From kim.barrett at oracle.com Sun Apr 1 03:12:57 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Sat, 31 Mar 2018 23:12:57 -0400
Subject: RFR: 8199417: Modularize interpreter GC barriers
In-Reply-To: <5AB8BDF9.4050106@oracle.com>
References: <5AB8BDF9.4050106@oracle.com>
Message-ID: <3FFD79AD-84B8-4E9E-98E3-47ACBA01D91F@oracle.com>
> On Mar 26, 2018, at 5:31 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>
> Hi,
>
> The GC barriers for the interpreter are not as modular as they could be. They currently use switch statements to check which GC barrier set is being used, and call this or that barrier based on that, in a way that assumes GCs only use write barriers.
>
> This patch modularizes this by generating accesses in the interpreter with declarative semantics. Accesses to the heap may now use store_at and load_at functions of the BarrierSetAssembler, passing along appropriate arguments and decorators. Each concrete BarrierSetAssembler can override the access completely or sprinkle some appropriate GC barriers as necessary.
>
> Big thanks go to Martin Doerr and Roman Kennke, who helped plugging this into S390, PPC and AArch64 respectively.
>
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.00/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8199417
>
> Thanks,
> /Erik
I've only looked at the x86 and generic code so far. I have some
comments, but also a bunch of questions. I think I'm missing some
things somewhere. I'm sending what I've got so far anyway, and will
continue studying.
------------------------------------------------------------------------------
src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
354 // flatten object address if needed
355 // We do it regardless of precise because we need the registers
There is no "precise" in this context.
------------------------------------------------------------------------------
src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
364 #ifndef _LP64
365 InterpreterMacroAssembler *imasm = static_cast<InterpreterMacroAssembler*>(masm);
366 #endif
In the old code, the function received an InterpreterMacroAssembler*.
What is there about this context that lets us know the downcast is
safe here? Is oop_store_at only ever called with an IMA*? If so,
then why isn't that the parameter type. If not, then what?
------------------------------------------------------------------------------
src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
753 bs->load_at(_masm, IN_HEAP | ON_WEAK_OOP_REF, T_OBJECT,
754 rax, field_address, /*tmp1*/ rbx, /*tmp_thread*/ rdx);
This needs to distinguish between WEAK and PHANTOM references, else it
will break ZGC's concurrent reference processing. (At least so long as
we still have to deal with finalization.)
------------------------------------------------------------------------------
src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
698 address TemplateInterpreterGenerator::generate_Reference_get_entry(void) {
Almost all the code here (and much of the commentary) was/is specific
to G1 (or SATB collectors). Shouldn't it all be in the barrier_set's
load_at? As it is now, if (say) we're using Parallel GC then I think
there's a bunch of additional code being generated and executed here
that wasn't present before.
------------------------------------------------------------------------------
src/hotspot/cpu/x86/methodHandles_x86.cpp
170 __ load_heap_oop(method_temp, Address(recv, NONZERO(java_lang_invoke_MethodHandle::form_offset_in_bytes())));
=>
175 bs->load_at(_masm, IN_HEAP, T_OBJECT, method_temp, Address(recv, NONZERO(java_lang_invoke_MethodHandle::form_offset_in_bytes())), t
This doesn't look like an improvement in code readability to me. Why
can't bs->load_at be the implementation of "__ load_heap_oop" ?
And the lines are getting really long; so long that webrev is cutting
off the right end, so I can't review the new versions of the lines.
------------------------------------------------------------------------------
src/hotspot/cpu/x86/methodHandles_x86.cpp
363 __ load_heap_oop(temp2_defc, member_clazz);
=>
368 BarrierSetAssembler* bs = BarrierSet::barrier_set()->barrier_set_assembler();
369 Register rthread = LP64_ONLY(r15_thread) NOT_LP64(noreg);
370 bs->load_at(_masm, IN_HEAP, T_OBJECT, temp2_defc, member_clazz, noreg, rthread);
Similarly, this doesn't seem like an improvement to me. And there are
more like this.
------------------------------------------------------------------------------
src/hotspot/cpu/x86/macroAssembler_x86.hpp
It would reduce the clutter in this change to leave the as_Address
declarations where they were, since that place is now public, rather
than moving them to a different public section.
------------------------------------------------------------------------------
Generally, it seems like it might be nice for the MacroAssembler class
to have a reference to the barrier_set, or maybe even the bs's
assembler, rather than looking them up in various places, and in
different ways. For example, I see each of
Universe::heap()->barrier_set()
BarrerSet::barrier_set()
used in various different places *in new code*. Some consistency
would be nice.
------------------------------------------------------------------------------
src/hotspot/cpu/x86/macroAssembler_x86.cpp
5249 bs->load_at(this, IN_ROOT | ON_PHANTOM_OOP_REF, T_OBJECT,
5250 value, Address(value, -JNIHandles::weak_tag_value), tmp, thread);
5251 verify_oop(value);
This puts the verify_oop after the G1 pre-barrier, where in the old
code verify_oop was before the pre-barrier. I remember the old order
being intentional, though don't off-hand recall how important that
was. If for no other reason, it seems like the new order could rarely
(due to bad timing) have a bad oop reported somewhere far away during
SATB buffer processing, rather than at the point of the load.
With the new version's order there could be one verify after the done
label. That's just a minor nit.
------------------------------------------------------------------------------
src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
230 #ifdef _LP64
231 if (c_rarg1 != thread) {
232 __ mov(c_rarg1, thread);
233 }
234 if (c_rarg0 != pre_val) {
235 __ mov(c_rarg0, pre_val);
236 }
237 #else
238 __ push(thread);
239 __ push(pre_val);
240 #endif
Old code used:
__ pass_arg1(thread);
__ pass_arg0(pre_val);
Why is this being changed? Oh, pass_argN are static helpers not
available outside macroAssembler_x86.cpp. Maybe they should be
exposed in some way, like public helpers in the x86 version of the
MacroAssembler class, rather than copied inline here (and maybe other
places?).
------------------------------------------------------------------------------
src/hotspot/cpu/x86/interp_masm_x86.cpp
Deleted these lines:
519 // The resulting oop is null if the reference is not yet resolved.
520 // It is Universe::the_null_sentinel() if the reference resolved to NULL via condy.
I don't think those comment lines should be deleted.
------------------------------------------------------------------------------
src/hotspot/cpu/x86/gc/shared/modRefBarrierSetAssembler_x86.cpp
86 void ModRefBarrierSetAssembler::store_at(MacroAssembler* masm, DecoratorSet decorators, BasicType type,
87 Address dst, Register val, Register tmp1, Register tmp2) {
88 if (type == T_OBJECT || type == T_ARRAY) {
89 oop_store_at(masm, decorators, type, dst, val, tmp1, tmp2);
90 } else {
91 BarrierSetAssembler::store_at(masm, decorators, type, dst, val, tmp1, tmp2);
92 }
93 }
Doesn't the conditional conversion from store_at to oop_store_at
actually indicate a bug in the caller? That is, calling store_at with
a oop (T_OBJECT or T_ARRAY) value seems like a bug, and should be
asserted against, rather than translating.
And oop_store_at should assert that the value *is* an oop value.
And should there be any verification that the decorators and the type
are consistent?
But maybe I'm not understanding the protocol around oop_store_at?
There being no documentation, it seems entirely possible that I've
misunderstood something here. Maybe I'm being confused by
similarities in naming with Access:: that don't hold?
------------------------------------------------------------------------------
src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
88 void CardTableBarrierSetAssembler::store_check(MacroAssembler* masm, Register obj, Address dst) {
89 // Does a store check for the oop in register obj. The content of
90 // register obj is destroyed afterwards.
The comment states obj is an oop, but when called by the precise case
of oop_store_at, it is not an oop, but rather a derived pointer. I
think it's the comment that's wrong.
------------------------------------------------------------------------------
I was surprised that oop_store_at is initially declared at the
ModRefBarrierSetAssembler level, rather than at the
BarrierSetAssembler level.
I was also surprised to not see an oop_load_at.
In Access we have _at suffixed operations paired with non-_at suffixed
operations, the difference being the _at suffixed operations have a
base object, to allow dealing with the brooks-ptr. I'm not finding any
such distinction in the xxxAssembler API. Presumably I've missed
something somewhere. How is that handled?
------------------------------------------------------------------------------
From gerard.ziemski at oracle.com Mon Apr 2 14:48:46 2018
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Mon, 2 Apr 2018 09:48:46 -0500
Subject: RFR (XL) 8081519 Split globals.hpp to factor out the Flag class
In-Reply-To: <4fb0eaf2-b27b-339e-7ea9-04ff3b9477ed@oracle.com>
References: <D6E4A4E8-8356-4694-BD9C-03AB5FA5BC65@oracle.com>
<17c47faa-4f6d-c3f3-bb71-ceba576146d0@oracle.com>
<680CAA14-704C-4B8A-8CB8-C3CFA7DF5B72@oracle.com>
<04FF41C3-FA1C-4570-BC35-BC986DCC7216@oracle.com>
<4fb0eaf2-b27b-339e-7ea9-04ff3b9477ed@oracle.com>
Message-ID: <F5A20A0C-DA99-4D62-B292-6CE41EF133BD@oracle.com>
Thank you for the review!
> On Mar 31, 2018, at 2:46 AM, David Holmes <david.holmes at oracle.com> wrote:
>
> Hi Gerard,
>
> Scanning through this it seems okay.
>
> Like Coleen I'm wondering why so many "flag" using .cpp files don't include jvmFlag.hpp? I expect they transitively included globals.hpp previously but now will need an explicit include.
I tested it with precompiled headers and without and all was good and I wanted to make as few changes to the include headers, but will explicitly add the headers.
>
> The two new files have a slight formatting error with their copyright, you need a comma after 2018.
Thank you.
>
> The include guards for all the relocated header files and the new files eg:
>
> 25 #ifndef SHARE_VM_RUNTIME_JVMFLAG_HPP
>
> need updating now you added the extra directory.
Good catch!
>
> Bikeshed: I'm not sure about calling the directory jvmFlags. First everything under src/hotspot is "jvm" so it is somewhat redundant to state that. Second you end up with jvmFlag/jvmFlag*.* which is more redundancy. I think runtime/flags would suffice.
Since we?re going through all the trouble, we can make this right - I like the suggestion, so will do.
cheers
>
> Thanks,
> David
>
> On 31/03/2018 3:27 AM, Gerard Ziemski wrote:
>> Hi all,
>> Please review this large and tedious (sorry), but simple fix that accomplishes the following:
>> #1 factor out the command option flag related APIs out of globals.hpp/.cpp into its own dedicated files, i.e. jvmFlag.hpp/.cpp
>> #2 moved all jvmFlag* files into its own dedicated folder (i.e. src/hotspot/share/runtime/jvmFlag/)
>> #3 merge Flag (too generic name) and CommandLineFlag classes and rename them as JVMFlag
>> #4 cleanup globals.hpp includes originally added by the JEP-245
>> Note: the renamed file retain their history, but one needs to add ?follow? flag, ex. ?hg log -f file?
>> https://bugs.openjdk.java.net/browse/JDK-8081519
>> http://cr.openjdk.java.net/~gziemski/8081519_rev2
>> Passes Mach5 hs_tier1-tier5, jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges tests.
>> cheers
From coleen.phillimore at oracle.com Mon Apr 2 19:22:32 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 2 Apr 2018 15:22:32 -0400
Subject: RFR (M) 8198313: Wrap holder object for ClassLoaderData in a
WeakHandle
In-Reply-To: <4C4FB5D1-A0BA-4CC8-ADB7-8BED6BC2B88C@oracle.com>
References: <3fe8b4c5-3e1d-d192-07ce-0828e3982e75@oracle.com>
<9C48FEF4-59DD-4415-AF18-B95ADBDFACB4@oracle.com>
<c62305c3-4567-d5c1-7aca-c5d47f885978@oracle.com>
<304110c1-f4e0-63c8-d94b-bc779b737411@oracle.com>
<4C4FB5D1-A0BA-4CC8-ADB7-8BED6BC2B88C@oracle.com>
Message-ID: <8372a910-f110-05df-85d0-e7c1859e4de4@oracle.com>
On 3/31/18 2:40 PM, Kim Barrett wrote:
>> On Mar 30, 2018, at 1:53 PM, coleen.phillimore at oracle.com wrote:
>>
>>
>> I have an incremental and full .02 version with the changes discussed here.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8198313.02.incr/webrev
>> open webrev at http://cr.openjdk.java.net/~coleenp/8198313.02/webrev
>>
>> These have been retested on x86, all hotspot jtreg tests.
>> thanks,
>> Coleen
> Looks good.
>
> In InstanceKlass::klass_holder_phantom, the klass_ prefix seems
> unnecessary. I don't need a new webrev if you decide to change the
> name.
Since it's pre-existing, I don't think I'll address it with this change.
Thank you for the review.
Coleen
From martijnverburg at gmail.com Mon Apr 2 20:40:01 2018
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 2 Apr 2018 22:40:01 +0200
Subject: JEP 331: Low-Overhead Heap Profiling
In-Reply-To: <20180329171223.64A4C1973B3@eggemoggin.niobe.net>
References: <20180329171223.64A4C1973B3@eggemoggin.niobe.net>
Message-ID: <CAP7YuARWgnVqMqAO711S0Kr2W-5d+9f1XSnGfMEJ16pFmBM9OA@mail.gmail.com>
This is a very welcome advancement - thank you! More NIH / custom LOC to
be removed from various projects I'm on :-)
Cheers,
Martijn
On 29 March 2018 at 19:12, <mark.reinhold at oracle.com> wrote:
> New JEP Candidate: http://openjdk.java.net/jeps/331
>
> - Mark
>
From jeremymanson at google.com Mon Apr 2 23:04:26 2018
From: jeremymanson at google.com (Jeremy Manson)
Date: Mon, 02 Apr 2018 23:04:26 +0000
Subject: JEP 331: Low-Overhead Heap Profiling
In-Reply-To: <CAP7YuARWgnVqMqAO711S0Kr2W-5d+9f1XSnGfMEJ16pFmBM9OA@mail.gmail.com>
References: <20180329171223.64A4C1973B3@eggemoggin.niobe.net>
<CAP7YuARWgnVqMqAO711S0Kr2W-5d+9f1XSnGfMEJ16pFmBM9OA@mail.gmail.com>
Message-ID: <CAPYFHW1Cdvd9yoy=Hd8H=b87r=+b0PPLqi+zNZEzt7uvGty_2w@mail.gmail.com>
Hey Martijn,
That's an interesting response. What did you build in this area?
(In developing this project, we've been pretty focused on our use cases,
many of which have been around for a very long time, so I'm really
interested to see what others are coming up with.)
Jeremy
On Mon, Apr 2, 2018 at 1:40 PM Martijn Verburg <martijnverburg at gmail.com>
wrote:
> This is a very welcome advancement - thank you! More NIH / custom LOC to
> be removed from various projects I'm on :-)
>
> Cheers,
> Martijn
>
> On 29 March 2018 at 19:12, <mark.reinhold at oracle.com> wrote:
>
> > New JEP Candidate: http://openjdk.java.net/jeps/331
> >
> > - Mark
> >
>
From yang.zhang at linaro.org Tue Apr 3 02:44:37 2018
From: yang.zhang at linaro.org (Yang Zhang)
Date: Tue, 3 Apr 2018 10:44:37 +0800
Subject: [aarch64-port-dev ] RFD: AOT for AArch64
In-Reply-To: <c16a5803-bc0e-f9d1-3644-ab925115563e@redhat.com>
References: <83f0e948-d002-6b71-e73f-6f65fce14e3b@redhat.com>
<6f669937-6e59-b4e8-e77b-1fe727dfc9e5@bell-sw.com>
<53daf9a7-5108-06ce-bb05-6b10612c48d8@bell-sw.com>
<c16a5803-bc0e-f9d1-3644-ab925115563e@redhat.com>
Message-ID: <CAHMTGtaxLe+65JBGRmJZXYmp-zym-pLeUkfzy_JjsSJMMT5Ynw@mail.gmail.com>
Hi Andrew
Thanks for your great work on aot.
I'm also testing your patches on jdk and graal. There are many
discussions on your patches. I'm not sure if I miss some updates in
the comments. Could you share your latest patches(hs and graal) and
jtreg command so that I can test them in my environment again?
Regards
Yang
On 29 March 2018 at 23:46, Andrew Haley <aph at redhat.com> wrote:
> There's a problem with assertions being fired which is apparently due
> to a recent Graal bug. Try running without assertions:
>
> diff -r ee513596f3ee test/hotspot/jtreg/compiler/aot/AotCompiler.java
> --- a/test/hotspot/jtreg/compiler/aot/AotCompiler.java Tue Jan 30 16:41:40 2018 +0100
> +++ b/test/hotspot/jtreg/compiler/aot/AotCompiler.java Thu Mar 29 16:37:21 2018 +0100
> @@ -114,8 +114,8 @@
> args.add(linker);
> }
> // Execute with asserts
> - args.add("-J-ea");
> - args.add("-J-esa");
> + // args.add("-J-ea");
> + // args.add("-J-esa");
> return launchJaotc(args, extraopts);
> }
>
> With that change, I get two failures. If you're seeing a lot more
> failures than that, please look t your test configuration.
>
> Passed: compiler/aot/calls/fromAot/AotInvokeDynamic2AotTest.java
> Passed: compiler/aot/calls/fromAot/AotInvokeDynamic2CompiledTest.java
> Passed: compiler/aot/calls/fromAot/AotInvokeDynamic2NativeTest.java
> Passed: compiler/aot/calls/fromAot/AotInvokeDynamic2InterpretedTest.java
> Passed: compiler/aot/calls/fromAot/AotInvokeInterface2InterpretedTest.java
> Passed: compiler/aot/calls/fromAot/AotInvokeInterface2AotTest.java
> Passed: compiler/aot/calls/fromAot/AotInvokeInterface2CompiledTest.java
> Passed: compiler/aot/calls/fromAot/AotInvokeInterface2NativeTest.java
> Passed: compiler/aot/calls/fromAot/AotInvokeSpecial2AotTest.java
> Passed: compiler/aot/calls/fromAot/AotInvokeSpecial2NativeTest.java
> Passed: compiler/aot/calls/fromAot/AotInvokeSpecial2CompiledTest.java
> Passed: compiler/aot/calls/fromAot/AotInvokeSpecial2InterpretedTest.java
> Passed: compiler/aot/calls/fromAot/AotInvokeStatic2AotTest.java
> Passed: compiler/aot/calls/fromAot/AotInvokeStatic2InterpretedTest.java
> Passed: compiler/aot/calls/fromAot/AotInvokeStatic2NativeTest.java
> Passed: compiler/aot/calls/fromAot/AotInvokeStatic2CompiledTest.java
> Passed: compiler/aot/calls/fromAot/AotInvokeVirtual2AotTest.java
> Passed: compiler/aot/calls/fromAot/AotInvokeVirtual2CompiledTest.java
> Passed: compiler/aot/calls/fromAot/AotInvokeVirtual2InterpretedTest.java
> Passed: compiler/aot/calls/fromAot/AotInvokeVirtual2NativeTest.java
> Passed: compiler/aot/calls/fromCompiled/CompiledInvokeDynamic2AotTest.java
> Passed: compiler/aot/calls/fromCompiled/CompiledInvokeInterface2AotTest.java
> Passed: compiler/aot/calls/fromCompiled/CompiledInvokeSpecial2AotTest.java
> Passed: compiler/aot/calls/fromCompiled/CompiledInvokeStatic2AotTest.java
> Passed: compiler/aot/calls/fromInterpreted/InterpretedInvokeInterface2AotTest.java
> Passed: compiler/aot/calls/fromInterpreted/InterpretedInvokeSpecial2AotTest.java
> Passed: compiler/aot/calls/fromCompiled/CompiledInvokeVirtual2AotTest.java
> Passed: compiler/aot/calls/fromInterpreted/InterpretedInvokeDynamic2AotTest.java
> Passed: compiler/aot/calls/fromNative/NativeInvokeStatic2AotTest.java
> Passed: compiler/aot/calls/fromInterpreted/InterpretedInvokeStatic2AotTest.java
> Passed: compiler/aot/calls/fromInterpreted/InterpretedInvokeVirtual2AotTest.java
> Passed: compiler/aot/calls/fromNative/NativeInvokeSpecial2AotTest.java
> Passed: compiler/aot/cli/jaotc/ClasspathOptionUnknownClassTest.java
> Passed: compiler/aot/cli/jaotc/CompileClassTest.java
> Passed: compiler/aot/calls/fromNative/NativeInvokeVirtual2AotTest.java
> Passed: compiler/aot/cli/jaotc/CompileClassWithDebugTest.java
> Passed: compiler/aot/cli/jaotc/CompileDirectoryTest.java
> Passed: compiler/aot/cli/jaotc/CompileModuleTest.java
> Passed: compiler/aot/cli/jaotc/CompileJarTest.java
> Passed: compiler/aot/cli/jaotc/ListOptionNotExistingTest.java
> Passed: compiler/aot/cli/jaotc/ListOptionTest.java
> Passed: compiler/aot/cli/jaotc/ListOptionWrongFileTest.java
> Passed: compiler/aot/cli/DisabledAOTWithLibraryTest.java
> Passed: compiler/aot/cli/IncorrectAOTLibraryTest.java
> Passed: compiler/aot/cli/NonExistingAOTLibraryTest.java
> Passed: compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/directory/DirectorySourceProviderTest.java
> Passed: compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/jar/JarSourceProviderTest.java
> Passed: compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/module/ModuleSourceProviderTest.java
> Passed: compiler/aot/cli/SingleAOTLibraryTest.java
> Passed: compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/ClassSearchTest.java
> Passed: compiler/aot/cli/MultipleAOTLibraryTest.java
> Passed: compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/ClassSourceTest.java
> Passed: compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/collect/SearchPathTest.java
> Passed: compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/NativeOrderOutputStreamTest.java
> Passed: compiler/aot/verification/vmflags/NotTrackedFlagTest.java
> Passed: compiler/aot/cli/SingleAOTOptionTest.java
> Passed: compiler/aot/verification/vmflags/TrackedFlagTest.java
> Passed: compiler/aot/verification/ClassAndLibraryNotMatchTest.java
> Passed: compiler/aot/SharedUsageTest.java
> TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Method is unexpectedly compiled after deoptimization: expected false, was true
> --------------------------------------------------
> Passed: compiler/aot/RecompilationTest.java
> Test results: passed: 60; failed: 1
> Report written to /local/jdk-hs/build/linux-aarch64-normal-server-release/test-results/jtreg_test_hotspot_jtreg_compiler_aot/html/report.html
> Results written to /local/jdk-hs/build/linux-aarch64-normal-server-release/test-support/jtreg_test_hotspot_jtreg_compiler_aot
> Error: Some tests failed or other problems occurred.
> Finished running test 'jtreg:test/hotspot/jtreg/compiler/aot'
> Test report is stored in build/linux-aarch64-normal-server-release/test-results/jtreg_test_hotspot_jtreg_compiler_aot
>
> ==============================
> Test summary
> ==============================
> TEST TOTAL PASS FAIL ERROR
>>> jtreg:test/hotspot/jtreg/compiler/aot 61 60 1 0 <<
> ==============================
> TEST FAILURE
>
> * jtreg:test/hotspot/jtreg/compiler/jvmci
>
> Running test 'jtreg:test/hotspot/jtreg/compiler/jvmci'
> Passed: compiler/jvmci/compilerToVM/AsResolvedJavaMethodTest.java
> Passed: compiler/jvmci/compilerToVM/CollectCountersTest.java
> Passed: compiler/jvmci/compilerToVM/DoNotInlineOrCompileTest.java
> --------------------------------------------------
> ACTION: main -- Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: CompileCodeTestCase{executable=public default int compiler.jvmci.compilerToVM.CompileCodeTestCase$Interface.defaultMethod(java.lang.Object), bci=-1} : 2nd invocation returned different value: expected
> --------------------------------------------------
> Passed: compiler/jvmci/compilerToVM/AllocateCompileIdTest.java
> Passed: compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest.java
> Passed: compiler/jvmci/compilerToVM/FindUniqueConcreteMethodTest.java
> Passed: compiler/jvmci/compilerToVM/DebugOutputTest.java
> Passed: compiler/jvmci/compilerToVM/GetBytecodeTest.java
> Passed: compiler/jvmci/compilerToVM/GetClassInitializerTest.java
> Passed: compiler/jvmci/compilerToVM/GetConstantPoolTest.java
> Passed: compiler/jvmci/compilerToVM/GetExceptionTableTest.java
> Passed: compiler/jvmci/compilerToVM/GetImplementorTest.java
> Passed: compiler/jvmci/compilerToVM/GetLineNumberTableTest.java
> Passed: compiler/jvmci/compilerToVM/GetFlagValueTest.java
> Passed: compiler/jvmci/compilerToVM/GetMaxCallTargetOffsetTest.java
> Passed: compiler/jvmci/compilerToVM/GetLocalVariableTableTest.java
> Passed: compiler/jvmci/compilerToVM/GetNextStackFrameTest.java
> Passed: compiler/jvmci/compilerToVM/GetResolvedJavaMethodTest.java
> Passed: compiler/jvmci/compilerToVM/GetStackTraceElementTest.java
> Passed: compiler/jvmci/compilerToVM/GetVtableIndexForInterfaceTest.java
> Passed: compiler/jvmci/compilerToVM/GetSymbolTest.java
> Passed: compiler/jvmci/compilerToVM/HasFinalizableSubclassTest.java
> Passed: compiler/jvmci/compilerToVM/HasNeverInlineDirectiveTest.java
> Passed: compiler/jvmci/compilerToVM/IsCompilableTest.java
> Passed: compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java
> Passed: compiler/jvmci/compilerToVM/IsMatureTest.java
> Passed: compiler/jvmci/compilerToVM/JVM_RegisterJVMCINatives.java
> Passed: compiler/jvmci/compilerToVM/IsMatureVsReprofileTest.java
> Passed: compiler/jvmci/compilerToVM/LookupKlassInPoolTest.java
> Passed: compiler/jvmci/compilerToVM/LookupKlassRefIndexInPoolTest.java
> Passed: compiler/jvmci/compilerToVM/LookupMethodInPoolTest.java
> Passed: compiler/jvmci/compilerToVM/LookupNameAndTypeRefIndexInPoolTest.java
> Passed: compiler/jvmci/compilerToVM/LookupNameInPoolTest.java
> Passed: compiler/jvmci/compilerToVM/LookupSignatureInPoolTest.java
> Passed: compiler/jvmci/compilerToVM/LookupTypeTest.java
> Passed: compiler/jvmci/compilerToVM/ReadConfigurationTest.java
> Passed: compiler/jvmci/compilerToVM/MethodIsIgnoredBySecurityStackWalkTest.java
> Passed: compiler/jvmci/compilerToVM/ResolveConstantInPoolTest.java
> Passed: compiler/jvmci/compilerToVM/ResolveFieldInPoolTest.java
> Passed: compiler/jvmci/compilerToVM/ResolveMethodTest.java
> Passed: compiler/jvmci/compilerToVM/ResolvePossiblyCachedConstantInPoolTest.java
> Passed: compiler/jvmci/compilerToVM/ReprofileTest.java
> Passed: compiler/jvmci/compilerToVM/ResolveTypeInPoolTest.java
> Passed: compiler/jvmci/compilerToVM/ShouldDebugNonSafepointsTest.java
> Passed: compiler/jvmci/compilerToVM/ShouldInlineMethodTest.java
> Passed: compiler/jvmci/errors/TestInvalidCompilationResult.java
> Passed: compiler/jvmci/errors/TestInvalidDebugInfo.java
> Passed: compiler/jvmci/errors/TestInvalidOopMap.java
> Passed: compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java
> Passed: compiler/jvmci/events/JvmciShutdownEventTest.java
> Passed: compiler/jvmci/events/JvmciNotifyInstallEventTest.java
> Passed: compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/HotSpotConstantReflectionProviderTest.java
> Passed: compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/MethodHandleAccessProviderTest.java
> Passed: compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/MemoryAccessProviderTest.java
> Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ResolvedJavaTypeResolveConcreteMethodTest.java
> Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ConstantTest.java
> Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ResolvedJavaTypeResolveMethodTest.java
> Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java
> Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestConstantReflectionProvider.java
> Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaMethod.java
> Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaType.java
> Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaField.java
> Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestMetaAccessProvider.java
> Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaField.java
> Passed: compiler/jvmci/meta/StableFieldTest.java
> Passed: compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java
> Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java
> Passed: compiler/jvmci/TestJVMCIPrintProperties.java
> Passed: compiler/jvmci/JVM_GetJVMCIRuntimeTest.java
> Passed: compiler/jvmci/TestValidateModules.java
> Passed: compiler/jvmci/SecurityRestrictionsTest.java
> Passed: compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java
> Test results: passed: 72; failed: 1
> Report written to /local/jdk-hs/build/linux-aarch64-normal-server-release/test-results/jtreg_test_hotspot_jtreg_compiler_jvmci/html/report.html
> Results written to /local/jdk-hs/build/linux-aarch64-normal-server-release/test-support/jtreg_test_hotspot_jtreg_compiler_jvmci
> Error: Some tests failed or other problems occurred.
> Finished running test 'jtreg:test/hotspot/jtreg/compiler/jvmci'
> Test report is stored in build/linux-aarch64-normal-server-release/test-results/jtreg_test_hotspot_jtreg_compiler_jvmci
>
> ==============================
> Test summary
> ==============================
> TEST TOTAL PASS FAIL ERROR
>>> jtreg:test/hotspot/jtreg/compiler/jvmci 73 72 1 0 <<
> ==============================
> TEST FAILURE
From per.liden at oracle.com Tue Apr 3 06:42:09 2018
From: per.liden at oracle.com (Per Liden)
Date: Tue, 3 Apr 2018 08:42:09 +0200
Subject: RFR: 8200429: Adjust object pinning interface on CollectedHeap
Message-ID: <60450527-a94b-f015-b5a7-a9b745e90b33@oracle.com>
The recent additions to CollectedHeap to support object pinning didn't
quite fit the bill for what the Shenandoah folks had in mind. Instead of
having CollectedHeap::pin_obejct/unpin_object grab/release the GCLocker
when object pinning is not supported, we add a
CollectedHeap::supports_obejct_pinning() and let the caller take the
appropriate action based on the response.
Bug: https://bugs.openjdk.java.net/browse/JDK-8200429
Webrev: http://cr.openjdk.java.net/~pliden/8200429/webrev.0
/Per
From per.liden at oracle.com Tue Apr 3 07:00:28 2018
From: per.liden at oracle.com (Per Liden)
Date: Tue, 3 Apr 2018 09:00:28 +0200
Subject: RFR: 8176717: GC log file handle leaked to child processes
In-Reply-To: <CAA-vtUxM2ED6MeLp3RvXXx8CY=1O73gAeT=qbhWQHKwcc9gv3A@mail.gmail.com>
References: <bcf5e1ca-ed60-127c-5765-98350909e38a@oracle.com>
<271f07b2-2a74-c5ff-7a7b-d9805929a23c@oracle.com>
<04b0987c-0de4-1e5e-52be-0c603c1fab10@oracle.com>
<4c216bb1-a3bf-e916-d07a-643431faa341@oracle.com>
<796998bd-78f5-1a2a-a38e-fc5da8f10b7a@oracle.com>
<CAA-vtUxM2ED6MeLp3RvXXx8CY=1O73gAeT=qbhWQHKwcc9gv3A@mail.gmail.com>
Message-ID: <4487e6ef-3fe1-c598-ec89-3ee1f0ebaa67@oracle.com>
On 03/30/2018 01:16 PM, Thomas St?fe wrote:
> Hi Leo,
>
> looks okay. I stated my reservations against adding this function and
> the platform specific code in its current form before, but I can
> certainly live with this fix. It follows what we did in os::open(), so
> it is consistent in that matter.
>
> Thanks for fixing this!
>
> Thomas
>
> (btw, I am not sure which of my "2" Per meant, since I accidentally
> miscounted my points in the earlier mail.)
Ah, didn't even notice ;) I was referring to the third bullet (the
second "2").
/Per
>
>
>
>
>
> On Thu, Mar 29, 2018 at 5:41 PM, Leo Korinth <leo.korinth at oracle.com
> <mailto:leo.korinth at oracle.com>> wrote:
>
> On 23/03/18 20:03, Leo Korinth wrote:
>
> Hi!
>
> Cross-posting this to both hotspot-dev and hotspot-runtime-dev
> to get more attention. Sorry.
>
> Original mail conversation can be found here:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-March/030637.html
> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-March/030637.html>
>
> I need feedback to know how to continue.
>
> Thanks,
> Leo
>
>
> Hi!
>
> Below is a new webrev with Thomas' and Per's suggested name change
> from: os::fopen_retain(const char* path, const char* mode)
> to:? ?os::fopen(const char* path, const char* mode)
>
> Full webrev:
> http://cr.openjdk.java.net/~lkorinth/8176717/02/
> <http://cr.openjdk.java.net/~lkorinth/8176717/02/>
>
> Review and/or comments please!
>
> Thanks,
> Leo
>
>
From david.holmes at oracle.com Tue Apr 3 07:01:43 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 3 Apr 2018 17:01:43 +1000
Subject: RFR: 8200429: Adjust object pinning interface on CollectedHeap
In-Reply-To: <60450527-a94b-f015-b5a7-a9b745e90b33@oracle.com>
References: <60450527-a94b-f015-b5a7-a9b745e90b33@oracle.com>
Message-ID: <cdd994d0-e645-6fe2-bd01-199febe8c700@oracle.com>
Hi Per,
On 3/04/2018 4:42 PM, Per Liden wrote:
> The recent additions to CollectedHeap to support object pinning didn't
> quite fit the bill for what the Shenandoah folks had in mind. Instead of
> having CollectedHeap::pin_obejct/unpin_object grab/release the GCLocker
> when object pinning is not supported, we add a
> CollectedHeap::supports_obejct_pinning() and let the caller take the
> appropriate action based on the response.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200429
> Webrev: http://cr.openjdk.java.net/~pliden/8200429/webrev.0
This looks fine to me. If we ever get a third way of not allowing an
object to move we should probably try to think of a good name for that
operation. ;-)
Thanks,
David
> /Per
From per.liden at oracle.com Tue Apr 3 07:11:31 2018
From: per.liden at oracle.com (Per Liden)
Date: Tue, 3 Apr 2018 09:11:31 +0200
Subject: RFR: 8200429: Adjust object pinning interface on CollectedHeap
In-Reply-To: <cdd994d0-e645-6fe2-bd01-199febe8c700@oracle.com>
References: <60450527-a94b-f015-b5a7-a9b745e90b33@oracle.com>
<cdd994d0-e645-6fe2-bd01-199febe8c700@oracle.com>
Message-ID: <ca01bdfc-e077-60c3-e72b-20ca313c2060@oracle.com>
Thanks for reviewing David!
/Per
On 04/03/2018 09:01 AM, David Holmes wrote:
> Hi Per,
>
> On 3/04/2018 4:42 PM, Per Liden wrote:
>> The recent additions to CollectedHeap to support object pinning didn't
>> quite fit the bill for what the Shenandoah folks had in mind. Instead
>> of having CollectedHeap::pin_obejct/unpin_object grab/release the
>> GCLocker when object pinning is not supported, we add a
>> CollectedHeap::supports_obejct_pinning() and let the caller take the
>> appropriate action based on the response.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200429
>> Webrev: http://cr.openjdk.java.net/~pliden/8200429/webrev.0
>
> This looks fine to me. If we ever get a third way of not allowing an
> object to move we should probably try to think of a good name for that
> operation. ;-)
>
> Thanks,
> David
>
>> /Per
From shade at redhat.com Tue Apr 3 08:20:07 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 3 Apr 2018 10:20:07 +0200
Subject: RFR/RFC: Non-PCH x86_32 build failure: err_msg is not defined
In-Reply-To: <CAA-vtUzLmuiCfwrSS0s+du_vNeUixOyaBEwN=HiJLCWmB6UtMQ@mail.gmail.com>
References: <e4c3ce19-c202-603e-7845-85cd0b789935@redhat.com>
<CAA-vtUzLmuiCfwrSS0s+du_vNeUixOyaBEwN=HiJLCWmB6UtMQ@mail.gmail.com>
Message-ID: <f0d017e9-49cc-adb8-215d-cb62af9b1d7c@redhat.com>
Thanks!
I would like to push the patch in this form, even though there seems to be a build system bug [1]
that builds x86_64 in x86_32 config. It also makes sense to me, because sharedRuntime_x86_64.cpp
uses err_msg defined in that header, and regular build seems to pass because we get that definition
transitively (which is fragile).
Any other opinions?
-Aleksey
[1] https://bugs.openjdk.java.net/browse/JDK-8200441
On 03/29/2018 08:02 PM, Thomas St?fe wrote:
> The fix is of course ok, regardless of the x64 confusion.
>
> ..Thomas
>
> On Thu, Mar 29, 2018 at 6:21 PM, Aleksey Shipilev <shade at redhat.com <mailto:shade at redhat.com>> wrote:
>
> Bug:
> ?https://bugs.openjdk.java.net/browse/JDK-8200438 <https://bugs.openjdk.java.net/browse/JDK-8200438>
>
> Obvious fix:
>
> diff -r 5a757c0326c7 src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
> --- a/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp? ? ? Thu Mar 29 17:15:26 2018 +0200
> +++ b/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp? ? ? Thu Mar 29 18:17:58 2018 +0200
> @@ -41,6 +41,7 @@
> ?#include "runtime/sharedRuntime.hpp"
> ?#include "runtime/vframeArray.hpp"
> ?#include "utilities/align.hpp"
> +#include "utilities/formatBuffer.hpp"
> ?#include "vm_version_x86.hpp"
> ?#include "vmreg_x86.inline.hpp"
> ?#ifdef COMPILER1
>
>
> The non-obvious part (and thus, "RFC") is why x86_64 build works fine in the same config. I don't
> have the answer for that.
>
> Testing: x86_32 build
>
> Thanks,
> -Aleksey
>
>
From stefan.karlsson at oracle.com Tue Apr 3 08:22:03 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 3 Apr 2018 10:22:03 +0200
Subject: RFR/RFC: Non-PCH x86_32 build failure: err_msg is not defined
In-Reply-To: <f0d017e9-49cc-adb8-215d-cb62af9b1d7c@redhat.com>
References: <e4c3ce19-c202-603e-7845-85cd0b789935@redhat.com>
<CAA-vtUzLmuiCfwrSS0s+du_vNeUixOyaBEwN=HiJLCWmB6UtMQ@mail.gmail.com>
<f0d017e9-49cc-adb8-215d-cb62af9b1d7c@redhat.com>
Message-ID: <1565fc89-17f8-96c7-c16c-8ac76c98c507@oracle.com>
On 2018-04-03 10:20, Aleksey Shipilev wrote:
> Thanks!
>
> I would like to push the patch in this form, even though there seems to be a build system bug [1]
> that builds x86_64 in x86_32 config. It also makes sense to me, because sharedRuntime_x86_64.cpp
> uses err_msg defined in that header, and regular build seems to pass because we get that definition
> transitively (which is fragile).
>
> Any other opinions?
Go ahead and push this fix.
Thanks,
StefanK
>
> -Aleksey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8200441
>
> On 03/29/2018 08:02 PM, Thomas St?fe wrote:
>> The fix is of course ok, regardless of the x64 confusion.
>>
>> ..Thomas
>>
>> On Thu, Mar 29, 2018 at 6:21 PM, Aleksey Shipilev <shade at redhat.com <mailto:shade at redhat.com>> wrote:
>>
>> Bug:
>> ?https://bugs.openjdk.java.net/browse/JDK-8200438 <https://bugs.openjdk.java.net/browse/JDK-8200438>
>>
>> Obvious fix:
>>
>> diff -r 5a757c0326c7 src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
>> --- a/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp? ? ? Thu Mar 29 17:15:26 2018 +0200
>> +++ b/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp? ? ? Thu Mar 29 18:17:58 2018 +0200
>> @@ -41,6 +41,7 @@
>> ?#include "runtime/sharedRuntime.hpp"
>> ?#include "runtime/vframeArray.hpp"
>> ?#include "utilities/align.hpp"
>> +#include "utilities/formatBuffer.hpp"
>> ?#include "vm_version_x86.hpp"
>> ?#include "vmreg_x86.inline.hpp"
>> ?#ifdef COMPILER1
>>
>>
>> The non-obvious part (and thus, "RFC") is why x86_64 build works fine in the same config. I don't
>> have the answer for that.
>>
>> Testing: x86_32 build
>>
>> Thanks,
>> -Aleksey
>>
>>
>
>
From rkennke at redhat.com Tue Apr 3 08:27:01 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 3 Apr 2018 10:27:01 +0200
Subject: RFR: 8200429: Adjust object pinning interface on CollectedHeap
In-Reply-To: <60450527-a94b-f015-b5a7-a9b745e90b33@oracle.com>
References: <60450527-a94b-f015-b5a7-a9b745e90b33@oracle.com>
Message-ID: <35871244-fd9d-5d01-51cb-b3606a69b6f6@redhat.com>
Am 03.04.2018 um 08:42 schrieb Per Liden:
> The recent additions to CollectedHeap to support object pinning didn't
> quite fit the bill for what the Shenandoah folks had in mind. Instead of
> having CollectedHeap::pin_obejct/unpin_object grab/release the GCLocker
> when object pinning is not supported, we add a
> CollectedHeap::supports_obejct_pinning() and let the caller take the
> appropriate action based on the response.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200429
> Webrev: http://cr.openjdk.java.net/~pliden/8200429/webrev.0
>
> /Per
Looks good to me. Thank you!
Roman
From per.liden at oracle.com Tue Apr 3 08:37:36 2018
From: per.liden at oracle.com (Per Liden)
Date: Tue, 3 Apr 2018 10:37:36 +0200
Subject: RFR: 8200429: Adjust object pinning interface on CollectedHeap
In-Reply-To: <35871244-fd9d-5d01-51cb-b3606a69b6f6@redhat.com>
References: <60450527-a94b-f015-b5a7-a9b745e90b33@oracle.com>
<35871244-fd9d-5d01-51cb-b3606a69b6f6@redhat.com>
Message-ID: <8dee1569-0781-0e71-652c-c9a330eb1181@oracle.com>
On 04/03/2018 10:27 AM, Roman Kennke wrote:
> Am 03.04.2018 um 08:42 schrieb Per Liden:
>> The recent additions to CollectedHeap to support object pinning didn't
>> quite fit the bill for what the Shenandoah folks had in mind. Instead of
>> having CollectedHeap::pin_obejct/unpin_object grab/release the GCLocker
>> when object pinning is not supported, we add a
>> CollectedHeap::supports_obejct_pinning() and let the caller take the
>> appropriate action based on the response.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200429
>> Webrev: http://cr.openjdk.java.net/~pliden/8200429/webrev.0
>>
>> /Per
>
> Looks good to me. Thank you!
Thanks for reviewing Roman!
Do you or Zhengyu plan on upstreaming a version of the patch you linked
to in the other mail thread, to support object pinning with
JavaCritical_? It seems that patch would complete the overall object
pinning story for HotSpot and would be useful for other GCs as well (at
least G1 and ZGC).
/Per
>
> Roman
>
From shade at redhat.com Tue Apr 3 08:38:49 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 3 Apr 2018 10:38:49 +0200
Subject: RFR/RFC: Non-PCH x86_32 build failure: err_msg is not defined
In-Reply-To: <1565fc89-17f8-96c7-c16c-8ac76c98c507@oracle.com>
References: <e4c3ce19-c202-603e-7845-85cd0b789935@redhat.com>
<CAA-vtUzLmuiCfwrSS0s+du_vNeUixOyaBEwN=HiJLCWmB6UtMQ@mail.gmail.com>
<f0d017e9-49cc-adb8-215d-cb62af9b1d7c@redhat.com>
<1565fc89-17f8-96c7-c16c-8ac76c98c507@oracle.com>
Message-ID: <79cfdfc8-7f61-4ba1-271a-9948f909291c@redhat.com>
Pushed.
-Aleksey
On 04/03/2018 10:22 AM, Stefan Karlsson wrote:
> On 2018-04-03 10:20, Aleksey Shipilev wrote:
>> Thanks!
>>
>> I would like to push the patch in this form, even though there seems to be a build system bug [1]
>> that builds x86_64 in x86_32 config. It also makes sense to me, because sharedRuntime_x86_64.cpp
>> uses err_msg defined in that header, and regular build seems to pass because we get that definition
>> transitively (which is fragile).
>>
>> Any other opinions?
>
> Go ahead and push this fix.
>
> Thanks,
> StefanK
>
>>
>> -Aleksey
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8200441
>>
>> On 03/29/2018 08:02 PM, Thomas St?fe wrote:
>>> The fix is of course ok, regardless of the x64 confusion.
>>>
>>> ..Thomas
>>>
>>> On Thu, Mar 29, 2018 at 6:21 PM, Aleksey Shipilev <shade at redhat.com <mailto:shade at redhat.com>>
>>> wrote:
>>>
>>> ???? Bug:
>>> ???? ?https://bugs.openjdk.java.net/browse/JDK-8200438
>>> <https://bugs.openjdk.java.net/browse/JDK-8200438>
>>>
>>> ???? Obvious fix:
>>>
>>> ???? diff -r 5a757c0326c7 src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
>>> ???? --- a/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp? ? ? Thu Mar 29 17:15:26 2018 +0200
>>> ???? +++ b/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp? ? ? Thu Mar 29 18:17:58 2018 +0200
>>> ???? @@ -41,6 +41,7 @@
>>> ???? ?#include "runtime/sharedRuntime.hpp"
>>> ???? ?#include "runtime/vframeArray.hpp"
>>> ???? ?#include "utilities/align.hpp"
>>> ???? +#include "utilities/formatBuffer.hpp"
>>> ???? ?#include "vm_version_x86.hpp"
>>> ???? ?#include "vmreg_x86.inline.hpp"
>>> ???? ?#ifdef COMPILER1
>>>
>>>
>>> ???? The non-obvious part (and thus, "RFC") is why x86_64 build works fine in the same config. I
>>> don't
>>> ???? have the answer for that.
>>>
>>> ???? Testing: x86_32 build
>>>
>>> ???? Thanks,
>>> ???? -Aleksey
>>>
>>>
>>
>>
From per.liden at oracle.com Tue Apr 3 08:46:15 2018
From: per.liden at oracle.com (Per Liden)
Date: Tue, 3 Apr 2018 10:46:15 +0200
Subject: RFR: 8200607: Add missing include dependency in bitMap.hpp
Message-ID: <84176d75-15d8-ba37-9d71-b41a15b0b0dc@oracle.com>
bitMap.hpp uses the MEMFLAGS type, but doesn't include allocation.hpp,
where that type is defined. This problem was exposed when writing a
small gtest test-case, which only included bitMap.hpp.
Bug: https://bugs.openjdk.java.net/browse/JDK-8200607
Webrev: http://cr.openjdk.java.net/~pliden/8200607/webrev.0
/Per
From shade at redhat.com Tue Apr 3 08:49:13 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 3 Apr 2018 10:49:13 +0200
Subject: RFR: 8200607: Add missing include dependency in bitMap.hpp
In-Reply-To: <84176d75-15d8-ba37-9d71-b41a15b0b0dc@oracle.com>
References: <84176d75-15d8-ba37-9d71-b41a15b0b0dc@oracle.com>
Message-ID: <27f6f775-7ded-590b-e7ef-ee14bcfecff2@redhat.com>
On 04/03/2018 10:46 AM, Per Liden wrote:
> bitMap.hpp uses the MEMFLAGS type, but doesn't include allocation.hpp, where that type is defined.
> This problem was exposed when writing a small gtest test-case, which only included bitMap.hpp.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200607
> Webrev: http://cr.openjdk.java.net/~pliden/8200607/webrev.0
Looks good!
-Aleksey
From stefan.karlsson at oracle.com Tue Apr 3 08:48:51 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 3 Apr 2018 10:48:51 +0200
Subject: RFR: 8200607: Add missing include dependency in bitMap.hpp
In-Reply-To: <84176d75-15d8-ba37-9d71-b41a15b0b0dc@oracle.com>
References: <84176d75-15d8-ba37-9d71-b41a15b0b0dc@oracle.com>
Message-ID: <955b8dd0-f27f-16be-efea-3962cc8ab070@oracle.com>
Looks good.
StefanK
On 2018-04-03 10:46, Per Liden wrote:
> bitMap.hpp uses the MEMFLAGS type, but doesn't include allocation.hpp,
> where that type is defined. This problem was exposed when writing a
> small gtest test-case, which only included bitMap.hpp.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200607
> Webrev: http://cr.openjdk.java.net/~pliden/8200607/webrev.0
>
> /Per
From per.liden at oracle.com Tue Apr 3 08:55:12 2018
From: per.liden at oracle.com (Per Liden)
Date: Tue, 3 Apr 2018 10:55:12 +0200
Subject: RFR: 8200607: Add missing include dependency in bitMap.hpp
In-Reply-To: <955b8dd0-f27f-16be-efea-3962cc8ab070@oracle.com>
References: <84176d75-15d8-ba37-9d71-b41a15b0b0dc@oracle.com>
<955b8dd0-f27f-16be-efea-3962cc8ab070@oracle.com>
Message-ID: <7ab06c45-5b39-7335-d187-1abca11fcbe6@oracle.com>
Thanks for reviewing, Aleksey and Stefan!
/Per
On 04/03/2018 10:48 AM, Stefan Karlsson wrote:
> Looks good.
>
> StefanK
>
> On 2018-04-03 10:46, Per Liden wrote:
>> bitMap.hpp uses the MEMFLAGS type, but doesn't include allocation.hpp,
>> where that type is defined. This problem was exposed when writing a
>> small gtest test-case, which only included bitMap.hpp.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200607
>> Webrev: http://cr.openjdk.java.net/~pliden/8200607/webrev.0
>>
>> /Per
From rkennke at redhat.com Tue Apr 3 09:03:55 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 3 Apr 2018 11:03:55 +0200
Subject: RFR: 8200429: Adjust object pinning interface on CollectedHeap
In-Reply-To: <8dee1569-0781-0e71-652c-c9a330eb1181@oracle.com>
References: <60450527-a94b-f015-b5a7-a9b745e90b33@oracle.com>
<35871244-fd9d-5d01-51cb-b3606a69b6f6@redhat.com>
<8dee1569-0781-0e71-652c-c9a330eb1181@oracle.com>
Message-ID: <eec7fe2a-b917-cdff-6352-72e1b1ab5abe@redhat.com>
Am 03.04.2018 um 10:37 schrieb Per Liden:
> On 04/03/2018 10:27 AM, Roman Kennke wrote:
>> Am 03.04.2018 um 08:42 schrieb Per Liden:
>>> The recent additions to CollectedHeap to support object pinning didn't
>>> quite fit the bill for what the Shenandoah folks had in mind. Instead of
>>> having CollectedHeap::pin_obejct/unpin_object grab/release the GCLocker
>>> when object pinning is not supported, we add a
>>> CollectedHeap::supports_obejct_pinning() and let the caller take the
>>> appropriate action based on the response.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200429
>>> Webrev: http://cr.openjdk.java.net/~pliden/8200429/webrev.0
>>>
>>> /Per
>>
>> Looks good to me. Thank you!
>
> Thanks for reviewing Roman!
>
> Do you or Zhengyu plan on upstreaming a version of the patch you linked
> to in the other mail thread, to support object pinning with
> JavaCritical_? It seems that patch would complete the overall object
> pinning story for HotSpot and would be useful for other GCs as well (at
> least G1 and ZGC).
Yes, definitely. Zhengyu is working on it. We want to give it a little
bit of baking in Shenandoah land, and then upstream it soon.
https://bugs.openjdk.java.net/browse/JDK-8199868
Thanks, Roman
From shade at redhat.com Tue Apr 3 09:18:03 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 3 Apr 2018 11:18:03 +0200
Subject: RFR (XS) 8200608: Build failures after JDK-8191101 (Show register
content in hs-err file on assert)
Message-ID: <c16534f7-3c96-407b-7b37-e2676ccc6d24@redhat.com>
Bug:
https://bugs.openjdk.java.net/browse/JDK-8200608
"jlong" is not "intx" in x86_32. The fix is simple, because os::current_thread_id() actually returns
intx. I think the fix falls under triviality rule.
--- a/src/hotspot/share/utilities/debug.cpp Tue Apr 03 10:27:46 2018 +0200
+++ b/src/hotspot/share/utilities/debug.cpp Tue Apr 03 11:04:01 2018 +0200
@@ -731,7 +731,7 @@
os::protect_memory((char*)g_assert_poison, os::vm_page_size(), os::MEM_PROT_RWX);
// Store Context away.
if (ucVoid) {
- const jlong my_tid = os::current_thread_id();
+ const intx my_tid = os::current_thread_id();
if (Atomic::cmpxchg(my_tid, &g_asserting_thread, (intx)0) == 0) {
if (store_context(ucVoid)) {
g_assertion_context = &g_stored_assertion_context;
Testing: x86_32 and x86_64 builds
Thanks,
-Aleksey
From per.liden at oracle.com Tue Apr 3 09:11:02 2018
From: per.liden at oracle.com (Per Liden)
Date: Tue, 3 Apr 2018 11:11:02 +0200
Subject: RFR: 8200429: Adjust object pinning interface on CollectedHeap
In-Reply-To: <eec7fe2a-b917-cdff-6352-72e1b1ab5abe@redhat.com>
References: <60450527-a94b-f015-b5a7-a9b745e90b33@oracle.com>
<35871244-fd9d-5d01-51cb-b3606a69b6f6@redhat.com>
<8dee1569-0781-0e71-652c-c9a330eb1181@oracle.com>
<eec7fe2a-b917-cdff-6352-72e1b1ab5abe@redhat.com>
Message-ID: <252b5f11-5253-1100-f967-73895981dcf6@oracle.com>
On 04/03/2018 11:03 AM, Roman Kennke wrote:
> Am 03.04.2018 um 10:37 schrieb Per Liden:
>> On 04/03/2018 10:27 AM, Roman Kennke wrote:
>>> Am 03.04.2018 um 08:42 schrieb Per Liden:
>>>> The recent additions to CollectedHeap to support object pinning didn't
>>>> quite fit the bill for what the Shenandoah folks had in mind. Instead of
>>>> having CollectedHeap::pin_obejct/unpin_object grab/release the GCLocker
>>>> when object pinning is not supported, we add a
>>>> CollectedHeap::supports_obejct_pinning() and let the caller take the
>>>> appropriate action based on the response.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200429
>>>> Webrev: http://cr.openjdk.java.net/~pliden/8200429/webrev.0
>>>>
>>>> /Per
>>>
>>> Looks good to me. Thank you!
>>
>> Thanks for reviewing Roman!
>>
>> Do you or Zhengyu plan on upstreaming a version of the patch you linked
>> to in the other mail thread, to support object pinning with
>> JavaCritical_? It seems that patch would complete the overall object
>> pinning story for HotSpot and would be useful for other GCs as well (at
>> least G1 and ZGC).
>
> Yes, definitely. Zhengyu is working on it. We want to give it a little
> bit of baking in Shenandoah land, and then upstream it soon.
>
> https://bugs.openjdk.java.net/browse/JDK-8199868
Sounds like a good plan, thanks!
/Per
>
> Thanks, Roman
>
From david.holmes at oracle.com Tue Apr 3 09:53:10 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 3 Apr 2018 19:53:10 +1000
Subject: RFR (XS) 8200608: Build failures after JDK-8191101 (Show register
content in hs-err file on assert)
In-Reply-To: <c16534f7-3c96-407b-7b37-e2676ccc6d24@redhat.com>
References: <c16534f7-3c96-407b-7b37-e2676ccc6d24@redhat.com>
Message-ID: <f159b52c-ef24-344f-5df9-0fe9b9be2d4f@oracle.com>
Seems trivial.
I have to wonder why jlong was ever used in the first place ???
David
On 3/04/2018 7:18 PM, Aleksey Shipilev wrote:
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8200608
>
> "jlong" is not "intx" in x86_32. The fix is simple, because os::current_thread_id() actually returns
> intx. I think the fix falls under triviality rule.
>
> --- a/src/hotspot/share/utilities/debug.cpp Tue Apr 03 10:27:46 2018 +0200
> +++ b/src/hotspot/share/utilities/debug.cpp Tue Apr 03 11:04:01 2018 +0200
> @@ -731,7 +731,7 @@
> os::protect_memory((char*)g_assert_poison, os::vm_page_size(), os::MEM_PROT_RWX);
> // Store Context away.
> if (ucVoid) {
> - const jlong my_tid = os::current_thread_id();
> + const intx my_tid = os::current_thread_id();
> if (Atomic::cmpxchg(my_tid, &g_asserting_thread, (intx)0) == 0) {
> if (store_context(ucVoid)) {
> g_assertion_context = &g_stored_assertion_context;
>
>
> Testing: x86_32 and x86_64 builds
>
> Thanks,
> -Aleksey
>
From magnus.ihse.bursie at oracle.com Tue Apr 3 10:13:37 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 3 Apr 2018 12:13:37 +0200
Subject: RFR (XL) 8081519 Split globals.hpp to factor out the Flag class
In-Reply-To: <D6E4A4E8-8356-4694-BD9C-03AB5FA5BC65@oracle.com>
References: <D6E4A4E8-8356-4694-BD9C-03AB5FA5BC65@oracle.com>
Message-ID: <8c2d6984-befe-bd10-7e2d-9c486e504a90@oracle.com>
On 2018-03-29 21:01, Gerard Ziemski wrote:
> Hi all,
>
> Please review this large and tedious (sorry), but simple fix that accomplishes the following:
>
> #1 factor out the command option flag related APIs out of globals.hpp/.cpp into its own dedicated files, i.e. jvmFlag.hpp/.cpp
> #2 merge Flag (too generic name) and CommandLineFlag classes and rename them as JVMFlag
> #3 cleanup globals.hpp includes originally added by the JEP-245
>
> Note: the renamed file retain their history, but one needs to add ?follow? flag, ex. ?hg log -f file?
>
> https://bugs.openjdk.java.net/browse/JDK-8081519
> http://cr.openjdk.java.net/~gziemski/8081519_rev1
Hi Gerard,
More or less by chance I looked at a random file in your review. I
noticed that the copyright line does not follow the Oracle standard:
2? * Copyright (c) 2018 Oracle and/or its affiliates. All rights reserved.
should be:
2? * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
/Your friendly typo detector. :)
>
> Passes Mach5 hs_tier1-tier5, jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges tests.
>
>
> cheers
From martijnverburg at gmail.com Tue Apr 3 10:17:21 2018
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 3 Apr 2018 11:17:21 +0100
Subject: JEP 331: Low-Overhead Heap Profiling
In-Reply-To: <CAPYFHW1Cdvd9yoy=Hd8H=b87r=+b0PPLqi+zNZEzt7uvGty_2w@mail.gmail.com>
References: <20180329171223.64A4C1973B3@eggemoggin.niobe.net>
<CAP7YuARWgnVqMqAO711S0Kr2W-5d+9f1XSnGfMEJ16pFmBM9OA@mail.gmail.com>
<CAPYFHW1Cdvd9yoy=Hd8H=b87r=+b0PPLqi+zNZEzt7uvGty_2w@mail.gmail.com>
Message-ID: <CAP7YuAQtG_4ZJCgoO4dJ+wjrRqnP9yMZcqMwLR5nbd_As9b=NQ@mail.gmail.com>
Mainly closed source (sadly) tooling for jClarity customers. e.g. Various
object allocation probes that can be byte code weaved in to detect and
capture 'interesting' allocation patterns (such as humungous objects).
Cheers,
Martijn
On 3 April 2018 at 00:04, Jeremy Manson <jeremymanson at google.com> wrote:
> Hey Martijn,
>
> That's an interesting response. What did you build in this area?
>
> (In developing this project, we've been pretty focused on our use cases,
> many of which have been around for a very long time, so I'm really
> interested to see what others are coming up with.)
>
> Jeremy
>
> On Mon, Apr 2, 2018 at 1:40 PM Martijn Verburg <martijnverburg at gmail.com>
> wrote:
>
>> This is a very welcome advancement - thank you! More NIH / custom LOC to
>> be removed from various projects I'm on :-)
>>
>> Cheers,
>> Martijn
>>
>> On 29 March 2018 at 19:12, <mark.reinhold at oracle.com> wrote:
>>
>> > New JEP Candidate: http://openjdk.java.net/jeps/331
>> >
>> > - Mark
>> >
>>
>
From magnus.ihse.bursie at oracle.com Tue Apr 3 10:18:56 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 3 Apr 2018 12:18:56 +0200
Subject: RFR: 8199736: Define WIN32_LEAN_AND_MEAN before including
windows.h
In-Reply-To: <d030055c-ce4b-e191-a6da-cc5e37b9ad0e@oracle.com>
References: <7F114FA8-59F0-42F1-A0B8-33D8C22DE81A@oracle.com>
<D12695CA-4408-41EC-86B6-26A0C4738BD3@oracle.com>
<C651EF47-0E7D-4819-85EE-3DB164318011@oracle.com>
<d030055c-ce4b-e191-a6da-cc5e37b9ad0e@oracle.com>
Message-ID: <8b8eff72-be6e-9b67-58b3-799de6ba10b4@oracle.com>
On 2018-03-26 01:03, David Holmes wrote:
> Hi Robin,
>
> On 23/03/2018 10:37 PM, Robin Westberg wrote:
>> Hi Kim & Erik,
>>
>> Certainly makes sense to define it from the build system, I?ve
>> updated the patch accordingly:
>>
>> Full: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.01/
>> <http://cr.openjdk.java.net/~rwestberg/8199736/webrev.01/>
>> Incremental:
>> http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00-01/
>> <http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00-01/>
>
> I'm a little unclear on the hotspot changes. If we define
> WIN32_LEAN_AND_MEAN then certain APIs like sockets are excluded from
> windows.h so we then have to include the specific header files like
> winsock2.h - is that right?
Using WIN32_LEAN_AND_MEAN is good industry practice. We already do so
for the JDK libraries. This trims down the number of files included by
windows.h to a more manageble number. Several years ago, Microsoft did
the (in my opinion) bad decision to let windows.h include a huge number
of interfaces, unless this macro was defined. Using WIN32_LEAN_AND_MEAN
and then explicitly including other API headers makes compilation
faster, and the intention of the code clearer.
On top of this, due to naming conflicts, it is not possible at all to
use winsock2.h unless you define WIN32_LEAN_AND_MEAN, windows.h will
then pull in the old v1 of winsock.
/Magnus
>
> src/hotspot/share/interpreter/bytecodes.cpp
>
> I'm curious about this change. u_short comes from types.h on
> non-Windows, is it simply missing on Windows (at least once we have
> WIN32_LEAN_AND_MEAN defined) ?
>
> src/hotspot/share/utilities/ostream.cpp
>
> 1029 #endif
> 1030 #if defined(_WINDOWS)
>
> Using elif could be marginally faster given the two sets of conditions
> are mutually exclusive.
>
> Thanks,
> David
>
>> (Not quite sure if the definition belongs where I put it or a bit
>> later where most other windows-specific JVM flags are defined, but
>> seemed reasonable to put it close to where it is defined for the JDK
>> libraries).
>>
>> Best regards,
>> Robin
>>
>>> On 22 Mar 2018, at 16:52, Kim Barrett <kim.barrett at oracle.com> wrote:
>>>
>>>> On Mar 22, 2018, at 10:34 AM, Robin Westberg
>>>> <robin.westberg at oracle.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Please review the following change that defines WIN32_LEAN_AND_MEAN
>>>> [1] before including windows.h. This marginally improves build
>>>> times, and makes it possible to include winsock2.h.
>>>>
>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8199736
>>>> <https://bugs.openjdk.java.net/browse/JDK-8199736>
>>>> Webrev: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00/
>>>> <http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00/>
>>>> Testing: hs-tier1
>>>>
>>>> Best regards,
>>>> Robin
>>>>
>>>> [1]
>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa383745%28v=vs.85%29.aspx#faster_builds_with_smaller_header_files
>>>> <https://msdn.microsoft.com/en-us/library/windows/desktop/aa383745(v=vs.85).aspx#faster_builds_with_smaller_header_files>
>>>>
>>>
>>> I think the addition of the WIN32_LEAN_AND_MEAN definition should be
>>> done through the build
>>> system, so that it applies everywhere.
>>>
>>
From magnus.ihse.bursie at oracle.com Tue Apr 3 10:20:21 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 3 Apr 2018 12:20:21 +0200
Subject: RFR (XL) 8081519 Split globals.hpp to factor out the Flag class
In-Reply-To: <8c2d6984-befe-bd10-7e2d-9c486e504a90@oracle.com>
References: <D6E4A4E8-8356-4694-BD9C-03AB5FA5BC65@oracle.com>
<8c2d6984-befe-bd10-7e2d-9c486e504a90@oracle.com>
Message-ID: <ede090c6-c5b0-67e0-ae15-c452fb539f2b@oracle.com>
On 2018-04-03 12:13, Magnus Ihse Bursie wrote:
> On 2018-03-29 21:01, Gerard Ziemski wrote:
>> Hi all,
>>
>> Please review this large and tedious (sorry), but simple fix that
>> accomplishes the following:
>>
>> #1 factor out the command option flag related APIs out of
>> globals.hpp/.cpp into its own dedicated files, i.e. jvmFlag.hpp/.cpp
>> #2 merge Flag (too generic name) and CommandLineFlag classes and
>> rename them as JVMFlag
>> #3 cleanup globals.hpp includes originally added by the JEP-245
>>
>> Note: the renamed file retain their history, but one needs to add
>> ?follow? flag, ex. ?hg log -f file?
>>
>> https://bugs.openjdk.java.net/browse/JDK-8081519
>> http://cr.openjdk.java.net/~gziemski/8081519_rev1
>
> Hi Gerard,
>
> More or less by chance I looked at a random file in your review.
... and the "random" file, perhaps I should tell you, is the new
jvmFlag.cpp. (Also seems to be fore jvmFlag.hpp.)
/Magnus
> I noticed that the copyright line does not follow the Oracle standard:
> 2? * Copyright (c) 2018 Oracle and/or its affiliates. All rights
> reserved.
>
> should be:
> 2? * Copyright (c) 2018, Oracle and/or its affiliates. All rights
> reserved.
>
> /Your friendly typo detector. :)
>
>>
>> Passes Mach5 hs_tier1-tier5,
>> jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges tests.
>>
>>
>> cheers
>
From shade at redhat.com Tue Apr 3 11:59:47 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 3 Apr 2018 13:59:47 +0200
Subject: RFR(XS): JDK-8199780: SetMemory0 and CopyMemory0 in unsafe.cpp
need to resolve their operands
In-Reply-To: <f586e115-451c-e541-6fee-4c1b305774c3@redhat.com>
References: <00c5000d-3e1f-b0cd-5426-c8b14d7516c7@redhat.com>
<5AB0E0D2.7090303@oracle.com>
<20b2bcd2-66f9-f80d-4eb9-bd0ee44d5261@redhat.com>
<5AB0E9BA.5000002@oracle.com>
<15133453-3d69-020f-780c-b04c5f820bb8@redhat.com>
<5AB135F6.3020508@oracle.com>
<3b8ce496-c053-4dc0-ff54-ccd9a6e74198@redhat.com>
<f586e115-451c-e541-6fee-4c1b305774c3@redhat.com>
Message-ID: <cd8ef246-4139-ee97-f820-14f9a13c9869@redhat.com>
On 03/28/2018 03:55 PM, Roman Kennke wrote:
> Am 21.03.2018 um 20:18 schrieb Roman Kennke:
>>>
>>>> Diff:
>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199780/webrev.01.diff/
>>>> Full:
>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199780/webrev.01/
Looks good.
-Aleksey
From rkennke at redhat.com Tue Apr 3 13:34:35 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 3 Apr 2018 15:34:35 +0200
Subject: RFR(XS): JDK-8199780: SetMemory0 and CopyMemory0 in unsafe.cpp
need to resolve their operands
In-Reply-To: <cd8ef246-4139-ee97-f820-14f9a13c9869@redhat.com>
References: <00c5000d-3e1f-b0cd-5426-c8b14d7516c7@redhat.com>
<5AB0E0D2.7090303@oracle.com>
<20b2bcd2-66f9-f80d-4eb9-bd0ee44d5261@redhat.com>
<5AB0E9BA.5000002@oracle.com>
<15133453-3d69-020f-780c-b04c5f820bb8@redhat.com>
<5AB135F6.3020508@oracle.com>
<3b8ce496-c053-4dc0-ff54-ccd9a6e74198@redhat.com>
<f586e115-451c-e541-6fee-4c1b305774c3@redhat.com>
<cd8ef246-4139-ee97-f820-14f9a13c9869@redhat.com>
Message-ID: <f48ea21c-b6cc-a105-628c-2690d00c2d1c@redhat.com>
Am 03.04.2018 um 13:59 schrieb Aleksey Shipilev:
> On 03/28/2018 03:55 PM, Roman Kennke wrote:
>> Am 21.03.2018 um 20:18 schrieb Roman Kennke:
>>>>
>>>>> Diff:
>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199780/webrev.01.diff/
>>>>> Full:
>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199780/webrev.01/
>
> Looks good.
>
> -Aleksey
>
Thanks Aleksey!
Unfortunately, testing came back with UNSTABLE, but it doesn't look like
related to this change (see below). Can somebody advice me what to do?
Thanks, Roman
Build Details: 2018-04-03-1240382.roman.source
0 Failed Tests
Mach5 Tasks Results Summary
EXECUTED_WITH_FAILURE: 14
KILLED: 0
NA: 0
UNABLE_TO_RUN: 69
PASSED: 0
FAILED: 0
Build
14 Not run
build_jdk_linux-linux-x64-linux-x64-build-0 error while
building, return value: 2
build_jdk_linux-linux-x64-debug-linux-x64-build-1 error
while building, return value: 2
build_jdk_linux-linux-x64-open-linux-x64-build-2 error while
building, return value: 2
build_jdk_linux-linux-x64-open-debug-linux-x64-build-3 error
while building, return value: 2
build_jdk_macosx-macosx-x64-macosx-x64-build-4 error while
building, return value: 2
build_jdk_macosx-macosx-x64-debug-macosx-x64-build-5 error
while building, return value: 2
build_jdk_macosx-macosx-x64-open-macosx-x64-build-6 error
while building, return value: 2
build_jdk_macosx-macosx-x64-open-debug-macosx-x64-build-7
error while building, return value: 2
build_jdk_solaris-solaris-sparcv9-solaris-sparcv9-build-8
error while building, return value: 2
build_jdk_solaris-solaris-sparcv9-debug-solaris-sparcv9-build-9 error
while building, return value: 2
See all 14...
Test
69 Not run
tier1-product-jdk_closed_test_hotspot_jtreg_tier1_common-linux-x64-20
Dependency task failed:
mach5...8-build_jdk_linux-linux-x64-linux-x64-build-0
tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_common-linux-x64-debug-56
Dependency task failed:
mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
tier1-product-jdk_closed_test_hotspot_jtreg_tier1_common-macosx-x64-21
Dependency task failed:
mach5...uild_jdk_macosx-macosx-x64-macosx-x64-build-4
tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_common-macosx-x64-debug-57
Dependency task failed:
mach5...dk_macosx-macosx-x64-debug-macosx-x64-build-5
tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-70
Dependency task failed:
mach5...laris-solaris-sparcv9-solaris-sparcv9-build-8
tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-71
Dependency task failed:
mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9
tier1-product-jdk_closed_test_hotspot_jtreg_tier1_common-windows-x64-22
Dependency task failed: mM15jYAzw
tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_common-windows-x64-debug-58
Dependency task failed: mM15jYAAw
tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_compiler_closed-linux-x64-debug-59
Dependency task failed:
mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_compiler_closed-macosx-x64-debug-60
Dependency task failed:
mach5...dk_macosx-macosx-x64-debug-macosx-x64-build-5
See all 69...
From zgu at redhat.com Tue Apr 3 13:44:05 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 3 Apr 2018 09:44:05 -0400
Subject: RFR(XS): JDK-8199780: SetMemory0 and CopyMemory0 in unsafe.cpp
need to resolve their operands
In-Reply-To: <f48ea21c-b6cc-a105-628c-2690d00c2d1c@redhat.com>
References: <00c5000d-3e1f-b0cd-5426-c8b14d7516c7@redhat.com>
<5AB0E0D2.7090303@oracle.com>
<20b2bcd2-66f9-f80d-4eb9-bd0ee44d5261@redhat.com>
<5AB0E9BA.5000002@oracle.com>
<15133453-3d69-020f-780c-b04c5f820bb8@redhat.com>
<5AB135F6.3020508@oracle.com>
<3b8ce496-c053-4dc0-ff54-ccd9a6e74198@redhat.com>
<f586e115-451c-e541-6fee-4c1b305774c3@redhat.com>
<cd8ef246-4139-ee97-f820-14f9a13c9869@redhat.com>
<f48ea21c-b6cc-a105-628c-2690d00c2d1c@redhat.com>
Message-ID: <87259431-04bb-a863-a842-f2adb639c765@redhat.com>
Seems oopDesc::is_null() no longer exists.
-Zhengyu
On 04/03/2018 09:34 AM, Roman Kennke wrote:
> Am 03.04.2018 um 13:59 schrieb Aleksey Shipilev:
>> On 03/28/2018 03:55 PM, Roman Kennke wrote:
>>> Am 21.03.2018 um 20:18 schrieb Roman Kennke:
>>>>>
>>>>>> Diff:
>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199780/webrev.01.diff/
>>>>>> Full:
>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199780/webrev.01/
>>
>> Looks good.
>>
>> -Aleksey
>>
>
> Thanks Aleksey!
>
> Unfortunately, testing came back with UNSTABLE, but it doesn't look like
> related to this change (see below). Can somebody advice me what to do?
>
> Thanks, Roman
>
>
>
> Build Details: 2018-04-03-1240382.roman.source
> 0 Failed Tests
> Mach5 Tasks Results Summary
>
> EXECUTED_WITH_FAILURE: 14
> KILLED: 0
> NA: 0
> UNABLE_TO_RUN: 69
> PASSED: 0
> FAILED: 0
> Build
>
> 14 Not run
> build_jdk_linux-linux-x64-linux-x64-build-0 error while
> building, return value: 2
> build_jdk_linux-linux-x64-debug-linux-x64-build-1 error
> while building, return value: 2
> build_jdk_linux-linux-x64-open-linux-x64-build-2 error while
> building, return value: 2
> build_jdk_linux-linux-x64-open-debug-linux-x64-build-3 error
> while building, return value: 2
> build_jdk_macosx-macosx-x64-macosx-x64-build-4 error while
> building, return value: 2
> build_jdk_macosx-macosx-x64-debug-macosx-x64-build-5 error
> while building, return value: 2
> build_jdk_macosx-macosx-x64-open-macosx-x64-build-6 error
> while building, return value: 2
> build_jdk_macosx-macosx-x64-open-debug-macosx-x64-build-7
> error while building, return value: 2
> build_jdk_solaris-solaris-sparcv9-solaris-sparcv9-build-8
> error while building, return value: 2
>
> build_jdk_solaris-solaris-sparcv9-debug-solaris-sparcv9-build-9 error
> while building, return value: 2
> See all 14...
>
> Test
>
> 69 Not run
>
> tier1-product-jdk_closed_test_hotspot_jtreg_tier1_common-linux-x64-20
> Dependency task failed:
> mach5...8-build_jdk_linux-linux-x64-linux-x64-build-0
>
> tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_common-linux-x64-debug-56
> Dependency task failed:
> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
>
> tier1-product-jdk_closed_test_hotspot_jtreg_tier1_common-macosx-x64-21
> Dependency task failed:
> mach5...uild_jdk_macosx-macosx-x64-macosx-x64-build-4
>
> tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_common-macosx-x64-debug-57
> Dependency task failed:
> mach5...dk_macosx-macosx-x64-debug-macosx-x64-build-5
>
> tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-70
> Dependency task failed:
> mach5...laris-solaris-sparcv9-solaris-sparcv9-build-8
>
> tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-71
> Dependency task failed:
> mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9
>
> tier1-product-jdk_closed_test_hotspot_jtreg_tier1_common-windows-x64-22
> Dependency task failed: mM15jYAzw
>
> tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_common-windows-x64-debug-58
> Dependency task failed: mM15jYAAw
>
> tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_compiler_closed-linux-x64-debug-59
> Dependency task failed:
> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
>
> tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_compiler_closed-macosx-x64-debug-60
> Dependency task failed:
> mach5...dk_macosx-macosx-x64-debug-macosx-x64-build-5
> See all 69...
>
>
>
From rkennke at redhat.com Tue Apr 3 13:58:08 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 3 Apr 2018 15:58:08 +0200
Subject: RFR(XS): JDK-8199780: SetMemory0 and CopyMemory0 in unsafe.cpp
need to resolve their operands
In-Reply-To: <87259431-04bb-a863-a842-f2adb639c765@redhat.com>
References: <00c5000d-3e1f-b0cd-5426-c8b14d7516c7@redhat.com>
<5AB0E0D2.7090303@oracle.com>
<20b2bcd2-66f9-f80d-4eb9-bd0ee44d5261@redhat.com>
<5AB0E9BA.5000002@oracle.com>
<15133453-3d69-020f-780c-b04c5f820bb8@redhat.com>
<5AB135F6.3020508@oracle.com>
<3b8ce496-c053-4dc0-ff54-ccd9a6e74198@redhat.com>
<f586e115-451c-e541-6fee-4c1b305774c3@redhat.com>
<cd8ef246-4139-ee97-f820-14f9a13c9869@redhat.com>
<f48ea21c-b6cc-a105-628c-2690d00c2d1c@redhat.com>
<87259431-04bb-a863-a842-f2adb639c765@redhat.com>
Message-ID: <5fcfa7bb-7853-4951-1d53-474e0be85111@redhat.com>
Duh. Thanks Zhengyu for spotting this.
Can you please ack this rather trivial change:
Differential:
http://cr.openjdk.java.net/~rkennke/JDK-8199780/webrev.02.diff/
Full:
http://cr.openjdk.java.net/~rkennke/JDK-8199780/webrev.02/
I re-submitted the same change for testing.
Thanks, Roman
> Seems oopDesc::is_null() no longer exists.
>
> -Zhengyu
>
> On 04/03/2018 09:34 AM, Roman Kennke wrote:
>> Am 03.04.2018 um 13:59 schrieb Aleksey Shipilev:
>>> On 03/28/2018 03:55 PM, Roman Kennke wrote:
>>>> Am 21.03.2018 um 20:18 schrieb Roman Kennke:
>>>>>>
>>>>>>> Diff:
>>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199780/webrev.01.diff/
>>>>>>> Full:
>>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8199780/webrev.01/
>>>
>>> Looks good.
>>>
>>> -Aleksey
>>>
>>
>> Thanks Aleksey!
>>
>> Unfortunately, testing came back with UNSTABLE, but it doesn't look like
>> related to this change (see below). Can somebody advice me what to do?
>>
>> Thanks, Roman
>>
>>
>>
>> Build Details: 2018-04-03-1240382.roman.source
>> 0 Failed Tests
>> Mach5 Tasks Results Summary
>>
>> ???? EXECUTED_WITH_FAILURE: 14
>> ???? KILLED: 0
>> ???? NA: 0
>> ???? UNABLE_TO_RUN: 69
>> ???? PASSED: 0
>> ???? FAILED: 0
>> ???? Build
>>
>> ???????? 14 Not run
>> ???????????? build_jdk_linux-linux-x64-linux-x64-build-0 error while
>> building, return value: 2
>> ???????????? build_jdk_linux-linux-x64-debug-linux-x64-build-1 error
>> while building, return value: 2
>> ???????????? build_jdk_linux-linux-x64-open-linux-x64-build-2 error while
>> building, return value: 2
>> ???????????? build_jdk_linux-linux-x64-open-debug-linux-x64-build-3 error
>> while building, return value: 2
>> ???????????? build_jdk_macosx-macosx-x64-macosx-x64-build-4 error while
>> building, return value: 2
>> ???????????? build_jdk_macosx-macosx-x64-debug-macosx-x64-build-5 error
>> while building, return value: 2
>> ???????????? build_jdk_macosx-macosx-x64-open-macosx-x64-build-6 error
>> while building, return value: 2
>> ???????????? build_jdk_macosx-macosx-x64-open-debug-macosx-x64-build-7
>> error while building, return value: 2
>> ???????????? build_jdk_solaris-solaris-sparcv9-solaris-sparcv9-build-8
>> error while building, return value: 2
>>
>> build_jdk_solaris-solaris-sparcv9-debug-solaris-sparcv9-build-9 error
>> while building, return value: 2
>> ???????????? See all 14...
>>
>> ???? Test
>>
>> ???????? 69 Not run
>>
>> tier1-product-jdk_closed_test_hotspot_jtreg_tier1_common-linux-x64-20
>> Dependency task failed:
>> mach5...8-build_jdk_linux-linux-x64-linux-x64-build-0
>>
>> tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_common-linux-x64-debug-56
>> Dependency task failed:
>> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
>>
>> tier1-product-jdk_closed_test_hotspot_jtreg_tier1_common-macosx-x64-21
>> Dependency task failed:
>> mach5...uild_jdk_macosx-macosx-x64-macosx-x64-build-4
>>
>> tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_common-macosx-x64-debug-57
>>
>> Dependency task failed:
>> mach5...dk_macosx-macosx-x64-debug-macosx-x64-build-5
>>
>> tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-70
>>
>> Dependency task failed:
>> mach5...laris-solaris-sparcv9-solaris-sparcv9-build-8
>>
>> tier1-solaris-sparc-jdk_closed_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-71
>>
>> Dependency task failed:
>> mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9
>>
>> tier1-product-jdk_closed_test_hotspot_jtreg_tier1_common-windows-x64-22
>> Dependency task failed: mM15jYAzw
>>
>> tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_common-windows-x64-debug-58
>>
>> Dependency task failed: mM15jYAAw
>>
>> tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_compiler_closed-linux-x64-debug-59
>>
>> Dependency task failed:
>> mach5...d_jdk_linux-linux-x64-debug-linux-x64-build-1
>>
>> tier1-debug-jdk_closed_test_hotspot_jtreg_tier1_compiler_closed-macosx-x64-debug-60
>>
>> Dependency task failed:
>> mach5...dk_macosx-macosx-x64-debug-macosx-x64-build-5
>> ???????????? See all 69...
>>
>>
>>
From shade at redhat.com Tue Apr 3 13:58:44 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 3 Apr 2018 15:58:44 +0200
Subject: RFR(XS): JDK-8199780: SetMemory0 and CopyMemory0 in unsafe.cpp
need to resolve their operands
In-Reply-To: <5fcfa7bb-7853-4951-1d53-474e0be85111@redhat.com>
References: <00c5000d-3e1f-b0cd-5426-c8b14d7516c7@redhat.com>
<5AB0E0D2.7090303@oracle.com>
<20b2bcd2-66f9-f80d-4eb9-bd0ee44d5261@redhat.com>
<5AB0E9BA.5000002@oracle.com>
<15133453-3d69-020f-780c-b04c5f820bb8@redhat.com>
<5AB135F6.3020508@oracle.com>
<3b8ce496-c053-4dc0-ff54-ccd9a6e74198@redhat.com>
<f586e115-451c-e541-6fee-4c1b305774c3@redhat.com>
<cd8ef246-4139-ee97-f820-14f9a13c9869@redhat.com>
<f48ea21c-b6cc-a105-628c-2690d00c2d1c@redhat.com>
<87259431-04bb-a863-a842-f2adb639c765@redhat.com>
<5fcfa7bb-7853-4951-1d53-474e0be85111@redhat.com>
Message-ID: <149fa9b4-e8cd-544d-f64d-507bdbccbaf3@redhat.com>
On 04/03/2018 03:58 PM, Roman Kennke wrote:
> Duh. Thanks Zhengyu for spotting this.
>
> Can you please ack this rather trivial change:
>
> Differential:
> http://cr.openjdk.java.net/~rkennke/JDK-8199780/webrev.02.diff/
> Full:
> http://cr.openjdk.java.net/~rkennke/JDK-8199780/webrev.02/
Yup, still good.
-Aleksey
From shade at redhat.com Tue Apr 3 14:00:30 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 3 Apr 2018 16:00:30 +0200
Subject: RFR (XS) 8200608: Build failures after JDK-8191101 (Show register
content in hs-err file on assert)
In-Reply-To: <f159b52c-ef24-344f-5df9-0fe9b9be2d4f@oracle.com>
References: <c16534f7-3c96-407b-7b37-e2676ccc6d24@redhat.com>
<f159b52c-ef24-344f-5df9-0fe9b9be2d4f@oracle.com>
Message-ID: <337d9941-0728-c734-dc7a-a86efe555063@redhat.com>
I believe that is a simple overlook. Thomas (Stuefe)?
-Aleksey
On 04/03/2018 11:53 AM, David Holmes wrote:
> Seems trivial.
>
> I have to wonder why jlong was ever used in the first place ???
>
> David
>
> On 3/04/2018 7:18 PM, Aleksey Shipilev wrote:
>> Bug:
>> ? https://bugs.openjdk.java.net/browse/JDK-8200608
>>
>> "jlong" is not "intx" in x86_32. The fix is simple, because os::current_thread_id() actually returns
>> intx. I think the fix falls under triviality rule.
>>
>> --- a/src/hotspot/share/utilities/debug.cpp???? Tue Apr 03 10:27:46 2018 +0200
>> +++ b/src/hotspot/share/utilities/debug.cpp???? Tue Apr 03 11:04:01 2018 +0200
>> @@ -731,7 +731,7 @@
>> ????? os::protect_memory((char*)g_assert_poison, os::vm_page_size(), os::MEM_PROT_RWX);
>> ????? // Store Context away.
>> ????? if (ucVoid) {
>> -????? const jlong my_tid = os::current_thread_id();
>> +????? const intx my_tid = os::current_thread_id();
>> ??????? if (Atomic::cmpxchg(my_tid, &g_asserting_thread, (intx)0) == 0) {
>> ????????? if (store_context(ucVoid)) {
>> ??????????? g_assertion_context = &g_stored_assertion_context;
>>
>>
>> Testing: x86_32 and x86_64 builds
>>
>> Thanks,
>> -Aleksey
>>
From zgu at redhat.com Tue Apr 3 14:01:25 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 3 Apr 2018 10:01:25 -0400
Subject: RFR(XS): JDK-8199780: SetMemory0 and CopyMemory0 in unsafe.cpp
need to resolve their operands
In-Reply-To: <149fa9b4-e8cd-544d-f64d-507bdbccbaf3@redhat.com>
References: <00c5000d-3e1f-b0cd-5426-c8b14d7516c7@redhat.com>
<5AB0E0D2.7090303@oracle.com>
<20b2bcd2-66f9-f80d-4eb9-bd0ee44d5261@redhat.com>
<5AB0E9BA.5000002@oracle.com>
<15133453-3d69-020f-780c-b04c5f820bb8@redhat.com>
<5AB135F6.3020508@oracle.com>
<3b8ce496-c053-4dc0-ff54-ccd9a6e74198@redhat.com>
<f586e115-451c-e541-6fee-4c1b305774c3@redhat.com>
<cd8ef246-4139-ee97-f820-14f9a13c9869@redhat.com>
<f48ea21c-b6cc-a105-628c-2690d00c2d1c@redhat.com>
<87259431-04bb-a863-a842-f2adb639c765@redhat.com>
<5fcfa7bb-7853-4951-1d53-474e0be85111@redhat.com>
<149fa9b4-e8cd-544d-f64d-507bdbccbaf3@redhat.com>
Message-ID: <046748a8-7c3b-f189-3101-5bd33ffad982@redhat.com>
Looks good to me too.
-Zhengyu
On 04/03/2018 09:58 AM, Aleksey Shipilev wrote:
> On 04/03/2018 03:58 PM, Roman Kennke wrote:
>> Duh. Thanks Zhengyu for spotting this.
>>
>> Can you please ack this rather trivial change:
>>
>> Differential:
>> http://cr.openjdk.java.net/~rkennke/JDK-8199780/webrev.02.diff/
>> Full:
>> http://cr.openjdk.java.net/~rkennke/JDK-8199780/webrev.02/
>
> Yup, still good.
>
> -Aleksey
>
From boris.ulasevich at bell-sw.com Tue Apr 3 14:53:43 2018
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Tue, 3 Apr 2018 17:53:43 +0300
Subject: RFR 8200627: Broken build after JDK-8198949
Message-ID: <ee1738f9-dd7f-4f19-5b07-20854bdacada@bell-sw.com>
Hi,
Please review this change to fix ARM32 build after recent push:
Bug:
https://bugs.openjdk.java.net/browse/JDK-8200627
Webrev:
http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8200627/webrev.00/
Thanks,
Boris Ulasevich
From boris.ulasevich at bell-sw.com Tue Apr 3 14:55:04 2018
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Tue, 3 Apr 2018 17:55:04 +0300
Subject: RFR (S) 8200628: Broken build after JDK-8199809
Message-ID: <a4331f8f-9e7b-fde6-9fa5-27427eac7837@bell-sw.com>
Hi,
Please review this small change to fix ARM32 build after recent push.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8200628
Webrev:
http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8200628/webrev.00/
Thanks,
Boris Ulasevich
From gerard.ziemski at oracle.com Tue Apr 3 14:56:30 2018
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Tue, 3 Apr 2018 09:56:30 -0500
Subject: RFR (XL) 8081519 Split globals.hpp to factor out the Flag class
In-Reply-To: <ede090c6-c5b0-67e0-ae15-c452fb539f2b@oracle.com>
References: <D6E4A4E8-8356-4694-BD9C-03AB5FA5BC65@oracle.com>
<8c2d6984-befe-bd10-7e2d-9c486e504a90@oracle.com>
<ede090c6-c5b0-67e0-ae15-c452fb539f2b@oracle.com>
Message-ID: <BFEB43B9-103F-45C3-B4BD-034031696539@oracle.com>
Thank you Magnus for the catch!
cheers
> On Apr 3, 2018, at 5:20 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>
>
>
> On 2018-04-03 12:13, Magnus Ihse Bursie wrote:
>> On 2018-03-29 21:01, Gerard Ziemski wrote:
>>> Hi all,
>>>
>>> Please review this large and tedious (sorry), but simple fix that accomplishes the following:
>>>
>>> #1 factor out the command option flag related APIs out of globals.hpp/.cpp into its own dedicated files, i.e. jvmFlag.hpp/.cpp
>>> #2 merge Flag (too generic name) and CommandLineFlag classes and rename them as JVMFlag
>>> #3 cleanup globals.hpp includes originally added by the JEP-245
>>>
>>> Note: the renamed file retain their history, but one needs to add ?follow? flag, ex. ?hg log -f file?
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8081519
>>> http://cr.openjdk.java.net/~gziemski/8081519_rev1
>>
>> Hi Gerard,
>>
>> More or less by chance I looked at a random file in your review.
>
> ... and the "random" file, perhaps I should tell you, is the new jvmFlag.cpp. (Also seems to be fore jvmFlag.hpp.)
>
> /Magnus
>
>> I noticed that the copyright line does not follow the Oracle standard:
>> 2 * Copyright (c) 2018 Oracle and/or its affiliates. All rights reserved.
>>
>> should be:
>> 2 * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
>>
>> /Your friendly typo detector. :)
>>
>>>
>>> Passes Mach5 hs_tier1-tier5, jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges tests.
>>>
>>>
>>> cheers
>>
>
From shade at redhat.com Tue Apr 3 15:03:14 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 3 Apr 2018 17:03:14 +0200
Subject: RFR 8200627: Broken build after JDK-8198949
In-Reply-To: <ee1738f9-dd7f-4f19-5b07-20854bdacada@bell-sw.com>
References: <ee1738f9-dd7f-4f19-5b07-20854bdacada@bell-sw.com>
Message-ID: <a046b9ce-acbd-bfe9-65eb-4380737c63fc@redhat.com>
On 04/03/2018 04:53 PM, Boris Ulasevich wrote:
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8200627
>
> Webrev:
> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8200627/webrev.00/
This looks good to me. I don't think we have seen similar failures on x86_{32,64} and aarch64.
-Aleksey
From shade at redhat.com Tue Apr 3 15:06:05 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 3 Apr 2018 17:06:05 +0200
Subject: RFR (S) 8200628: Broken build after JDK-8199809
In-Reply-To: <a4331f8f-9e7b-fde6-9fa5-27427eac7837@bell-sw.com>
References: <a4331f8f-9e7b-fde6-9fa5-27427eac7837@bell-sw.com>
Message-ID: <76971cbe-85b6-cba4-2d76-6cdf539e8058@redhat.com>
On 04/03/2018 04:55 PM, Boris Ulasevich wrote:
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8200628
>
> Webrev:
> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8200628/webrev.00/
This looks good.
It seems "Interpreter::SignatureHandlerGenerator" is only present in interpreterRT_arm.cpp:
http://hg.openjdk.java.net/jdk/jdk/rev/d7df2dd501ce#l14.15
-Aleksey
From erik.osterlund at oracle.com Tue Apr 3 15:32:29 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Tue, 3 Apr 2018 17:32:29 +0200
Subject: RFR 8200627: Broken build after JDK-8198949
In-Reply-To: <ee1738f9-dd7f-4f19-5b07-20854bdacada@bell-sw.com>
References: <ee1738f9-dd7f-4f19-5b07-20854bdacada@bell-sw.com>
Message-ID: <5AC39E8D.9050205@oracle.com>
Hi,
Looks good. Thanks for fixing.
/Erik
On 2018-04-03 16:53, Boris Ulasevich wrote:
> Hi,
>
> Please review this change to fix ARM32 build after recent push:
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8200627
>
> Webrev:
> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8200627/webrev.00/
>
> Thanks,
> Boris Ulasevich
From coleen.phillimore at oracle.com Tue Apr 3 15:56:26 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 3 Apr 2018 11:56:26 -0400
Subject: RFR (S) 8200628: Broken build after JDK-8199809
In-Reply-To: <a4331f8f-9e7b-fde6-9fa5-27427eac7837@bell-sw.com>
References: <a4331f8f-9e7b-fde6-9fa5-27427eac7837@bell-sw.com>
Message-ID: <bb880216-4fcc-0008-727e-827f7ec93ff3@oracle.com>
Looks good to me.? Also trivial and can be pushed today.
thanks,
Coleen
On 4/3/18 10:55 AM, Boris Ulasevich wrote:
> Hi,
>
> Please review this small change to fix ARM32 build after recent push.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8200628
>
> Webrev:
> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8200628/webrev.00/
>
> Thanks,
> Boris Ulasevich
From leo.korinth at oracle.com Tue Apr 3 16:24:38 2018
From: leo.korinth at oracle.com (Leo Korinth)
Date: Tue, 3 Apr 2018 18:24:38 +0200
Subject: RFR: 8176717: GC log file handle leaked to child processes
In-Reply-To: <CAA-vtUxM2ED6MeLp3RvXXx8CY=1O73gAeT=qbhWQHKwcc9gv3A@mail.gmail.com>
References: <bcf5e1ca-ed60-127c-5765-98350909e38a@oracle.com>
<271f07b2-2a74-c5ff-7a7b-d9805929a23c@oracle.com>
<04b0987c-0de4-1e5e-52be-0c603c1fab10@oracle.com>
<4c216bb1-a3bf-e916-d07a-643431faa341@oracle.com>
<796998bd-78f5-1a2a-a38e-fc5da8f10b7a@oracle.com>
<CAA-vtUxM2ED6MeLp3RvXXx8CY=1O73gAeT=qbhWQHKwcc9gv3A@mail.gmail.com>
Message-ID: <7f6fc2dc-dd2b-06ef-895d-8b03308b985f@oracle.com>
Hi Thomas,
On 30/03/18 13:16, Thomas St?fe wrote:
> Hi Leo,
>
> looks okay. I stated my reservations against adding this function and
> the platform specific code in its current form before, but I can
> certainly live with this fix. It follows what we did in os::open(), so
> it is consistent in that matter.
Thanks for (what I understand is) a review approval. I am still open for
a different solution if you have one you feel for. Below are some
alternatives that we have talked about (or I have thought about).
Dividing the fix to os_windows/os_posix will not get rid of the #if and
splitting it between aix/bsd/linux/solaris/windows will make the
solution much bigger, redundant and arguably harder to maintain.
I could possibly change it to have a variable or function in each
architecture that holds only the mode string for fopen (or NULL for no
support) and in that way change the "#if" to an "if" and remove the
LINUX_ONLY("e") BSD_ONLY("e") WINDOWS_ONLY("N"). I dislike it because it
spreads the solution to more files, but at least it reduces the use of
the preprocessor.
I could try to get the mode flag through autoconf, but that seems _very_
hard -- does success of fopen really mean that the mode is supported or
merely ignored? I believe it to be undefined by the c standard :-(, It
seems even harder to do an autoconf runtime test for the feature.
I could leave it to be fixed (only) by core-libs, but that I feel is
wrong for several reasons:
- We have a corresponding fix in os::open that says that we should
auto-close on exec from hotspot to be sure. And I agree on that.
- core-libs might not be able to fix it for legacy reasons
- it does not protect from when JNI creates new processes (I guess it is
allowed)
I could make the change log-specific, but that makes little sense as if
I ought to do it in logging, I ought to do it on every fopen.
I was and still am hoping for more opinions to get a better solution or
at least a consensus on this solution. If I get none, I will continue
with the one I propose.
In the end, I will need a sponsor to eventually push the change.
/Leo
> Thanks for fixing this!
>
> Thomas
>
> (btw, I am not sure which of my "2" Per meant, since I accidentally
> miscounted my points in the earlier mail.)
>
>
>
>
>
> On Thu, Mar 29, 2018 at 5:41 PM, Leo Korinth <leo.korinth at oracle.com
> <mailto:leo.korinth at oracle.com>> wrote:
>
> On 23/03/18 20:03, Leo Korinth wrote:
>
> Hi!
>
> Cross-posting this to both hotspot-dev and hotspot-runtime-dev
> to get more attention. Sorry.
>
> Original mail conversation can be found here:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-March/030637.html
> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-March/030637.html>
>
> I need feedback to know how to continue.
>
> Thanks,
> Leo
>
>
> Hi!
>
> Below is a new webrev with Thomas' and Per's suggested name change
> from: os::fopen_retain(const char* path, const char* mode)
> to:? ?os::fopen(const char* path, const char* mode)
>
> Full webrev:
> http://cr.openjdk.java.net/~lkorinth/8176717/02/
> <http://cr.openjdk.java.net/~lkorinth/8176717/02/>
>
> Review and/or comments please!
>
> Thanks,
> Leo
>
>
From jeremymanson at google.com Tue Apr 3 17:07:20 2018
From: jeremymanson at google.com (Jeremy Manson)
Date: Tue, 03 Apr 2018 17:07:20 +0000
Subject: JEP 331: Low-Overhead Heap Profiling
In-Reply-To: <CAP7YuAQtG_4ZJCgoO4dJ+wjrRqnP9yMZcqMwLR5nbd_As9b=NQ@mail.gmail.com>
References: <20180329171223.64A4C1973B3@eggemoggin.niobe.net>
<CAP7YuARWgnVqMqAO711S0Kr2W-5d+9f1XSnGfMEJ16pFmBM9OA@mail.gmail.com>
<CAPYFHW1Cdvd9yoy=Hd8H=b87r=+b0PPLqi+zNZEzt7uvGty_2w@mail.gmail.com>
<CAP7YuAQtG_4ZJCgoO4dJ+wjrRqnP9yMZcqMwLR5nbd_As9b=NQ@mail.gmail.com>
Message-ID: <CAPYFHW2MJU75ScV9a39RJSASW_74FWy8vFBNZjvJKC7jMpoA8w@mail.gmail.com>
Thanks! No problem about the source status - just curious about the use
cases. That general kind of thing should be pretty easy to do without
bytecode rewriting with this JEP. Have you taken a close enough look at
the current state of it to figure out whether it does what you want?
Jeremy
On Tue, Apr 3, 2018 at 3:17 AM Martijn Verburg <martijnverburg at gmail.com>
wrote:
> Mainly closed source (sadly) tooling for jClarity customers. e.g. Various
> object allocation probes that can be byte code weaved in to detect and
> capture 'interesting' allocation patterns (such as humungous objects).
>
> Cheers,
> Martijn
>
> On 3 April 2018 at 00:04, Jeremy Manson <jeremymanson at google.com> wrote:
>
>> Hey Martijn,
>>
>> That's an interesting response. What did you build in this area?
>>
>> (In developing this project, we've been pretty focused on our use cases,
>> many of which have been around for a very long time, so I'm really
>> interested to see what others are coming up with.)
>>
>> Jeremy
>>
>> On Mon, Apr 2, 2018 at 1:40 PM Martijn Verburg <martijnverburg at gmail.com>
>> wrote:
>>
>>> This is a very welcome advancement - thank you! More NIH / custom LOC to
>>> be removed from various projects I'm on :-)
>>>
>>> Cheers,
>>> Martijn
>>>
>>> On 29 March 2018 at 19:12, <mark.reinhold at oracle.com> wrote:
>>>
>>> > New JEP Candidate: http://openjdk.java.net/jeps/331
>>> >
>>> > - Mark
>>> >
>>>
>>
>
From aph at redhat.com Tue Apr 3 17:28:40 2018
From: aph at redhat.com (Andrew Haley)
Date: Tue, 3 Apr 2018 18:28:40 +0100
Subject: AOT for AArch64: current status
In-Reply-To: <edaacf43-9be5-c029-99c8-1753d1c9f8b6@redhat.com>
References: <83f0e948-d002-6b71-e73f-6f65fce14e3b@redhat.com>
<15f51315-3497-6c01-2ecb-1f758762e99e@redhat.com>
<849a8fcf-85cd-b8c6-1134-9aea3877e9b7@redhat.com>
<2c42186a-523e-6912-6eb0-36c7ee2be09f@redhat.com>
<8b4a211e-44af-ed28-5abf-697d722771d1@redhat.com>
<97d96f0e-43b0-beca-3b31-3dabc6073f3a@redhat.com>
<8342caa0-e4d1-0250-02ab-c8f9cf8085bd@redhat.com>
<edaacf43-9be5-c029-99c8-1753d1c9f8b6@redhat.com>
Message-ID: <6ed685f0-c851-d12f-1788-a896f4e0d162@redhat.com>
I fixed a bug in Graal which was causing
compiler.aot.DeoptimizationTest to fail.
I fixed the bug which was causing assertion failures due to branch out
of range.
I pulled from the tip of Graal master. It should all be up to date
now.
All pushed to https://github.com/theRealAph/graal.git aarch64-branch-overflows
I'm still seeing some assertion failures, but they're not in my code
and I don't think they're anything to do with me. They all seem to do
with types not being registered. Updating Graal didn't help, so I
need to try to figure out why this isn't a problem on x86.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From erik.joelsson at oracle.com Tue Apr 3 17:30:48 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 3 Apr 2018 10:30:48 -0700
Subject: space.inline.hpp build failure
In-Reply-To: <CAF9Mjxnm3MdC+moxQYtOuT5m3TF0nX_EaVrzpozCWYV9WKFLYA@mail.gmail.com>
References: <CAF9Mjxnm3MdC+moxQYtOuT5m3TF0nX_EaVrzpozCWYV9WKFLYA@mail.gmail.com>
Message-ID: <5c17779e-c069-0f6b-de07-1a5784426d97@oracle.com>
Hello Peter,
Forwarding this to hotspot-dev as it's an issue with hotspot.
/Erik
On 2018-03-29 23:36, Peter Johnson wrote:
> When cross compiling either 9 or 10 to ARM with gcc 5.5.0, I get the
> following linker error:
> /tmp/cc7TKVtK.ltrans2.ltrans.o: In function
> `OffsetTableContigSpace::block_start_const(void const*) const':
> <artificial>:(.text+0x26e4): undefined reference to
> `BlockOffsetTable::block_start(void const*) const'
> /tmp/cc7TKVtK.ltrans13.ltrans.o: In function
> `OffsetTableContigSpace::verify() const':
> <artificial>:(.text+0x2ca6): undefined reference to
> `BlockOffsetTable::block_start(void const*) const'
> collect2: error: ld returned 1 exit status
>
> This appears to be due to a missing include in space.inline.hpp. Applying
> the following patch fixes the build for me.
>
> Thanks,
> Peter
>
> diff -r 5ab7a67bc155 src/share/vm/gc/shared/space.inline.hpp
> --- a/src/share/vm/gc/shared/space.inline.hpp Fri Sep 08 18:24:18 2017
> +0000
> +++ b/src/share/vm/gc/shared/space.inline.hpp Thu Mar 29 23:25:25 2018
> -0700
> @@ -26,6 +26,7 @@
> #define SHARE_VM_GC_SHARED_SPACE_INLINE_HPP
>
> #include "gc/serial/markSweep.inline.hpp"
> +#include "gc/shared/blockOffsetTable.inline.hpp"
> #include "gc/shared/collectedHeap.hpp"
> #include "gc/shared/generation.hpp"
> #include "gc/shared/space.hpp"
From thomas.stuefe at gmail.com Tue Apr 3 18:30:44 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 3 Apr 2018 20:30:44 +0200
Subject: RFR: 8176717: GC log file handle leaked to child processes
In-Reply-To: <7f6fc2dc-dd2b-06ef-895d-8b03308b985f@oracle.com>
References: <bcf5e1ca-ed60-127c-5765-98350909e38a@oracle.com>
<271f07b2-2a74-c5ff-7a7b-d9805929a23c@oracle.com>
<04b0987c-0de4-1e5e-52be-0c603c1fab10@oracle.com>
<4c216bb1-a3bf-e916-d07a-643431faa341@oracle.com>
<796998bd-78f5-1a2a-a38e-fc5da8f10b7a@oracle.com>
<CAA-vtUxM2ED6MeLp3RvXXx8CY=1O73gAeT=qbhWQHKwcc9gv3A@mail.gmail.com>
<7f6fc2dc-dd2b-06ef-895d-8b03308b985f@oracle.com>
Message-ID: <CAA-vtUzFu+aQZUzix2Oo=3eAPbT-KZmxTgbe_vHVkDNkGi+k7A@mail.gmail.com>
Hi Leo,
On Tue, Apr 3, 2018 at 6:24 PM, Leo Korinth <leo.korinth at oracle.com> wrote:
> Hi Thomas,
>
> On 30/03/18 13:16, Thomas St?fe wrote:
>
>> Hi Leo,
>>
>> looks okay. I stated my reservations against adding this function and the
>> platform specific code in its current form before, but I can certainly live
>> with this fix. It follows what we did in os::open(), so it is consistent in
>> that matter.
>>
>
> Thanks for (what I understand is) a review approval.
It was a fully approved review from my point. As I stated, I can live with
this fix. I am fine with you shipping this fix in its current form.
You cannot make everyone completely happy, nor is that even necessary. In
my eyes, the review process shall ensure that nothing gets submitted which
goes strongly against the grain or taste of reviewers or against the
community (e.g. like systemd). However, that process is not precise; there
will always be gray areas and many matters of taste.
Part of being reviewer is to know when to reign in ones own preferences for
the benefit of having a solution and not torturing the patch submitter more
than necessary. This is what I tried to convey here: it is not my solution
no. 1, but among the space of possible solutions it is one I can sure live
with.
So, whatever else I write below are just idle musings. In the end, I am
fine with this fix in its current form. Ship it.
I am still open for a different solution if you have one you feel for.
> Below are some alternatives that we have talked about (or I have thought
> about).
>
> Dividing the fix to os_windows/os_posix will not get rid of the #if and
> splitting it between aix/bsd/linux/solaris/windows will make the solution
> much bigger, redundant and arguably harder to maintain.
>
>
Yet this is what is usually done in hs coding - see e.g. in the case of
os::open(). The question of how many platform ifdefs are one-too-many and
at which point one starts to blossom out into platform specific files is a
matter of taste, and different reviewers have different pain barriers. I
think I am somewhere in the middle.
Also, I usually do "as the romans do" with regards to code. So, if I see
that the original code maintainers show strong preference for one side or
the other, I lean into the same side taste wise.
I could possibly change it to have a variable or function in each
> architecture that holds only the mode string for fopen (or NULL for no
> support) and in that way change the "#if" to an "if" and remove the
> LINUX_ONLY("e") BSD_ONLY("e") WINDOWS_ONLY("N"). I dislike it because it
> spreads the solution to more files, but at least it reduces the use of the
> preprocessor.
>
>
Dislike it too.
> I could try to get the mode flag through autoconf, but that seems _very_
> hard -- does success of fopen really mean that the mode is supported or
> merely ignored? I believe it to be undefined by the c standard :-(, It
> seems even harder to do an autoconf runtime test for the feature.
>
>
Hard to maintain, yes, and also unnecessary.
> I could leave it to be fixed (only) by core-libs, but that I feel is wrong
> for several reasons:
> - We have a corresponding fix in os::open that says that we should
> auto-close on exec from hotspot to be sure. And I agree on that.
> - core-libs might not be able to fix it for legacy reasons
> - it does not protect from when JNI creates new processes (I guess it is
> allowed)
>
> I could make the change log-specific, but that makes little sense as if I
> ought to do it in logging, I ought to do it on every fopen.
>
> I was and still am hoping for more opinions to get a better solution or at
> least a consensus on this solution. If I get none, I will continue with the
> one I propose.
>
> In the end, I will need a sponsor to eventually push the change.
>
>
Oh right, you are not committer.
I am currently in vacation, so if I am to push this you will have to wait
2-3 weeks. Also, I am outside Oracle - while we outsiders can sponsor and
push now too, it may still go faster if you ask someone from Oracle to
sponsor this.
Kind Regards, and thanks for your work,
Thomas
> /Leo
>
> Thanks for fixing this!
>>
>> Thomas
>>
>> (btw, I am not sure which of my "2" Per meant, since I accidentally
>> miscounted my points in the earlier mail.)
>>
>>
>>
>>
>>
>> On Thu, Mar 29, 2018 at 5:41 PM, Leo Korinth <leo.korinth at oracle.com
>> <mailto:leo.korinth at oracle.com>> wrote:
>>
>> On 23/03/18 20:03, Leo Korinth wrote:
>>
>> Hi!
>>
>> Cross-posting this to both hotspot-dev and hotspot-runtime-dev
>> to get more attention. Sorry.
>>
>> Original mail conversation can be found here:
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-Marc
>> h/030637.html
>> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-Mar
>> ch/030637.html>
>>
>> I need feedback to know how to continue.
>>
>> Thanks,
>> Leo
>>
>>
>> Hi!
>>
>> Below is a new webrev with Thomas' and Per's suggested name change
>> from: os::fopen_retain(const char* path, const char* mode)
>> to: os::fopen(const char* path, const char* mode)
>>
>> Full webrev:
>> http://cr.openjdk.java.net/~lkorinth/8176717/02/
>> <http://cr.openjdk.java.net/~lkorinth/8176717/02/>
>>
>> Review and/or comments please!
>>
>> Thanks,
>> Leo
>>
>>
>>
From martijnverburg at gmail.com Tue Apr 3 20:43:43 2018
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 3 Apr 2018 21:43:43 +0100
Subject: JEP 331: Low-Overhead Heap Profiling
In-Reply-To: <CAPYFHW2MJU75ScV9a39RJSASW_74FWy8vFBNZjvJKC7jMpoA8w@mail.gmail.com>
References: <20180329171223.64A4C1973B3@eggemoggin.niobe.net>
<CAP7YuARWgnVqMqAO711S0Kr2W-5d+9f1XSnGfMEJ16pFmBM9OA@mail.gmail.com>
<CAPYFHW1Cdvd9yoy=Hd8H=b87r=+b0PPLqi+zNZEzt7uvGty_2w@mail.gmail.com>
<CAP7YuAQtG_4ZJCgoO4dJ+wjrRqnP9yMZcqMwLR5nbd_As9b=NQ@mail.gmail.com>
<CAPYFHW2MJU75ScV9a39RJSASW_74FWy8vFBNZjvJKC7jMpoA8w@mail.gmail.com>
Message-ID: <CAP7YuAQO260xxeeUs9LM0WKW=EW=6PzBEznBPwyz6iLFqJrAFg@mail.gmail.com>
Hi Jeremy,
Yes we think it will cover our use cases. Our workflow is currently either
to manually attach an agent or dynamically attach an agent with
functionality similar to https://github.com/google/allocation-instrumenter
(I suspect you know that well!). The dynamic one if some sort of SLA has
been breached. It's our idea of a light-weight (as much as you can) on
demand allocation profiler.
It's just the dynamically attaching agent use case that will no longer work
for us (separate issue modularity / security), although the impact of that
is now also lessening as our customers will become more comfortable having
a permanent Java agent if it only does light weight things (one of our USPs
is being more lightweight than traditional 'gather all of the data all of
the time' approaches).
All in all this JEP seems really well designed to us, we just need to go
attack some real world use cases with it.
Cheers,
Martijn
On 3 April 2018 at 18:07, Jeremy Manson <jeremymanson at google.com> wrote:
>
> Thanks! No problem about the source status - just curious about the use
> cases. That general kind of thing should be pretty easy to do without
> bytecode rewriting with this JEP. Have you taken a close enough look at
> the current state of it to figure out whether it does what you want?
>
> Jeremy
>
> On Tue, Apr 3, 2018 at 3:17 AM Martijn Verburg <martijnverburg at gmail.com>
> wrote:
>
>> Mainly closed source (sadly) tooling for jClarity customers. e.g.
>> Various object allocation probes that can be byte code weaved in to detect
>> and capture 'interesting' allocation patterns (such as humungous objects).
>>
>> Cheers,
>> Martijn
>>
>> On 3 April 2018 at 00:04, Jeremy Manson <jeremymanson at google.com> wrote:
>>
>>> Hey Martijn,
>>>
>>> That's an interesting response. What did you build in this area?
>>>
>>> (In developing this project, we've been pretty focused on our use cases,
>>> many of which have been around for a very long time, so I'm really
>>> interested to see what others are coming up with.)
>>>
>>> Jeremy
>>>
>>> On Mon, Apr 2, 2018 at 1:40 PM Martijn Verburg <martijnverburg at gmail.com>
>>> wrote:
>>>
>>>> This is a very welcome advancement - thank you! More NIH / custom LOC
>>>> to
>>>> be removed from various projects I'm on :-)
>>>>
>>>> Cheers,
>>>> Martijn
>>>>
>>>> On 29 March 2018 at 19:12, <mark.reinhold at oracle.com> wrote:
>>>>
>>>> > New JEP Candidate: http://openjdk.java.net/jeps/331
>>>> >
>>>> > - Mark
>>>> >
>>>>
>>>
>>
From kim.barrett at oracle.com Tue Apr 3 21:00:36 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 3 Apr 2018 17:00:36 -0400
Subject: RFR: 8200630: Globally suppress Visual Studio warning C4351
Message-ID: <AE209A4D-CC94-4E98-AF2D-56D1EE6BA31B@oracle.com>
Please review this change to globally suppress Visual Studio warning
C4351. This warning is entirely useless to us. All it does is
interfere with writing clear and correct code. (See bug for more
details.)
This change also removes the one existing occurrence of local
suppression of this warning, which is no longer needed.
CR:
https://bugs.openjdk.java.net/browse/JDK-8200630
Webrev:
http://cr.openjdk.java.net/~kbarrett/8200630/open.00/
Testing:
Build on all Oracle supported platforms, and ran hs-tier1.
From george.triantafillou at oracle.com Tue Apr 3 21:53:06 2018
From: george.triantafillou at oracle.com (George Triantafillou)
Date: Tue, 3 Apr 2018 17:53:06 -0400
Subject: RFR: 8200630: Globally suppress Visual Studio warning C4351
In-Reply-To: <AE209A4D-CC94-4E98-AF2D-56D1EE6BA31B@oracle.com>
References: <AE209A4D-CC94-4E98-AF2D-56D1EE6BA31B@oracle.com>
Message-ID: <c8678bc9-56f5-6e63-998f-92a49b0e14eb@oracle.com>
Hi Kim,
This looks good.
-George
On 4/3/2018 5:00 PM, Kim Barrett wrote:
> Please review this change to globally suppress Visual Studio warning
> C4351. This warning is entirely useless to us. All it does is
> interfere with writing clear and correct code. (See bug for more
> details.)
>
> This change also removes the one existing occurrence of local
> suppression of this warning, which is no longer needed.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8200630
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8200630/open.00/
>
> Testing:
> Build on all Oracle supported platforms, and ran hs-tier1.
>
From kim.barrett at oracle.com Tue Apr 3 23:22:17 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 3 Apr 2018 19:22:17 -0400
Subject: RFR: 8200630: Globally suppress Visual Studio warning C4351
In-Reply-To: <c8678bc9-56f5-6e63-998f-92a49b0e14eb@oracle.com>
References: <AE209A4D-CC94-4E98-AF2D-56D1EE6BA31B@oracle.com>
<c8678bc9-56f5-6e63-998f-92a49b0e14eb@oracle.com>
Message-ID: <EA81723C-E499-4A3F-AEE4-3A7309CB2423@oracle.com>
> On Apr 3, 2018, at 5:53 PM, George Triantafillou <george.triantafillou at oracle.com> wrote:
>
> Hi Kim,
>
> This looks good.
Thanks.
> -George
>
> On 4/3/2018 5:00 PM, Kim Barrett wrote:
>> Please review this change to globally suppress Visual Studio warning
>> C4351. This warning is entirely useless to us. All it does is
>> interfere with writing clear and correct code. (See bug for more
>> details.)
>>
>> This change also removes the one existing occurrence of local
>> suppression of this warning, which is no longer needed.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8200630
>>
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8200630/open.00/
>>
>> Testing:
>> Build on all Oracle supported platforms, and ran hs-tier1.
From shade at redhat.com Wed Apr 4 09:05:14 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 4 Apr 2018 11:05:14 +0200
Subject: RFR (XS) 8200608: Build failures after JDK-8191101 (Show register
content in hs-err file on assert)
In-Reply-To: <337d9941-0728-c734-dc7a-a86efe555063@redhat.com>
References: <c16534f7-3c96-407b-7b37-e2676ccc6d24@redhat.com>
<f159b52c-ef24-344f-5df9-0fe9b9be2d4f@oracle.com>
<337d9941-0728-c734-dc7a-a86efe555063@redhat.com>
Message-ID: <59b77b1b-d15e-b1ae-a7be-f41ae2d70987@redhat.com>
Thomas had not replied yet, I am pushing this as is to unbreak the build.
Triviality rule does not require me to have two reviewers, and only one is fine, right?
-Aleksey
On 04/03/2018 04:00 PM, Aleksey Shipilev wrote:
> I believe that is a simple overlook. Thomas (Stuefe)?
>
> -Aleksey
>
> On 04/03/2018 11:53 AM, David Holmes wrote:
>> Seems trivial.
>>
>> I have to wonder why jlong was ever used in the first place ???
>>
>> David
>>
>> On 3/04/2018 7:18 PM, Aleksey Shipilev wrote:
>>> Bug:
>>> ? https://bugs.openjdk.java.net/browse/JDK-8200608
>>>
>>> "jlong" is not "intx" in x86_32. The fix is simple, because os::current_thread_id() actually returns
>>> intx. I think the fix falls under triviality rule.
>>>
>>> --- a/src/hotspot/share/utilities/debug.cpp???? Tue Apr 03 10:27:46 2018 +0200
>>> +++ b/src/hotspot/share/utilities/debug.cpp???? Tue Apr 03 11:04:01 2018 +0200
>>> @@ -731,7 +731,7 @@
>>> ????? os::protect_memory((char*)g_assert_poison, os::vm_page_size(), os::MEM_PROT_RWX);
>>> ????? // Store Context away.
>>> ????? if (ucVoid) {
>>> -????? const jlong my_tid = os::current_thread_id();
>>> +????? const intx my_tid = os::current_thread_id();
>>> ??????? if (Atomic::cmpxchg(my_tid, &g_asserting_thread, (intx)0) == 0) {
>>> ????????? if (store_context(ucVoid)) {
>>> ??????????? g_assertion_context = &g_stored_assertion_context;
>>>
>>>
>>> Testing: x86_32 and x86_64 builds
>>>
>>> Thanks,
>>> -Aleksey
>>>
>
>
From thomas.schatzl at oracle.com Wed Apr 4 09:17:22 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 04 Apr 2018 11:17:22 +0200
Subject: RFR (XS) 8200608: Build failures after JDK-8191101 (Show
register content in hs-err file on assert)
In-Reply-To: <59b77b1b-d15e-b1ae-a7be-f41ae2d70987@redhat.com>
References: <c16534f7-3c96-407b-7b37-e2676ccc6d24@redhat.com>
<f159b52c-ef24-344f-5df9-0fe9b9be2d4f@oracle.com>
<337d9941-0728-c734-dc7a-a86efe555063@redhat.com>
<59b77b1b-d15e-b1ae-a7be-f41ae2d70987@redhat.com>
Message-ID: <1522833442.2398.1.camel@oracle.com>
Hi Aleksey,
On Wed, 2018-04-04 at 11:05 +0200, Aleksey Shipilev wrote:
> Thomas had not replied yet, I am pushing this as is to unbreak the
> build.
>
> Triviality rule does not require me to have two reviewers, and only
> one is fine, right?
>
yes. If you need another reviewer, you can count me in. Change looks
good.
Thomas
From thomas.schatzl at oracle.com Wed Apr 4 09:31:35 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 04 Apr 2018 11:31:35 +0200
Subject: RFR: 8200630: Globally suppress Visual Studio warning C4351
In-Reply-To: <AE209A4D-CC94-4E98-AF2D-56D1EE6BA31B@oracle.com>
References: <AE209A4D-CC94-4E98-AF2D-56D1EE6BA31B@oracle.com>
Message-ID: <1522834295.2398.3.camel@oracle.com>
Hi,
On Tue, 2018-04-03 at 17:00 -0400, Kim Barrett wrote:
> Please review this change to globally suppress Visual Studio warning
> C4351. This warning is entirely useless to us. All it does is
> interfere with writing clear and correct code. (See bug for more
> details.)
>
> This change also removes the one existing occurrence of local
> suppression of this warning, which is no longer needed.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8200630
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8200630/open.00/
>
find with me. Looks good to me.
Thomas
From shade at redhat.com Wed Apr 4 10:41:25 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 4 Apr 2018 12:41:25 +0200
Subject: JEP 331: Low-Overhead Heap Profiling
In-Reply-To: <20180329171223.64A4C1973B3@eggemoggin.niobe.net>
References: <20180329171223.64A4C1973B3@eggemoggin.niobe.net>
Message-ID: <cfb1b563-2702-a0b8-b122-da0e46b3b26f@redhat.com>
On 03/29/2018 07:12 PM, mark.reinhold at oracle.com wrote:
> New JEP Candidate: http://openjdk.java.net/jeps/331
Interesting JEP!
*) It would be nice to mention the implementation details in the JEP itself, i.e. where are the
points it injects into GCs to sample? I assume it has to inject into CollectedHeap::allocate_tlab,
and it has to cap the max TLAB sizes to get into allocation slowpath often enough?
*) Since JC apparently has the prototype, it would be easier to put it somewhere, and link it into
the JEP itself. Webrevs are interesting, but they get outdated pretty quickly, so maybe putting the
whole thing in JDK Sandbox [1] is the way to go.
Otherwise it leads to speculation, which raises the questions like below:
*) Motivation says: "The downsides [of JFR] are that a) it is tied to a particular allocation
implementation (TLABs), and misses allocations that don?t meet that pattern; b) it doesn?t allow the
user to customize the sampling rate; c) it only logs allocations, so you cannot distinguish between
live and dead objects."
...but then JEP apparently describes sampling the allocations via TLABs? So, the real difference is
(b), allowing to customize the sampling rate, or do I miss something?
*) Goals say: "Can give information about both live and dead Java objects."
...but there is not discussion what/how does it give information about the dead Java objects. I am
struggling to imagine how allocation sampling would give this. Is the goal too broad, or some API is
not described in the JEP?
Thanks,
-Aleksey
[1] http://cr.openjdk.java.net/~chegar/docs/sandbox.html
From stefan.karlsson at oracle.com Wed Apr 4 13:22:03 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 4 Apr 2018 15:22:03 +0200
Subject: RFR: 8200735: Move CMS specific code from binaryTreeDictionary and
freeList to CMS files
Message-ID: <71db7b0e-e2cb-cd13-a255-e5d4f8cb883d@oracle.com>
Hi all,
[Sending to hotspot-dev because this changes both GC and Metaspace code]
Please review this patch to move CMS specific code out of the
binaryTreeDictionary.*pp and freeList.*hpp files into CMS files.
http://cr.openjdk.java.net/~stefank/8200735/webrev.01
https://bugs.openjdk.java.net/browse/JDK-8200735
The BinaryTreeDictionary and FreeList used to be classes only used by
CMS, and therefore contained CMS specific code. These classes were later
used by the Metaspace and moved to the memory/ directory. The CMS
specific code was then guarded with numerous INCLUDE_ALL_GCS. This patch
moves the CMS code to compactibleFreeListSpace.*pp, where it's used.
To make it possible for the code in compactibleFreeListSpace.cpp file to
use the code in binaryTreeDictionary.cpp and freeList.cpp I removed the
explicit template instantiation and changed these two files into two
.inline.hpp files.
This patch helps minimizing the number of places we use INCLUDE_ALL_GCS
in non-GC code, and is a prerequisite for:
https://bugs.openjdk.java.net/browse/JDK-8200729 - Conditional
compilation of GCs
Thanks,
StefanK
From erik.osterlund at oracle.com Wed Apr 4 13:38:29 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Wed, 4 Apr 2018 15:38:29 +0200
Subject: RFR: 8199417: Modularize interpreter GC barriers
In-Reply-To: <3FFD79AD-84B8-4E9E-98E3-47ACBA01D91F@oracle.com>
References: <5AB8BDF9.4050106@oracle.com>
<3FFD79AD-84B8-4E9E-98E3-47ACBA01D91F@oracle.com>
Message-ID: <5AC4D555.9040800@oracle.com>
Hi Kim,
Thank you for reviewing this.
I have made a new webrev with proposed changes to the x86/x64 code
reflecting the concerns you and Coleen have.
I thought we should settle for something we like in the x86/x64 code
before going ahead and changing the other platforms too much (I don't
want to bug Martin and Roman too much before).
New full webrev:
http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01/
Incremental:
http://cr.openjdk.java.net/~eosterlund/8199417/webrev.00_01/
On 2018-04-01 05:12, Kim Barrett wrote:
>> On Mar 26, 2018, at 5:31 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>>
>> Hi,
>>
>> The GC barriers for the interpreter are not as modular as they could be. They currently use switch statements to check which GC barrier set is being used, and call this or that barrier based on that, in a way that assumes GCs only use write barriers.
>>
>> This patch modularizes this by generating accesses in the interpreter with declarative semantics. Accesses to the heap may now use store_at and load_at functions of the BarrierSetAssembler, passing along appropriate arguments and decorators. Each concrete BarrierSetAssembler can override the access completely or sprinkle some appropriate GC barriers as necessary.
>>
>> Big thanks go to Martin Doerr and Roman Kennke, who helped plugging this into S390, PPC and AArch64 respectively.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.00/
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8199417
>>
>> Thanks,
>> /Erik
> I've only looked at the x86 and generic code so far. I have some
> comments, but also a bunch of questions. I think I'm missing some
> things somewhere. I'm sending what I've got so far anyway, and will
> continue studying.
>
> ------------------------------------------------------------------------------
> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
> 354 // flatten object address if needed
> 355 // We do it regardless of precise because we need the registers
>
> There is no "precise" in this context.
I thought "precise" was referring to the concept of precise card
marking, as opposed to the variable 'precise' that used to exist. I have
reworded the comment to reflect that.
> ------------------------------------------------------------------------------
> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
> 364 #ifndef _LP64
> 365 InterpreterMacroAssembler *imasm = static_cast<InterpreterMacroAssembler*>(masm);
> 366 #endif
>
> In the old code, the function received an InterpreterMacroAssembler*.
>
> What is there about this context that lets us know the downcast is
> safe here? Is oop_store_at only ever called with an IMA*? If so,
> then why isn't that the parameter type. If not, then what?
Yes, this is indeed only used by the InterpreterMacroAssembler. But I
wanted the interface to use MacroAssembler. Why?
1) It's only 32 bit x86 that relies on this property, and I hope it will
go away soon, and the save bcp hack with it.
2) previous load_heap_oop is used not only in the
InterpreterMacroAssembler, and I wanted the same assembler in load_at
and store_at.
So for now it is only used in InterpreterMacroAssembler, and I doubt
that will change any time soon. I am hoping 32 bit support will be
dropped before that, and the hack will go away. For now, I have added a
virtual is_interpreter_masm() call that I use in an assert to make sure
this is not accidentally used in the wrong context until 32 bit support
is gone.
> ------------------------------------------------------------------------------
> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> 753 bs->load_at(_masm, IN_HEAP | ON_WEAK_OOP_REF, T_OBJECT,
> 754 rax, field_address, /*tmp1*/ rbx, /*tmp_thread*/ rdx);
>
> This needs to distinguish between WEAK and PHANTOM references, else it
> will break ZGC's concurrent reference processing. (At least so long as
> we still have to deal with finalization.)
It does. This is ON_WEAK_OOP_REF. The get intrinsic is generated for
WeakReference (and SoftReference) only. PhantomReference does not have a
getter. Therefore, in all contexts this is intrinsified, it will refer
to an ON_WEAK_OOP_REF.
> ------------------------------------------------------------------------------
> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> 698 address TemplateInterpreterGenerator::generate_Reference_get_entry(void) {
>
> Almost all the code here (and much of the commentary) was/is specific
> to G1 (or SATB collectors). Shouldn't it all be in the barrier_set's
> load_at? As it is now, if (say) we're using Parallel GC then I think
> there's a bunch of additional code being generated and executed here
> that wasn't present before.
It is true that interpreter Reference.get() intrinsics with
Parallel/CMS/Serial currently run a few instructions more than they need
to pay for the abstraction. There is no doubt in my mind that this
abstraction is worth the cost. Reference.get in the interpreter is not a
hot path, and does not need to optimize every cycle.
I changed the G1 comments to more general comments instead.
> ------------------------------------------------------------------------------
> src/hotspot/cpu/x86/methodHandles_x86.cpp
> 170 __ load_heap_oop(method_temp, Address(recv, NONZERO(java_lang_invoke_MethodHandle::form_offset_in_bytes())));
> =>
> 175 bs->load_at(_masm, IN_HEAP, T_OBJECT, method_temp, Address(recv, NONZERO(java_lang_invoke_MethodHandle::form_offset_in_bytes())), t
>
> This doesn't look like an improvement in code readability to me. Why
> can't bs->load_at be the implementation of "__ load_heap_oop" ?
>
> And the lines are getting really long; so long that webrev is cutting
> off the right end, so I can't review the new versions of the lines.
Due to popular demand, I have done what you (and Coleen) both proposed:
retained the load_heap_oop abstraction.
Before:
* load_heap_oop was the "raw" variant, similar to
oopDesc::load_decode_heap_oop, which no longer exists.
Now:
* load_heap_oop calls MacroAssembler::access_load_at
* access_load_at grabs the active BarrierSetAssembler and calls load_at
on it.
... same idea for stores.
* What used to be the raw versions for oop loads and stores, has moved
to BarrierSetAssembler::load_at/store_at.
These accessors now optionally take temporary register and decorator
parameters than you don't have to supply:
* supplying temprary register is polite to the GC so its accesses can be
a bit better
* supplying decorators can be done if it is not a default access. For
example, AS_RAW can now be used to perform a raw load instead.
> ------------------------------------------------------------------------------
> src/hotspot/cpu/x86/methodHandles_x86.cpp
> 363 __ load_heap_oop(temp2_defc, member_clazz);
> =>
> 368 BarrierSetAssembler* bs = BarrierSet::barrier_set()->barrier_set_assembler();
> 369 Register rthread = LP64_ONLY(r15_thread) NOT_LP64(noreg);
> 370 bs->load_at(_masm, IN_HEAP, T_OBJECT, temp2_defc, member_clazz, noreg, rthread);
>
> Similarly, this doesn't seem like an improvement to me. And there are
> more like this.
Fixed.
> ------------------------------------------------------------------------------
> src/hotspot/cpu/x86/macroAssembler_x86.hpp
>
> It would reduce the clutter in this change to leave the as_Address
> declarations where they were, since that place is now public, rather
> than moving them to a different public section.
Fixed.
> ------------------------------------------------------------------------------
>
> Generally, it seems like it might be nice for the MacroAssembler class
> to have a reference to the barrier_set, or maybe even the bs's
> assembler, rather than looking them up in various places, and in
> different ways. For example, I see each of
>
> Universe::heap()->barrier_set()
> BarrerSet::barrier_set()
>
> used in various different places *in new code*. Some consistency
> would be nice.
I think it seems fine to just fetch them only in the
access_load/store_at wrappers.
> ------------------------------------------------------------------------------
> src/hotspot/cpu/x86/macroAssembler_x86.cpp
> 5249 bs->load_at(this, IN_ROOT | ON_PHANTOM_OOP_REF, T_OBJECT,
> 5250 value, Address(value, -JNIHandles::weak_tag_value), tmp, thread);
> 5251 verify_oop(value);
>
> This puts the verify_oop after the G1 pre-barrier, where in the old
> code verify_oop was before the pre-barrier. I remember the old order
> being intentional, though don't off-hand recall how important that
> was. If for no other reason, it seems like the new order could rarely
> (due to bad timing) have a bad oop reported somewhere far away during
> SATB buffer processing, rather than at the point of the load.
>
> With the new version's order there could be one verify after the done
> label. That's just a minor nit.
Conversely, I think the new order is better and more GC agnostic.
It avoids, for example, sending in bad oops for verification with ZGC.
The more GC-agnostic interface is that after the load_at
> ------------------------------------------------------------------------------
> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
> 230 #ifdef _LP64
> 231 if (c_rarg1 != thread) {
> 232 __ mov(c_rarg1, thread);
> 233 }
> 234 if (c_rarg0 != pre_val) {
> 235 __ mov(c_rarg0, pre_val);
> 236 }
> 237 #else
> 238 __ push(thread);
> 239 __ push(pre_val);
> 240 #endif
>
> Old code used:
>
> __ pass_arg1(thread);
> __ pass_arg0(pre_val);
>
> Why is this being changed? Oh, pass_argN are static helpers not
> available outside macroAssembler_x86.cpp. Maybe they should be
> exposed in some way, like public helpers in the x86 version of the
> MacroAssembler class, rather than copied inline here (and maybe other
> places?).
Fixed. (added a wrapper for this to MacroAssembler, as suggested)
> ------------------------------------------------------------------------------
> src/hotspot/cpu/x86/interp_masm_x86.cpp
> Deleted these lines:
> 519 // The resulting oop is null if the reference is not yet resolved.
> 520 // It is Universe::the_null_sentinel() if the reference resolved to NULL via condy.
>
> I don't think those comment lines should be deleted.
Fixed.
> ------------------------------------------------------------------------------
> src/hotspot/cpu/x86/gc/shared/modRefBarrierSetAssembler_x86.cpp
> 86 void ModRefBarrierSetAssembler::store_at(MacroAssembler* masm, DecoratorSet decorators, BasicType type,
> 87 Address dst, Register val, Register tmp1, Register tmp2) {
> 88 if (type == T_OBJECT || type == T_ARRAY) {
> 89 oop_store_at(masm, decorators, type, dst, val, tmp1, tmp2);
> 90 } else {
> 91 BarrierSetAssembler::store_at(masm, decorators, type, dst, val, tmp1, tmp2);
> 92 }
> 93 }
>
> Doesn't the conditional conversion from store_at to oop_store_at
> actually indicate a bug in the caller? That is, calling store_at with
> a oop (T_OBJECT or T_ARRAY) value seems like a bug, and should be
> asserted against, rather than translating.
>
> And oop_store_at should assert that the value *is* an oop value.
>
> And should there be any verification that the decorators and the type
> are consistent?
>
> But maybe I'm not understanding the protocol around oop_store_at?
> There being no documentation, it seems entirely possible that I've
> misunderstood something here. Maybe I'm being confused by
> similarities in naming with Access:: that don't hold?
The confusion roots in that Access and BarrierSetAssembler are not
structured exactly the same.
Access provides store_at and oop_store_at. The reason for providing both
of these, is that I could not safely infer whether the passed in
parameters were oops or not without changing oop and narrowOop to always
be value objects, which I did not dare to do as the generated code was
worse.
In BarrierSetAssembler, there is no such restriction. The type for the
access is always passed in to store_at/load_at as BasicType. It is the
responsibility of ModRefBarrierSetAssembler to filter away non-oop
references, and call oop_store_at for relevant accesses for ModRef. This
follows the same pattern that the arraycopy stubs used. This allows,
e.g. CardTableModRef to only override oop_store_at. This is similar to
how ModRefBarrierSet::AccessBarrier<decorators,
BarrierSetT>::oop_store_in_heap calls the concrete barriersets for help
generating that access. I hope this helps understanding the structuring.
This is also the reason why G1BarrierSetAssembler::load_at checks
whether it is an oop that is loaded or not, because loads are not riding
on the ModRef layer, which only knows about oop stores.
> ------------------------------------------------------------------------------
> src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
> 88 void CardTableBarrierSetAssembler::store_check(MacroAssembler* masm, Register obj, Address dst) {
> 89 // Does a store check for the oop in register obj. The content of
> 90 // register obj is destroyed afterwards.
>
> The comment states obj is an oop, but when called by the precise case
> of oop_store_at, it is not an oop, but rather a derived pointer. I
> think it's the comment that's wrong.
I changed the comment to refer to obj as an oop* instead of an oop.
> ------------------------------------------------------------------------------
>
> I was surprised that oop_store_at is initially declared at the
> ModRefBarrierSetAssembler level, rather than at the
> BarrierSetAssembler level.
>
> I was also surprised to not see an oop_load_at.
>
> In Access we have _at suffixed operations paired with non-_at suffixed
> operations, the difference being the _at suffixed operations have a
> base object, to allow dealing with the brooks-ptr. I'm not finding any
> such distinction in the xxxAssembler API. Presumably I've missed
> something somewhere. How is that handled?
I think I previously already explained this one. ModRef does not know
about oop loads, only stores. Therefore, G1 must override load_at, and
not oop_load_at.
Thanks,
/Erik
> ------------------------------------------------------------------------------
>
>
From glaubitz at physik.fu-berlin.de Wed Apr 4 15:06:02 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Wed, 4 Apr 2018 17:06:02 +0200
Subject: Execution problems with Atomic Operations on OpenJDK10 for ARM5
Soft Float
In-Reply-To: <209e831bd10929184afdbedb7e811652@juanantonio.info>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
Message-ID: <4e146cb4-5998-2d0d-5c51-f2003b1c71b9@physik.fu-berlin.de>
CC'ing hotspot-dev
On 04/04/2018 12:29 PM, bren at juanantonio.info wrote:
> I think that in OpenJDK10 changed something in compare to OpenJDK9 in relation to ARM5 support.
It was OpenJDK9 which dropped support for ARM CPUs prior ARMv7. If you are
using ARMv5, you have to resort to OpenJDK Zero, i.e. the unoptimized, generic
implementation of the JVM.
As for the atomic operation, I'm not sure whether Zero supports this particular
atomic operation. I will have to dig into the code myself.
Would it be possible that you provide sample code that helps reproduce the problem?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From bob.vandette at oracle.com Wed Apr 4 16:15:38 2018
From: bob.vandette at oracle.com (Bob Vandette)
Date: Wed, 4 Apr 2018 12:15:38 -0400
Subject: Execution problems with Atomic Operations on OpenJDK10 for ARM5
Soft Float
In-Reply-To: <4e146cb4-5998-2d0d-5c51-f2003b1c71b9@physik.fu-berlin.de>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
<4e146cb4-5998-2d0d-5c51-f2003b1c71b9@physik.fu-berlin.de>
Message-ID: <AE5E3644-C06D-4114-9020-C414DD170294@oracle.com>
I believe the problem is that the VM is now using more atomic load/store of java longs
and we don?t support these operations on multi-processing ARMv5 systems due to the
lack of low level atomic instructions. On non MP ARMv5 systems, we use load/store multiple
instructions.
If you can determine that your ARMv5 processor?s implementation of ldmia/stmia are
indeed atomic, you could try to use these instructions by altering the code below.
Otherwise, you might want to investigate gcc atomic intrinsics and see if 8 byte atomics
are supported on your platform. There?s a set of kernel helper routines that we use
for atomic exchange of 8 bytes, maybe they now have atomic 8 byte loads/stores.
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt
In open/src/hotspot/cpu/arm/stubGenerator_arm.cpp, these two functions would need to be
fixed to provide these low level operations.
address generate_atomic_load_long() {
address start;
StubCodeMark mark(this, "StubRoutines", "atomic_load_long");
start = __ pc();
Register result_lo = R0;
Register result_hi = R1;
Register src = R0;
if (!os::is_MP()) {
__ ldmia(src, RegisterSet(result_lo, result_hi));
__ bx(LR);
} else if (VM_Version::supports_ldrexd()) {
__ ldrexd(result_lo, Address(src));
__ clrex(); // FIXME: safe to remove?
__ bx(LR);
} else {
__ stop("Atomic load(jlong) unsupported on this platform");
__ bx(LR);
}
return start;
}
address generate_atomic_store_long() {
address start;
StubCodeMark mark(this, "StubRoutines", "atomic_store_long");
start = __ pc();
Register newval_lo = R0;
Register newval_hi = R1;
Register dest = R2;
Register scratch_lo = R2;
Register scratch_hi = R3; /* After load from stack */
Register result = R3;
if (!os::is_MP()) {
__ stmia(dest, RegisterSet(newval_lo, newval_hi));
__ bx(LR);
} else if (VM_Version::supports_ldrexd()) {
__ mov(Rtemp, dest); // get dest to Rtemp
Label retry;
__ bind(retry);
__ ldrexd(scratch_lo, Address(Rtemp));
__ strexd(result, R0, Address(Rtemp));
__ rsbs(result, result, 1);
__ b(retry, eq);
__ bx(LR);
} else {
__ stop("Atomic store(jlong) unsupported on this platform");
__ bx(LR);
}
return start;
}
Bob.
> On Apr 4, 2018, at 11:06 AM, John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de> wrote:
>
> CC'ing hotspot-dev
>
> On 04/04/2018 12:29 PM, bren at juanantonio.info wrote:
>> I think that in OpenJDK10 changed something in compare to OpenJDK9 in relation to ARM5 support.
>
> It was OpenJDK9 which dropped support for ARM CPUs prior ARMv7. If you are
> using ARMv5, you have to resort to OpenJDK Zero, i.e. the unoptimized, generic
> implementation of the JVM.
>
> As for the atomic operation, I'm not sure whether Zero supports this particular
> atomic operation. I will have to dig into the code myself.
>
> Would it be possible that you provide sample code that helps reproduce the problem?
>
> Adrian
>
> --
> .''`. John Paul Adrian Glaubitz
> : :' : Debian Developer - glaubitz at debian.org
> `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From shade at redhat.com Wed Apr 4 16:34:25 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 4 Apr 2018 18:34:25 +0200
Subject: RFR: 8200735: Move CMS specific code from binaryTreeDictionary
and freeList to CMS files
In-Reply-To: <71db7b0e-e2cb-cd13-a255-e5d4f8cb883d@oracle.com>
References: <71db7b0e-e2cb-cd13-a255-e5d4f8cb883d@oracle.com>
Message-ID: <03019539-9ca2-eb44-608d-34199984916e@redhat.com>
On 04/04/2018 03:22 PM, Stefan Karlsson wrote:
> Please review this patch to move CMS specific code out of the binaryTreeDictionary.*pp and
> freeList.*hpp files into CMS files.
>
> http://cr.openjdk.java.net/~stefank/8200735/webrev.01
Very nice cleanup, looks good!
I assume these are only code moves, and no actual code changes hidden there.
Thanks,
-Aleksey
From stefan.karlsson at oracle.com Wed Apr 4 17:13:27 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 4 Apr 2018 19:13:27 +0200
Subject: RFR: 8200735: Move CMS specific code from binaryTreeDictionary
and freeList to CMS files
In-Reply-To: <03019539-9ca2-eb44-608d-34199984916e@redhat.com>
References: <71db7b0e-e2cb-cd13-a255-e5d4f8cb883d@oracle.com>
<03019539-9ca2-eb44-608d-34199984916e@redhat.com>
Message-ID: <fc32e69a-a29d-45dd-8497-7916ded53fb8@oracle.com>
On 2018-04-04 18:34, Aleksey Shipilev wrote:
> On 04/04/2018 03:22 PM, Stefan Karlsson wrote:
>> Please review this patch to move CMS specific code out of the binaryTreeDictionary.*pp and
>> freeList.*hpp files into CMS files.
>>
>> http://cr.openjdk.java.net/~stefank/8200735/webrev.01
> Very nice cleanup, looks good!
Thanks, Aleksey!
> I assume these are only code moves, and no actual code changes hidden there.
I've tried to only make changes that would cause the compiler to
generate equivalent code, minus the fact that it now might inline more
(which is a consequence of the removal of the explicit template
instantiation).
It might be important to not that I did some changes to the classes that
were brought over to CMS. For example:
-template <class Chunk_t, class FreeList_t>
-class BeginSweepClosure : public AscendTreeCensusClosure<Chunk_t,
FreeList_t> {
-? double _percentage;
-? float _inter_sweep_current;
-? float _inter_sweep_estimate;
-? float _intra_sweep_estimate;
-
- public:
-? BeginSweepClosure(double p, float inter_sweep_current,
-????????????????????????????? float inter_sweep_estimate,
-????????????????????????????? float intra_sweep_estimate) :
-?? _percentage(p),
-?? _inter_sweep_current(inter_sweep_current),
-?? _inter_sweep_estimate(inter_sweep_estimate),
-?? _intra_sweep_estimate(intra_sweep_estimate) { }
-
-? void do_list(FreeList<Chunk_t>* fl) {}
-
-#if INCLUDE_ALL_GCS
-? void do_list(AdaptiveFreeList<Chunk_t>* fl) {
-??? double coalSurplusPercent = _percentage;
-??? fl->compute_desired(_inter_sweep_current, _inter_sweep_estimate,
_intra_sweep_estimate);
-??? fl->set_coal_desired((ssize_t)((double)fl->desired() *
coalSurplusPercent));
-??? fl->set_before_sweep(fl->count());
-??? fl->set_bfr_surp(fl->surplus());
-? }
-#endif // INCLUDE_ALL_GCS
-};
became:
+class BeginSweepClosure : public AscendTreeCensusClosure<FreeChunk,
AdaptiveFreeList<FreeChunk> > {
+? double _percentage;
+? float _inter_sweep_current;
+? float _inter_sweep_estimate;
+? float _intra_sweep_estimate;
+
+ public:
+? BeginSweepClosure(double p, float inter_sweep_current,
+????????????????????????????? float inter_sweep_estimate,
+????????????????????????????? float intra_sweep_estimate) :
+?? _percentage(p),
+?? _inter_sweep_current(inter_sweep_current),
+?? _inter_sweep_estimate(inter_sweep_estimate),
+?? _intra_sweep_estimate(intra_sweep_estimate) { }
+
+? void do_list(AdaptiveFreeList<FreeChunk>* fl) {
+??? double coalSurplusPercent = _percentage;
+??? fl->compute_desired(_inter_sweep_current, _inter_sweep_estimate,
_intra_sweep_estimate);
+??? fl->set_coal_desired((ssize_t)((double)fl->desired() *
coalSurplusPercent));
+??? fl->set_before_sweep(fl->count());
+??? fl->set_bfr_surp(fl->surplus());
+? }
+};
That is, I removed the template parameters of the class and got rid of
the unused do_list overload.
I think it's easiest to see this if one diffs the old
binaryTreeDictionary.cpp and the new compactibleFreeListSpace.cpp.
Unfortunately, I didn't maintain the order of the classes and functions
when I brought them over. I should probably do that change so that this
gets easier to review.
Thanks,
StefanK
>
> Thanks,
> -Aleksey
From zgu at redhat.com Wed Apr 4 17:47:43 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 4 Apr 2018 13:47:43 -0400
Subject: RFR 8199868: Support JNI critical functions in object pinning API
Message-ID: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com>
Please review this patch that adds JNI critical native support to object
pinning.
Shenandoah does not block GC while JNI critical session is in progress.
This patch allows it to pin all incoming array objects before critical
native call, and unpin them after call completes.
Bug: https://bugs.openjdk.java.net/browse/JDK-8199868
Webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.00/
Test:
hotspot_runtime and hotspot_compiler on Linux x86 (fastdebug and release).
Submit test also clean:
Mach5 mach5-one-zgu-JDK-8199868-20180404-1334-17314: Builds PASSED.
Testing SUCCESSFUL.
Thanks,
-Zhengyu
From stefan.karlsson at oracle.com Wed Apr 4 18:02:05 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 4 Apr 2018 20:02:05 +0200
Subject: RFR: 8200735: Move CMS specific code from binaryTreeDictionary
and freeList to CMS files
In-Reply-To: <fc32e69a-a29d-45dd-8497-7916ded53fb8@oracle.com>
References: <71db7b0e-e2cb-cd13-a255-e5d4f8cb883d@oracle.com>
<03019539-9ca2-eb44-608d-34199984916e@redhat.com>
<fc32e69a-a29d-45dd-8497-7916ded53fb8@oracle.com>
Message-ID: <2b2b9c73-c018-4316-0d27-b6c90c5534d0@oracle.com>
I've updated the patch so that we maintain the order of the moved
classes and functions:
?http://cr.openjdk.java.net/~stefank/8200735/webrev.02
http://cr.openjdk.java.net/~stefank/8200735/webrev.02.delta
And here's the diff of the important parts of the old
binaryTreeDictionary.cpp and the new compactibleFreeListSpace.cpp files:
?http://cr.openjdk.java.net/~stefank/8200735/webrev.02/oldBinaryTreeDictionaryCppVSnewCompactibleFreeListSpaceCpp.patch
Thanks,
StefanK
On 2018-04-04 19:13, Stefan Karlsson wrote:
> On 2018-04-04 18:34, Aleksey Shipilev wrote:
>> On 04/04/2018 03:22 PM, Stefan Karlsson wrote:
>>> Please review this patch to move CMS specific code out of the
>>> binaryTreeDictionary.*pp and
>>> freeList.*hpp files into CMS files.
>>>
>>> http://cr.openjdk.java.net/~stefank/8200735/webrev.01
>> Very nice cleanup, looks good!
>
> Thanks, Aleksey!
>
>> I assume these are only code moves, and no actual code changes hidden
>> there.
>
> I've tried to only make changes that would cause the compiler to
> generate equivalent code, minus the fact that it now might inline more
> (which is a consequence of the removal of the explicit template
> instantiation).
>
> It might be important to not that I did some changes to the classes
> that were brought over to CMS. For example:
> -template <class Chunk_t, class FreeList_t>
> -class BeginSweepClosure : public AscendTreeCensusClosure<Chunk_t,
> FreeList_t> {
> -? double _percentage;
> -? float _inter_sweep_current;
> -? float _inter_sweep_estimate;
> -? float _intra_sweep_estimate;
> -
> - public:
> -? BeginSweepClosure(double p, float inter_sweep_current,
> -????????????????????????????? float inter_sweep_estimate,
> -????????????????????????????? float intra_sweep_estimate) :
> -?? _percentage(p),
> -?? _inter_sweep_current(inter_sweep_current),
> -?? _inter_sweep_estimate(inter_sweep_estimate),
> -?? _intra_sweep_estimate(intra_sweep_estimate) { }
> -
> -? void do_list(FreeList<Chunk_t>* fl) {}
> -
> -#if INCLUDE_ALL_GCS
> -? void do_list(AdaptiveFreeList<Chunk_t>* fl) {
> -??? double coalSurplusPercent = _percentage;
> -??? fl->compute_desired(_inter_sweep_current, _inter_sweep_estimate,
> _intra_sweep_estimate);
> -??? fl->set_coal_desired((ssize_t)((double)fl->desired() *
> coalSurplusPercent));
> -??? fl->set_before_sweep(fl->count());
> -??? fl->set_bfr_surp(fl->surplus());
> -? }
> -#endif // INCLUDE_ALL_GCS
> -};
>
> became:
> +class BeginSweepClosure : public AscendTreeCensusClosure<FreeChunk,
> AdaptiveFreeList<FreeChunk> > {
> +? double _percentage;
> +? float _inter_sweep_current;
> +? float _inter_sweep_estimate;
> +? float _intra_sweep_estimate;
> +
> + public:
> +? BeginSweepClosure(double p, float inter_sweep_current,
> +????????????????????????????? float inter_sweep_estimate,
> +????????????????????????????? float intra_sweep_estimate) :
> +?? _percentage(p),
> +?? _inter_sweep_current(inter_sweep_current),
> +?? _inter_sweep_estimate(inter_sweep_estimate),
> +?? _intra_sweep_estimate(intra_sweep_estimate) { }
> +
> +? void do_list(AdaptiveFreeList<FreeChunk>* fl) {
> +??? double coalSurplusPercent = _percentage;
> +??? fl->compute_desired(_inter_sweep_current, _inter_sweep_estimate,
> _intra_sweep_estimate);
> +??? fl->set_coal_desired((ssize_t)((double)fl->desired() *
> coalSurplusPercent));
> +??? fl->set_before_sweep(fl->count());
> +??? fl->set_bfr_surp(fl->surplus());
> +? }
> +};
>
> That is, I removed the template parameters of the class and got rid of
> the unused do_list overload.
>
> I think it's easiest to see this if one diffs the old
> binaryTreeDictionary.cpp and the new compactibleFreeListSpace.cpp.
> Unfortunately, I didn't maintain the order of the classes and
> functions when I brought them over. I should probably do that change
> so that this gets easier to review.
>
> Thanks,
> StefanK
>
>>
>> Thanks,
>> -Aleksey
>
>
From erik.joelsson at oracle.com Wed Apr 4 18:30:08 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 4 Apr 2018 11:30:08 -0700
Subject: RFR: JDK-8196724: Change macosx deployment target to 10.9
Message-ID: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com>
This patch changes the values for the macosx version min and max
settings from 10.7 to 10.9. It also changes the stdlib from libstdc++ to
libc++ (explicitly for Hotspot and implicitly everywhere else). This
change is necessary to keep up with newer toolchain versions on Macosx
where using the old and no longer maintained libstdc++ has been
deprecated. This is done in preparation for bumping the preferred Xcode
version used for builds at Oracle.
The switch has been tested for both Hotspot and client.
The switch triggered some new deprecation warnings which have been
silenced and followup bugs have been filed on the concerned team.
Bug: https://bugs.openjdk.java.net/browse/JDK-8196724
Webrev: http://cr.openjdk.java.net/~erikj/8196724/webrev.01/index.html
/Erik
From kim.barrett at oracle.com Wed Apr 4 18:35:32 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 4 Apr 2018 14:35:32 -0400
Subject: RFR: 8200630: Globally suppress Visual Studio warning C4351
In-Reply-To: <1522834295.2398.3.camel@oracle.com>
References: <AE209A4D-CC94-4E98-AF2D-56D1EE6BA31B@oracle.com>
<1522834295.2398.3.camel@oracle.com>
Message-ID: <27DE7F02-92EA-4D3C-97C3-0A1782E957BD@oracle.com>
> On Apr 4, 2018, at 5:31 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
>
> Hi,
>
> On Tue, 2018-04-03 at 17:00 -0400, Kim Barrett wrote:
>> Please review this change to globally suppress Visual Studio warning
>> C4351. This warning is entirely useless to us. All it does is
>> interfere with writing clear and correct code. (See bug for more
>> details.)
>>
>> This change also removes the one existing occurrence of local
>> suppression of this warning, which is no longer needed.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8200630
>>
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8200630/open.00/
>>
>
> find with me. Looks good to me.
>
> Thomas
Thanks.
From kim.barrett at oracle.com Wed Apr 4 18:53:01 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 4 Apr 2018 14:53:01 -0400
Subject: RFR: 8200697: Add utility for spin wait with fallback to yield/sleep
Message-ID: <E1CA91CD-9CF6-44D5-A7B7-0747AA648D65@oracle.com>
Please review this addition of SpinYield utility class.
It initially supplies a very simple policy: spin a configured number
of times, then switch to yielding or (eventually) sleeping. Other
policies may replace this one or be provided as alternatives in the
future.
This is joint work with Robbin Ehn.
Robbin and I have immediate uses for this utility in changes we are
developing. In addition, there are some existing places that might be
converted to use this utility (or perhaps some extended version of
it), including SafepointSynchronize::begin, ReadStableMark,
Thread::SpinAcquire, and ParallelTaskTerminator::offer_termination.
Those existing potential uses are not being changed here; for now,
we're just adding the utility in support of our in-development
changes. We plan to file followup RFEs to consider converting those
potential uses.
CR:
https://bugs.openjdk.java.net/browse/JDK-8200697
Webrev:
http://cr.openjdk.java.net/~kbarrett/8200697/open.00/
Testing:
Added unit test of basic functionality.
Build and hs-tier1 (for gtest) on all Oracle platforms.
From daniel.daugherty at oracle.com Wed Apr 4 19:33:07 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 4 Apr 2018 15:33:07 -0400
Subject: RFR: 8200697: Add utility for spin wait with fallback to
yield/sleep
In-Reply-To: <E1CA91CD-9CF6-44D5-A7B7-0747AA648D65@oracle.com>
References: <E1CA91CD-9CF6-44D5-A7B7-0747AA648D65@oracle.com>
Message-ID: <6ed25248-9d20-970f-2bf9-de56fe9b5a14@oracle.com>
On 4/4/18 2:53 PM, Kim Barrett wrote:
> Please review this addition of SpinYield utility class.
>
> It initially supplies a very simple policy: spin a configured number
> of times, then switch to yielding or (eventually) sleeping. Other
> policies may replace this one or be provided as alternatives in the
> future.
>
> This is joint work with Robbin Ehn.
>
> Robbin and I have immediate uses for this utility in changes we are
> developing. In addition, there are some existing places that might be
> converted to use this utility (or perhaps some extended version of
> it), including SafepointSynchronize::begin, ReadStableMark,
> Thread::SpinAcquire, and ParallelTaskTerminator::offer_termination.
> Those existing potential uses are not being changed here; for now,
> we're just adding the utility in support of our in-development
> changes. We plan to file followup RFEs to consider converting those
> potential uses.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8200697
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8200697/open.00/
src/hotspot/share/utilities/spinYield.cpp
??? L35: ? _spin_limit(os::is_MP() ? spin_limit : 0),
??????? Do you want to mention in the .hpp file that spin_limit
??????? only has meaning when os::is_MP() == true?
??? L45: ??? os::naked_short_sleep(1);
??????? Hmmm... I have a vague memory of a 10ms lower limit for
??????? sleeps on at least some versions of Win*. I realize that
??????? naked_short_sleep() doesn't complain, but does that break
??????? anything in your assumptions?
src/hotspot/share/utilities/spinYield.hpp
??? No comments other than whether you want to talk about limitations
??? in the .hpp file?
test/hotspot/gtest/utilities/test_spinYield.cpp
??? No comments.
Thumbs up.
Dan
P.S.
I think we've still got some spin/yield stuff in Java monitors
and/or Mutexes so this could probably be used there also...
>
> Testing:
> Added unit test of basic functionality.
> Build and hs-tier1 (for gtest) on all Oracle platforms.
>
From tim.bell at oracle.com Wed Apr 4 19:36:53 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 04 Apr 2018 12:36:53 -0700
Subject: RFR: JDK-8196724: Change macosx deployment target to 10.9
In-Reply-To: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com>
References: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com>
Message-ID: <5AC52955.1000306@oracle.com>
Erik:
> This patch changes the values for the macosx version min and max
> settings from 10.7 to 10.9. It also changes the stdlib from libstdc++ to
> libc++ (explicitly for Hotspot and implicitly everywhere else). This
> change is necessary to keep up with newer toolchain versions on Macosx
> where using the old and no longer maintained libstdc++ has been
> deprecated. This is done in preparation for bumping the preferred Xcode
> version used for builds at Oracle.
>
> The switch has been tested for both Hotspot and client.
>
> The switch triggered some new deprecation warnings which have been
> silenced and followup bugs have been filed on the concerned team.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196724
>
> Webrev: http://cr.openjdk.java.net/~erikj/8196724/webrev.01/index.html
Looks good.
/Tim
From stefan.karlsson at oracle.com Wed Apr 4 19:37:16 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 4 Apr 2018 21:37:16 +0200
Subject: RFR: 8200759: Move GC entries in vmStructs.cpp to GC specific files
Message-ID: <8f9ef0fb-14b6-fca8-04ac-1ce49a3a11f0@oracle.com>
Hi all,
Please review this patch to move GC specific entries in vmStructs.cpp
out to GC specific files.
http://cr.openjdk.java.net/~stefank/8200759/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8200759
This patch is done in preparation for:
?https://bugs.openjdk.java.net/browse/JDK-8200729 - Conditional
compilation of GCs
This patch also has the nice feature that it removes multiple usages of
the GC specific defines in vmStructs.cpp. When new GCs are added only
three defines need to be added to vmStructs_gc.hpp.
Tested locally with test/hotspot/jtreg/serviceability/sa, but will run
this through mach5 to find potantial missing includes / forward
declarations.
Thanks,
StefanK
From coleen.phillimore at oracle.com Wed Apr 4 20:05:41 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 4 Apr 2018 16:05:41 -0400
Subject: RFR: 8199417: Modularize interpreter GC barriers
In-Reply-To: <5AC4D555.9040800@oracle.com>
References: <5AB8BDF9.4050106@oracle.com>
<3FFD79AD-84B8-4E9E-98E3-47ACBA01D91F@oracle.com>
<5AC4D555.9040800@oracle.com>
Message-ID: <722ff8a5-a919-cf07-31c6-637303ac1171@oracle.com>
Thank you for keeping load_heap_oop in the macroAssembler, I like it and
think it should be consistent with the rest of the platforms.
http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01/src/hotspot/cpu/x86/templateTable_x86.cpp.udiff.html
+ do_oop_store(_masm, Address(rdx, 0), rax, IN_HEAP_ARRAY);
What happens if someone misses IN_HEAP_ARRAY and puts IN_HEAP instead?
http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp.udiff.html
+ do_oop_store(_masm, element_address, noreg, IN_HEAP | IN_HEAP_ARRAY);
Here it has both for aarch64.
I reviewed the x86 interpreter code, and will review the rest when/if
people say that load_heap_oop is good.
Thanks,
Coleen
On 4/4/18 9:38 AM, Erik ?sterlund wrote:
> Hi Kim,
>
> Thank you for reviewing this.
>
> I have made a new webrev with proposed changes to the x86/x64 code
> reflecting the concerns you and Coleen have.
> I thought we should settle for something we like in the x86/x64 code
> before going ahead and changing the other platforms too much (I don't
> want to bug Martin and Roman too much before).
>
> New full webrev:
> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01/
>
> Incremental:
> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.00_01/
>
> On 2018-04-01 05:12, Kim Barrett wrote:
>>> On Mar 26, 2018, at 5:31 AM, Erik ?sterlund
>>> <erik.osterlund at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> The GC barriers for the interpreter are not as modular as they could
>>> be. They currently use switch statements to check which GC barrier
>>> set is being used, and call this or that barrier based on that, in a
>>> way that assumes GCs only use write barriers.
>>>
>>> This patch modularizes this by generating accesses in the
>>> interpreter with declarative semantics. Accesses to the heap may now
>>> use store_at and load_at functions of the BarrierSetAssembler,
>>> passing along appropriate arguments and decorators. Each concrete
>>> BarrierSetAssembler can override the access completely or sprinkle
>>> some appropriate GC barriers as necessary.
>>>
>>> Big thanks go to Martin Doerr and Roman Kennke, who helped plugging
>>> this into S390, PPC and AArch64 respectively.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.00/
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8199417
>>>
>>> Thanks,
>>> /Erik
>> I've only looked at the x86 and generic code so far. I have some
>> comments, but also a bunch of questions. I think I'm missing some
>> things somewhere. I'm sending what I've got so far anyway, and will
>> continue studying.
>>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>> 354?? // flatten object address if needed
>> 355?? // We do it regardless of precise because we need the registers
>>
>> There is no "precise" in this context.
>
> I thought "precise" was referring to the concept of precise card
> marking, as opposed to the variable 'precise' that used to exist. I
> have reworded the comment to reflect that.
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>> 364 #ifndef _LP64
>> 365?? InterpreterMacroAssembler *imasm =
>> static_cast<InterpreterMacroAssembler*>(masm);
>> 366 #endif
>>
>> In the old code, the function received an InterpreterMacroAssembler*.
>>
>> What is there about this context that lets us know the downcast is
>> safe here?? Is oop_store_at only ever called with an IMA*?? If so,
>> then why isn't that the parameter type.? If not, then what?
>
> Yes, this is indeed only used by the InterpreterMacroAssembler. But I
> wanted the interface to use MacroAssembler. Why?
>
> 1) It's only 32 bit x86 that relies on this property, and I hope it
> will go away soon, and the save bcp hack with it.
> 2) previous load_heap_oop is used not only in the
> InterpreterMacroAssembler, and I wanted the same assembler in load_at
> and store_at.
>
> So for now it is only used in InterpreterMacroAssembler, and I doubt
> that will change any time soon. I am hoping 32 bit support will be
> dropped before that, and the hack will go away. For now, I have added
> a virtual is_interpreter_masm() call that I use in an assert to make
> sure this is not accidentally used in the wrong context until 32 bit
> support is gone.
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> 753?? bs->load_at(_masm, IN_HEAP | ON_WEAK_OOP_REF, T_OBJECT,
>> 754?????????????? rax, field_address, /*tmp1*/ rbx, /*tmp_thread*/ rdx);
>>
>> This needs to distinguish between WEAK and PHANTOM references, else it
>> will break ZGC's concurrent reference processing.? (At least so long as
>> we still have to deal with finalization.)
>
> It does. This is ON_WEAK_OOP_REF. The get intrinsic is generated for
> WeakReference (and SoftReference) only. PhantomReference does not have
> a getter. Therefore, in all contexts this is intrinsified, it will
> refer to an ON_WEAK_OOP_REF.
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> 698 address
>> TemplateInterpreterGenerator::generate_Reference_get_entry(void) {
>>
>> Almost all the code here (and much of the commentary) was/is specific
>> to G1 (or SATB collectors).? Shouldn't it all be in the barrier_set's
>> load_at?? As it is now, if (say) we're using Parallel GC then I think
>> there's a bunch of additional code being generated and executed here
>> that wasn't present before.
>
> It is true that interpreter Reference.get() intrinsics with
> Parallel/CMS/Serial currently run a few instructions more than they
> need to pay for the abstraction. There is no doubt in my mind that
> this abstraction is worth the cost. Reference.get in the interpreter
> is not a hot path, and does not need to optimize every cycle.
>
> I changed the G1 comments to more general comments instead.
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/methodHandles_x86.cpp
>> 170?? __ load_heap_oop(method_temp, Address(recv,
>> NONZERO(java_lang_invoke_MethodHandle::form_offset_in_bytes())));
>> =>
>> 175?? bs->load_at(_masm, IN_HEAP, T_OBJECT, method_temp,
>> Address(recv,
>> NONZERO(java_lang_invoke_MethodHandle::form_offset_in_bytes())), t
>>
>> This doesn't look like an improvement in code readability to me.? Why
>> can't bs->load_at be the implementation of "__ load_heap_oop" ?
>>
>> And the lines are getting really long; so long that webrev is cutting
>> off the right end, so I can't review the new versions of the lines.
>
> Due to popular demand, I have done what you (and Coleen) both
> proposed: retained the load_heap_oop abstraction.
>
> Before:
> * load_heap_oop was the "raw" variant, similar to
> oopDesc::load_decode_heap_oop, which no longer exists.
>
> Now:
> * load_heap_oop calls MacroAssembler::access_load_at
> * access_load_at grabs the active BarrierSetAssembler and calls
> load_at on it.
> ... same idea for stores.
> * What used to be the raw versions for oop loads and stores, has moved
> to BarrierSetAssembler::load_at/store_at.
>
> These accessors now optionally take temporary register and decorator
> parameters than you don't have to supply:
> * supplying temprary register is polite to the GC so its accesses can
> be a bit better
> * supplying decorators can be done if it is not a default access. For
> example, AS_RAW can now be used to perform a raw load instead.
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/methodHandles_x86.cpp
>> 363???????? __ load_heap_oop(temp2_defc, member_clazz);
>> =>
>> 368???????? BarrierSetAssembler* bs =
>> BarrierSet::barrier_set()->barrier_set_assembler();
>> 369???????? Register rthread = LP64_ONLY(r15_thread) NOT_LP64(noreg);
>> 370???????? bs->load_at(_masm, IN_HEAP, T_OBJECT, temp2_defc,
>> member_clazz, noreg, rthread);
>>
>> Similarly, this doesn't seem like an improvement to me.? And there are
>> more like this.
>
> Fixed.
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/macroAssembler_x86.hpp
>>
>> It would reduce the clutter in this change to leave the as_Address
>> declarations where they were, since that place is now public, rather
>> than moving them to a different public section.
>
> Fixed.
>
>> ------------------------------------------------------------------------------
>>
>>
>> Generally, it seems like it might be nice for the MacroAssembler class
>> to have a reference to the barrier_set, or maybe even the bs's
>> assembler, rather than looking them up in various places, and in
>> different ways.? For example, I see each of
>>
>> ?? Universe::heap()->barrier_set()
>> ?? BarrerSet::barrier_set()
>>
>> used in various different places *in new code*.? Some consistency
>> would be nice.
>
> I think it seems fine to just fetch them only in the
> access_load/store_at wrappers.
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> 5249?? bs->load_at(this, IN_ROOT | ON_PHANTOM_OOP_REF, T_OBJECT,
>> 5250?????????????? value, Address(value,
>> -JNIHandles::weak_tag_value), tmp, thread);
>> 5251?? verify_oop(value);
>>
>> This puts the verify_oop after the G1 pre-barrier, where in the old
>> code verify_oop was before the pre-barrier. I remember the old order
>> being intentional, though don't off-hand recall how important that
>> was.? If for no other reason, it seems like the new order could rarely
>> (due to bad timing) have a bad oop reported somewhere far away during
>> SATB buffer processing, rather than at the point of the load.
>>
>> With the new version's order there could be one verify after the done
>> label.? That's just a minor nit.
>
> Conversely, I think the new order is better and more GC agnostic.
> It avoids, for example, sending in bad oops for verification with ZGC.
> The more GC-agnostic interface is that after the load_at
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>> 230 #ifdef _LP64
>> 231???? if (c_rarg1 != thread) {
>> 232?????? __ mov(c_rarg1, thread);
>> 233???? }
>> 234???? if (c_rarg0 != pre_val) {
>> 235?????? __ mov(c_rarg0, pre_val);
>> 236???? }
>> 237 #else
>> 238???? __ push(thread);
>> 239???? __ push(pre_val);
>> 240 #endif
>>
>> Old code used:
>>
>> ?? __ pass_arg1(thread);
>> ?? __ pass_arg0(pre_val);
>>
>> Why is this being changed?? Oh, pass_argN are static helpers not
>> available outside macroAssembler_x86.cpp.? Maybe they should be
>> exposed in some way, like public helpers in the x86 version of the
>> MacroAssembler class, rather than copied inline here (and maybe other
>> places?).
>
> Fixed. (added a wrapper for this to MacroAssembler, as suggested)
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/interp_masm_x86.cpp
>> Deleted these lines:
>> 519?? // The resulting oop is null if the reference is not yet resolved.
>> 520?? // It is Universe::the_null_sentinel() if the reference
>> resolved to NULL via condy.
>>
>> I don't think those comment lines should be deleted.
>
> Fixed.
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/gc/shared/modRefBarrierSetAssembler_x86.cpp
>> 86 void ModRefBarrierSetAssembler::store_at(MacroAssembler* masm,
>> DecoratorSet decorators, BasicType type,
>> 87??????????????????????????????????????? Address dst, Register val,
>> Register tmp1, Register tmp2) {
>> 88?? if (type == T_OBJECT || type == T_ARRAY) {
>> 89???? oop_store_at(masm, decorators, type, dst, val, tmp1, tmp2);
>> 90?? } else {
>> 91???? BarrierSetAssembler::store_at(masm, decorators, type, dst,
>> val, tmp1, tmp2);
>> 92?? }
>> 93 }
>>
>> Doesn't the conditional conversion from store_at to oop_store_at
>> actually indicate a bug in the caller? That is, calling store_at with
>> a oop (T_OBJECT or T_ARRAY) value seems like a bug, and should be
>> asserted against, rather than translating.
>>
>> And oop_store_at should assert that the value *is* an oop value.
>>
>> And should there be any verification that the decorators and the type
>> are consistent?
>>
>> But maybe I'm not understanding the protocol around oop_store_at?
>> There being no documentation, it seems entirely possible that I've
>> misunderstood something here.? Maybe I'm being confused by
>> similarities in naming with Access:: that don't hold?
>
> The confusion roots in that Access and BarrierSetAssembler are not
> structured exactly the same.
>
> Access provides store_at and oop_store_at. The reason for providing
> both of these, is that I could not safely infer whether the passed in
> parameters were oops or not without changing oop and narrowOop to
> always be value objects, which I did not dare to do as the generated
> code was worse.
>
> In BarrierSetAssembler, there is no such restriction. The type for the
> access is always passed in to store_at/load_at as BasicType. It is the
> responsibility of ModRefBarrierSetAssembler to filter away non-oop
> references, and call oop_store_at for relevant accesses for ModRef.
> This follows the same pattern that the arraycopy stubs used. This
> allows, e.g. CardTableModRef to only override oop_store_at. This is
> similar to how ModRefBarrierSet::AccessBarrier<decorators,
> BarrierSetT>::oop_store_in_heap calls the concrete barriersets for
> help generating that access. I hope this helps understanding the
> structuring.
>
> This is also the reason why G1BarrierSetAssembler::load_at checks
> whether it is an oop that is loaded or not, because loads are not
> riding on the ModRef layer, which only knows about oop stores.
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
>> 88 void CardTableBarrierSetAssembler::store_check(MacroAssembler*
>> masm, Register obj, Address dst) {
>> 89?? // Does a store check for the oop in register obj. The content of
>> 90?? // register obj is destroyed afterwards.
>>
>> The comment states obj is an oop, but when called by the precise case
>> of oop_store_at, it is not an oop, but rather a derived pointer.? I
>> think it's the comment that's wrong.
>
> I changed the comment to refer to obj as an oop* instead of an oop.
>
>> ------------------------------------------------------------------------------
>>
>>
>> I was surprised that oop_store_at is initially declared at the
>> ModRefBarrierSetAssembler level, rather than at the
>> BarrierSetAssembler level.
>>
>> I was also surprised to not see an oop_load_at.
>>
>> In Access we have _at suffixed operations paired with non-_at suffixed
>> operations, the difference being the _at suffixed operations have a
>> base object, to allow dealing with the brooks-ptr. I'm not finding any
>> such distinction in the xxxAssembler API. Presumably I've missed
>> something somewhere. How is that handled?
>
> I think I previously already explained this one. ModRef does not know
> about oop loads, only stores. Therefore, G1 must override load_at, and
> not oop_load_at.
>
> Thanks,
> /Erik
>
>> ------------------------------------------------------------------------------
>>
>>
>>
>
From gerard.ziemski at oracle.com Wed Apr 4 20:11:12 2018
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Wed, 4 Apr 2018 15:11:12 -0500
Subject: RFR: JDK-8196724: Change macosx deployment target to 10.9
In-Reply-To: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com>
References: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com>
Message-ID: <8763A5C5-FCD4-43A2-9DA9-B52FE240558B@oracle.com>
hi Erik,
Thanks for doing this.
I like how you are using a narrow mechanism to turn off only those warnings that come up due to deprecated APIs.
Just a quick verification question (not very familiar with the makefiles), in line like this:
DISABLED_WARNINGS_clang := deprecated-declarations
I assume we turn "deprecated-declarations? into ?-Wdeprecated-declarations? flag that then gets passed to the compiler?
cheers
> On Apr 4, 2018, at 1:30 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>
> This patch changes the values for the macosx version min and max settings from 10.7 to 10.9. It also changes the stdlib from libstdc++ to libc++ (explicitly for Hotspot and implicitly everywhere else). This change is necessary to keep up with newer toolchain versions on Macosx where using the old and no longer maintained libstdc++ has been deprecated. This is done in preparation for bumping the preferred Xcode version used for builds at Oracle.
>
> The switch has been tested for both Hotspot and client.
>
> The switch triggered some new deprecation warnings which have been silenced and followup bugs have been filed on the concerned team.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196724
>
> Webrev: http://cr.openjdk.java.net/~erikj/8196724/webrev.01/index.html
>
> /Erik
>
From coleen.phillimore at oracle.com Wed Apr 4 20:24:37 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 4 Apr 2018 16:24:37 -0400
Subject: RFR: 8200697: Add utility for spin wait with fallback to
yield/sleep
In-Reply-To: <E1CA91CD-9CF6-44D5-A7B7-0747AA648D65@oracle.com>
References: <E1CA91CD-9CF6-44D5-A7B7-0747AA648D65@oracle.com>
Message-ID: <9993b3a7-dc29-97a5-016f-d776c75898e0@oracle.com>
This looks good to me.? Looking forward to the other RFEs to use this.
thanks,
Coleen
On 4/4/18 2:53 PM, Kim Barrett wrote:
> Please review this addition of SpinYield utility class.
>
> It initially supplies a very simple policy: spin a configured number
> of times, then switch to yielding or (eventually) sleeping. Other
> policies may replace this one or be provided as alternatives in the
> future.
>
> This is joint work with Robbin Ehn.
>
> Robbin and I have immediate uses for this utility in changes we are
> developing. In addition, there are some existing places that might be
> converted to use this utility (or perhaps some extended version of
> it), including SafepointSynchronize::begin, ReadStableMark,
> Thread::SpinAcquire, and ParallelTaskTerminator::offer_termination.
> Those existing potential uses are not being changed here; for now,
> we're just adding the utility in support of our in-development
> changes. We plan to file followup RFEs to consider converting those
> potential uses.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8200697
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8200697/open.00/
>
> Testing:
> Added unit test of basic functionality.
> Build and hs-tier1 (for gtest) on all Oracle platforms.
>
From erik.joelsson at oracle.com Wed Apr 4 20:27:54 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 4 Apr 2018 13:27:54 -0700
Subject: RFR: JDK-8196724: Change macosx deployment target to 10.9
In-Reply-To: <8763A5C5-FCD4-43A2-9DA9-B52FE240558B@oracle.com>
References: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com>
<8763A5C5-FCD4-43A2-9DA9-B52FE240558B@oracle.com>
Message-ID: <f93eda1e-d89d-3c58-90db-1e7708e26908@oracle.com>
On 2018-04-04 13:11, Gerard Ziemski wrote:
> hi Erik,
>
> Thanks for doing this.
>
> I like how you are using a narrow mechanism to turn off only those warnings that come up due to deprecated APIs.
>
> Just a quick verification question (not very familiar with the makefiles), in line like this:
>
> DISABLED_WARNINGS_clang := deprecated-declarations
>
> I assume we turn "deprecated-declarations? into ?-Wdeprecated-declarations? flag that then gets passed to the compiler?
Yes, (to be more precise -Wno-deprecated-declarations) this is the
preferred way of disabling warnings in the build.
/Erik
>
> cheers
>
>> On Apr 4, 2018, at 1:30 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>
>> This patch changes the values for the macosx version min and max settings from 10.7 to 10.9. It also changes the stdlib from libstdc++ to libc++ (explicitly for Hotspot and implicitly everywhere else). This change is necessary to keep up with newer toolchain versions on Macosx where using the old and no longer maintained libstdc++ has been deprecated. This is done in preparation for bumping the preferred Xcode version used for builds at Oracle.
>>
>> The switch has been tested for both Hotspot and client.
>>
>> The switch triggered some new deprecation warnings which have been silenced and followup bugs have been filed on the concerned team.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196724
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8196724/webrev.01/index.html
>>
>> /Erik
>>
From rkennke at redhat.com Wed Apr 4 20:52:29 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 4 Apr 2018 22:52:29 +0200
Subject: RFR: 8199417: Modularize interpreter GC barriers
In-Reply-To: <5AC4D555.9040800@oracle.com>
References: <5AB8BDF9.4050106@oracle.com>
<3FFD79AD-84B8-4E9E-98E3-47ACBA01D91F@oracle.com>
<5AC4D555.9040800@oracle.com>
Message-ID: <d1fd6107-4592-0778-eaa5-d02d84ed0a1e@redhat.com>
Hi Erik,
the changes make sense to me, and look good.
I am thinking ahead a little bit and am wondering how to fit primitive
heap access into it. Will we have to add one load_heap_X for each
primitive type X, or call access_load_at() directly from all the places
in the interpreter?
Thanks,
Roman
> Hi Kim,
>
> Thank you for reviewing this.
>
> I have made a new webrev with proposed changes to the x86/x64 code
> reflecting the concerns you and Coleen have.
> I thought we should settle for something we like in the x86/x64 code
> before going ahead and changing the other platforms too much (I don't
> want to bug Martin and Roman too much before).
>
> New full webrev:
> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01/
>
> Incremental:
> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.00_01/
>
> On 2018-04-01 05:12, Kim Barrett wrote:
>>> On Mar 26, 2018, at 5:31 AM, Erik ?sterlund
>>> <erik.osterlund at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> The GC barriers for the interpreter are not as modular as they could
>>> be. They currently use switch statements to check which GC barrier
>>> set is being used, and call this or that barrier based on that, in a
>>> way that assumes GCs only use write barriers.
>>>
>>> This patch modularizes this by generating accesses in the interpreter
>>> with declarative semantics. Accesses to the heap may now use store_at
>>> and load_at functions of the BarrierSetAssembler, passing along
>>> appropriate arguments and decorators. Each concrete
>>> BarrierSetAssembler can override the access completely or sprinkle
>>> some appropriate GC barriers as necessary.
>>>
>>> Big thanks go to Martin Doerr and Roman Kennke, who helped plugging
>>> this into S390, PPC and AArch64 respectively.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.00/
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8199417
>>>
>>> Thanks,
>>> /Erik
>> I've only looked at the x86 and generic code so far. I have some
>> comments, but also a bunch of questions. I think I'm missing some
>> things somewhere. I'm sending what I've got so far anyway, and will
>> continue studying.
>>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>> 354?? // flatten object address if needed
>> 355?? // We do it regardless of precise because we need the registers
>>
>> There is no "precise" in this context.
>
> I thought "precise" was referring to the concept of precise card
> marking, as opposed to the variable 'precise' that used to exist. I have
> reworded the comment to reflect that.
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>> 364 #ifndef _LP64
>> 365?? InterpreterMacroAssembler *imasm =
>> static_cast<InterpreterMacroAssembler*>(masm);
>> 366 #endif
>>
>> In the old code, the function received an InterpreterMacroAssembler*.
>>
>> What is there about this context that lets us know the downcast is
>> safe here?? Is oop_store_at only ever called with an IMA*?? If so,
>> then why isn't that the parameter type.? If not, then what?
>
> Yes, this is indeed only used by the InterpreterMacroAssembler. But I
> wanted the interface to use MacroAssembler. Why?
>
> 1) It's only 32 bit x86 that relies on this property, and I hope it will
> go away soon, and the save bcp hack with it.
> 2) previous load_heap_oop is used not only in the
> InterpreterMacroAssembler, and I wanted the same assembler in load_at
> and store_at.
>
> So for now it is only used in InterpreterMacroAssembler, and I doubt
> that will change any time soon. I am hoping 32 bit support will be
> dropped before that, and the hack will go away. For now, I have added a
> virtual is_interpreter_masm() call that I use in an assert to make sure
> this is not accidentally used in the wrong context until 32 bit support
> is gone.
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> 753?? bs->load_at(_masm, IN_HEAP | ON_WEAK_OOP_REF, T_OBJECT,
>> 754?????????????? rax, field_address, /*tmp1*/ rbx, /*tmp_thread*/ rdx);
>>
>> This needs to distinguish between WEAK and PHANTOM references, else it
>> will break ZGC's concurrent reference processing.? (At least so long as
>> we still have to deal with finalization.)
>
> It does. This is ON_WEAK_OOP_REF. The get intrinsic is generated for
> WeakReference (and SoftReference) only. PhantomReference does not have a
> getter. Therefore, in all contexts this is intrinsified, it will refer
> to an ON_WEAK_OOP_REF.
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> 698 address
>> TemplateInterpreterGenerator::generate_Reference_get_entry(void) {
>>
>> Almost all the code here (and much of the commentary) was/is specific
>> to G1 (or SATB collectors).? Shouldn't it all be in the barrier_set's
>> load_at?? As it is now, if (say) we're using Parallel GC then I think
>> there's a bunch of additional code being generated and executed here
>> that wasn't present before.
>
> It is true that interpreter Reference.get() intrinsics with
> Parallel/CMS/Serial currently run a few instructions more than they need
> to pay for the abstraction. There is no doubt in my mind that this
> abstraction is worth the cost. Reference.get in the interpreter is not a
> hot path, and does not need to optimize every cycle.
>
> I changed the G1 comments to more general comments instead.
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/methodHandles_x86.cpp
>> 170?? __ load_heap_oop(method_temp, Address(recv,
>> NONZERO(java_lang_invoke_MethodHandle::form_offset_in_bytes())));
>> =>
>> 175?? bs->load_at(_masm, IN_HEAP, T_OBJECT, method_temp, Address(recv,
>> NONZERO(java_lang_invoke_MethodHandle::form_offset_in_bytes())), t
>>
>> This doesn't look like an improvement in code readability to me.? Why
>> can't bs->load_at be the implementation of "__ load_heap_oop" ?
>>
>> And the lines are getting really long; so long that webrev is cutting
>> off the right end, so I can't review the new versions of the lines.
>
> Due to popular demand, I have done what you (and Coleen) both proposed:
> retained the load_heap_oop abstraction.
>
> Before:
> * load_heap_oop was the "raw" variant, similar to
> oopDesc::load_decode_heap_oop, which no longer exists.
>
> Now:
> * load_heap_oop calls MacroAssembler::access_load_at
> * access_load_at grabs the active BarrierSetAssembler and calls load_at
> on it.
> ... same idea for stores.
> * What used to be the raw versions for oop loads and stores, has moved
> to BarrierSetAssembler::load_at/store_at.
>
> These accessors now optionally take temporary register and decorator
> parameters than you don't have to supply:
> * supplying temprary register is polite to the GC so its accesses can be
> a bit better
> * supplying decorators can be done if it is not a default access. For
> example, AS_RAW can now be used to perform a raw load instead.
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/methodHandles_x86.cpp
>> 363???????? __ load_heap_oop(temp2_defc, member_clazz);
>> =>
>> 368???????? BarrierSetAssembler* bs =
>> BarrierSet::barrier_set()->barrier_set_assembler();
>> 369???????? Register rthread = LP64_ONLY(r15_thread) NOT_LP64(noreg);
>> 370???????? bs->load_at(_masm, IN_HEAP, T_OBJECT, temp2_defc,
>> member_clazz, noreg, rthread);
>>
>> Similarly, this doesn't seem like an improvement to me.? And there are
>> more like this.
>
> Fixed.
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/macroAssembler_x86.hpp
>>
>> It would reduce the clutter in this change to leave the as_Address
>> declarations where they were, since that place is now public, rather
>> than moving them to a different public section.
>
> Fixed.
>
>> ------------------------------------------------------------------------------
>>
>>
>> Generally, it seems like it might be nice for the MacroAssembler class
>> to have a reference to the barrier_set, or maybe even the bs's
>> assembler, rather than looking them up in various places, and in
>> different ways.? For example, I see each of
>>
>> ?? Universe::heap()->barrier_set()
>> ?? BarrerSet::barrier_set()
>>
>> used in various different places *in new code*.? Some consistency
>> would be nice.
>
> I think it seems fine to just fetch them only in the
> access_load/store_at wrappers.
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> 5249?? bs->load_at(this, IN_ROOT | ON_PHANTOM_OOP_REF, T_OBJECT,
>> 5250?????????????? value, Address(value, -JNIHandles::weak_tag_value),
>> tmp, thread);
>> 5251?? verify_oop(value);
>>
>> This puts the verify_oop after the G1 pre-barrier, where in the old
>> code verify_oop was before the pre-barrier. I remember the old order
>> being intentional, though don't off-hand recall how important that
>> was.? If for no other reason, it seems like the new order could rarely
>> (due to bad timing) have a bad oop reported somewhere far away during
>> SATB buffer processing, rather than at the point of the load.
>>
>> With the new version's order there could be one verify after the done
>> label.? That's just a minor nit.
>
> Conversely, I think the new order is better and more GC agnostic.
> It avoids, for example, sending in bad oops for verification with ZGC.
> The more GC-agnostic interface is that after the load_at
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>> 230 #ifdef _LP64
>> 231???? if (c_rarg1 != thread) {
>> 232?????? __ mov(c_rarg1, thread);
>> 233???? }
>> 234???? if (c_rarg0 != pre_val) {
>> 235?????? __ mov(c_rarg0, pre_val);
>> 236???? }
>> 237 #else
>> 238???? __ push(thread);
>> 239???? __ push(pre_val);
>> 240 #endif
>>
>> Old code used:
>>
>> ?? __ pass_arg1(thread);
>> ?? __ pass_arg0(pre_val);
>>
>> Why is this being changed?? Oh, pass_argN are static helpers not
>> available outside macroAssembler_x86.cpp.? Maybe they should be
>> exposed in some way, like public helpers in the x86 version of the
>> MacroAssembler class, rather than copied inline here (and maybe other
>> places?).
>
> Fixed. (added a wrapper for this to MacroAssembler, as suggested)
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/interp_masm_x86.cpp
>> Deleted these lines:
>> 519?? // The resulting oop is null if the reference is not yet resolved.
>> 520?? // It is Universe::the_null_sentinel() if the reference resolved
>> to NULL via condy.
>>
>> I don't think those comment lines should be deleted.
>
> Fixed.
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/gc/shared/modRefBarrierSetAssembler_x86.cpp
>> 86 void ModRefBarrierSetAssembler::store_at(MacroAssembler* masm,
>> DecoratorSet decorators, BasicType type,
>> 87??????????????????????????????????????? Address dst, Register val,
>> Register tmp1, Register tmp2) {
>> 88?? if (type == T_OBJECT || type == T_ARRAY) {
>> 89???? oop_store_at(masm, decorators, type, dst, val, tmp1, tmp2);
>> 90?? } else {
>> 91???? BarrierSetAssembler::store_at(masm, decorators, type, dst, val,
>> tmp1, tmp2);
>> 92?? }
>> 93 }
>>
>> Doesn't the conditional conversion from store_at to oop_store_at
>> actually indicate a bug in the caller? That is, calling store_at with
>> a oop (T_OBJECT or T_ARRAY) value seems like a bug, and should be
>> asserted against, rather than translating.
>>
>> And oop_store_at should assert that the value *is* an oop value.
>>
>> And should there be any verification that the decorators and the type
>> are consistent?
>>
>> But maybe I'm not understanding the protocol around oop_store_at?
>> There being no documentation, it seems entirely possible that I've
>> misunderstood something here.? Maybe I'm being confused by
>> similarities in naming with Access:: that don't hold?
>
> The confusion roots in that Access and BarrierSetAssembler are not
> structured exactly the same.
>
> Access provides store_at and oop_store_at. The reason for providing both
> of these, is that I could not safely infer whether the passed in
> parameters were oops or not without changing oop and narrowOop to always
> be value objects, which I did not dare to do as the generated code was
> worse.
>
> In BarrierSetAssembler, there is no such restriction. The type for the
> access is always passed in to store_at/load_at as BasicType. It is the
> responsibility of ModRefBarrierSetAssembler to filter away non-oop
> references, and call oop_store_at for relevant accesses for ModRef. This
> follows the same pattern that the arraycopy stubs used. This allows,
> e.g. CardTableModRef to only override oop_store_at. This is similar to
> how ModRefBarrierSet::AccessBarrier<decorators,
> BarrierSetT>::oop_store_in_heap calls the concrete barriersets for help
> generating that access. I hope this helps understanding the structuring.
>
> This is also the reason why G1BarrierSetAssembler::load_at checks
> whether it is an oop that is loaded or not, because loads are not riding
> on the ModRef layer, which only knows about oop stores.
>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
>> 88 void CardTableBarrierSetAssembler::store_check(MacroAssembler*
>> masm, Register obj, Address dst) {
>> 89?? // Does a store check for the oop in register obj. The content of
>> 90?? // register obj is destroyed afterwards.
>>
>> The comment states obj is an oop, but when called by the precise case
>> of oop_store_at, it is not an oop, but rather a derived pointer.? I
>> think it's the comment that's wrong.
>
> I changed the comment to refer to obj as an oop* instead of an oop.
>
>> ------------------------------------------------------------------------------
>>
>>
>> I was surprised that oop_store_at is initially declared at the
>> ModRefBarrierSetAssembler level, rather than at the
>> BarrierSetAssembler level.
>>
>> I was also surprised to not see an oop_load_at.
>>
>> In Access we have _at suffixed operations paired with non-_at suffixed
>> operations, the difference being the _at suffixed operations have a
>> base object, to allow dealing with the brooks-ptr. I'm not finding any
>> such distinction in the xxxAssembler API. Presumably I've missed
>> something somewhere. How is that handled?
>
> I think I previously already explained this one. ModRef does not know
> about oop loads, only stores. Therefore, G1 must override load_at, and
> not oop_load_at.
>
> Thanks,
> /Erik
>
>> ------------------------------------------------------------------------------
>>
>>
>>
>
From erik.osterlund at oracle.com Wed Apr 4 20:58:44 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Wed, 4 Apr 2018 22:58:44 +0200
Subject: RFR: 8199417: Modularize interpreter GC barriers
In-Reply-To: <d1fd6107-4592-0778-eaa5-d02d84ed0a1e@redhat.com>
References: <5AB8BDF9.4050106@oracle.com>
<3FFD79AD-84B8-4E9E-98E3-47ACBA01D91F@oracle.com>
<5AC4D555.9040800@oracle.com>
<d1fd6107-4592-0778-eaa5-d02d84ed0a1e@redhat.com>
Message-ID: <f9a7133d-0bb3-0627-562e-5b5c83a80f1d@oracle.com>
Hi Roman,
On 2018-04-04 22:52, Roman Kennke wrote:
> Hi Erik,
>
> the changes make sense to me, and look good.
Thanks.
> I am thinking ahead a little bit and am wondering how to fit primitive
> heap access into it. Will we have to add one load_heap_X for each
> primitive type X, or call access_load_at() directly from all the places
> in the interpreter?
You would call access_load_at directly, I think, and add some backend
where there are now asserts in BarrierSetAssembler to perform the
primitive accesses, and stick some brooks pointers juice in your
ShenandoahBarrierSetAssembler.
/Erik
> Thanks,
> Roman
>
>> Hi Kim,
>>
>> Thank you for reviewing this.
>>
>> I have made a new webrev with proposed changes to the x86/x64 code
>> reflecting the concerns you and Coleen have.
>> I thought we should settle for something we like in the x86/x64 code
>> before going ahead and changing the other platforms too much (I don't
>> want to bug Martin and Roman too much before).
>>
>> New full webrev:
>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01/
>>
>> Incremental:
>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.00_01/
>>
>> On 2018-04-01 05:12, Kim Barrett wrote:
>>>> On Mar 26, 2018, at 5:31 AM, Erik ?sterlund
>>>> <erik.osterlund at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> The GC barriers for the interpreter are not as modular as they could
>>>> be. They currently use switch statements to check which GC barrier
>>>> set is being used, and call this or that barrier based on that, in a
>>>> way that assumes GCs only use write barriers.
>>>>
>>>> This patch modularizes this by generating accesses in the interpreter
>>>> with declarative semantics. Accesses to the heap may now use store_at
>>>> and load_at functions of the BarrierSetAssembler, passing along
>>>> appropriate arguments and decorators. Each concrete
>>>> BarrierSetAssembler can override the access completely or sprinkle
>>>> some appropriate GC barriers as necessary.
>>>>
>>>> Big thanks go to Martin Doerr and Roman Kennke, who helped plugging
>>>> this into S390, PPC and AArch64 respectively.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.00/
>>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8199417
>>>>
>>>> Thanks,
>>>> /Erik
>>> I've only looked at the x86 and generic code so far. I have some
>>> comments, but also a bunch of questions. I think I'm missing some
>>> things somewhere. I'm sending what I've got so far anyway, and will
>>> continue studying.
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>>> 354?? // flatten object address if needed
>>> 355?? // We do it regardless of precise because we need the registers
>>>
>>> There is no "precise" in this context.
>> I thought "precise" was referring to the concept of precise card
>> marking, as opposed to the variable 'precise' that used to exist. I have
>> reworded the comment to reflect that.
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>>> 364 #ifndef _LP64
>>> 365?? InterpreterMacroAssembler *imasm =
>>> static_cast<InterpreterMacroAssembler*>(masm);
>>> 366 #endif
>>>
>>> In the old code, the function received an InterpreterMacroAssembler*.
>>>
>>> What is there about this context that lets us know the downcast is
>>> safe here?? Is oop_store_at only ever called with an IMA*?? If so,
>>> then why isn't that the parameter type.? If not, then what?
>> Yes, this is indeed only used by the InterpreterMacroAssembler. But I
>> wanted the interface to use MacroAssembler. Why?
>>
>> 1) It's only 32 bit x86 that relies on this property, and I hope it will
>> go away soon, and the save bcp hack with it.
>> 2) previous load_heap_oop is used not only in the
>> InterpreterMacroAssembler, and I wanted the same assembler in load_at
>> and store_at.
>>
>> So for now it is only used in InterpreterMacroAssembler, and I doubt
>> that will change any time soon. I am hoping 32 bit support will be
>> dropped before that, and the hack will go away. For now, I have added a
>> virtual is_interpreter_masm() call that I use in an assert to make sure
>> this is not accidentally used in the wrong context until 32 bit support
>> is gone.
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>>> 753?? bs->load_at(_masm, IN_HEAP | ON_WEAK_OOP_REF, T_OBJECT,
>>> 754?????????????? rax, field_address, /*tmp1*/ rbx, /*tmp_thread*/ rdx);
>>>
>>> This needs to distinguish between WEAK and PHANTOM references, else it
>>> will break ZGC's concurrent reference processing.? (At least so long as
>>> we still have to deal with finalization.)
>> It does. This is ON_WEAK_OOP_REF. The get intrinsic is generated for
>> WeakReference (and SoftReference) only. PhantomReference does not have a
>> getter. Therefore, in all contexts this is intrinsified, it will refer
>> to an ON_WEAK_OOP_REF.
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>>> 698 address
>>> TemplateInterpreterGenerator::generate_Reference_get_entry(void) {
>>>
>>> Almost all the code here (and much of the commentary) was/is specific
>>> to G1 (or SATB collectors).? Shouldn't it all be in the barrier_set's
>>> load_at?? As it is now, if (say) we're using Parallel GC then I think
>>> there's a bunch of additional code being generated and executed here
>>> that wasn't present before.
>> It is true that interpreter Reference.get() intrinsics with
>> Parallel/CMS/Serial currently run a few instructions more than they need
>> to pay for the abstraction. There is no doubt in my mind that this
>> abstraction is worth the cost. Reference.get in the interpreter is not a
>> hot path, and does not need to optimize every cycle.
>>
>> I changed the G1 comments to more general comments instead.
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/methodHandles_x86.cpp
>>> 170?? __ load_heap_oop(method_temp, Address(recv,
>>> NONZERO(java_lang_invoke_MethodHandle::form_offset_in_bytes())));
>>> =>
>>> 175?? bs->load_at(_masm, IN_HEAP, T_OBJECT, method_temp, Address(recv,
>>> NONZERO(java_lang_invoke_MethodHandle::form_offset_in_bytes())), t
>>>
>>> This doesn't look like an improvement in code readability to me.? Why
>>> can't bs->load_at be the implementation of "__ load_heap_oop" ?
>>>
>>> And the lines are getting really long; so long that webrev is cutting
>>> off the right end, so I can't review the new versions of the lines.
>> Due to popular demand, I have done what you (and Coleen) both proposed:
>> retained the load_heap_oop abstraction.
>>
>> Before:
>> * load_heap_oop was the "raw" variant, similar to
>> oopDesc::load_decode_heap_oop, which no longer exists.
>>
>> Now:
>> * load_heap_oop calls MacroAssembler::access_load_at
>> * access_load_at grabs the active BarrierSetAssembler and calls load_at
>> on it.
>> ... same idea for stores.
>> * What used to be the raw versions for oop loads and stores, has moved
>> to BarrierSetAssembler::load_at/store_at.
>>
>> These accessors now optionally take temporary register and decorator
>> parameters than you don't have to supply:
>> * supplying temprary register is polite to the GC so its accesses can be
>> a bit better
>> * supplying decorators can be done if it is not a default access. For
>> example, AS_RAW can now be used to perform a raw load instead.
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/methodHandles_x86.cpp
>>> 363???????? __ load_heap_oop(temp2_defc, member_clazz);
>>> =>
>>> 368???????? BarrierSetAssembler* bs =
>>> BarrierSet::barrier_set()->barrier_set_assembler();
>>> 369???????? Register rthread = LP64_ONLY(r15_thread) NOT_LP64(noreg);
>>> 370???????? bs->load_at(_masm, IN_HEAP, T_OBJECT, temp2_defc,
>>> member_clazz, noreg, rthread);
>>>
>>> Similarly, this doesn't seem like an improvement to me.? And there are
>>> more like this.
>> Fixed.
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/macroAssembler_x86.hpp
>>>
>>> It would reduce the clutter in this change to leave the as_Address
>>> declarations where they were, since that place is now public, rather
>>> than moving them to a different public section.
>> Fixed.
>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>> Generally, it seems like it might be nice for the MacroAssembler class
>>> to have a reference to the barrier_set, or maybe even the bs's
>>> assembler, rather than looking them up in various places, and in
>>> different ways.? For example, I see each of
>>>
>>> ?? Universe::heap()->barrier_set()
>>> ?? BarrerSet::barrier_set()
>>>
>>> used in various different places *in new code*.? Some consistency
>>> would be nice.
>> I think it seems fine to just fetch them only in the
>> access_load/store_at wrappers.
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/macroAssembler_x86.cpp
>>> 5249?? bs->load_at(this, IN_ROOT | ON_PHANTOM_OOP_REF, T_OBJECT,
>>> 5250?????????????? value, Address(value, -JNIHandles::weak_tag_value),
>>> tmp, thread);
>>> 5251?? verify_oop(value);
>>>
>>> This puts the verify_oop after the G1 pre-barrier, where in the old
>>> code verify_oop was before the pre-barrier. I remember the old order
>>> being intentional, though don't off-hand recall how important that
>>> was.? If for no other reason, it seems like the new order could rarely
>>> (due to bad timing) have a bad oop reported somewhere far away during
>>> SATB buffer processing, rather than at the point of the load.
>>>
>>> With the new version's order there could be one verify after the done
>>> label.? That's just a minor nit.
>> Conversely, I think the new order is better and more GC agnostic.
>> It avoids, for example, sending in bad oops for verification with ZGC.
>> The more GC-agnostic interface is that after the load_at
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>>> 230 #ifdef _LP64
>>> 231???? if (c_rarg1 != thread) {
>>> 232?????? __ mov(c_rarg1, thread);
>>> 233???? }
>>> 234???? if (c_rarg0 != pre_val) {
>>> 235?????? __ mov(c_rarg0, pre_val);
>>> 236???? }
>>> 237 #else
>>> 238???? __ push(thread);
>>> 239???? __ push(pre_val);
>>> 240 #endif
>>>
>>> Old code used:
>>>
>>> ?? __ pass_arg1(thread);
>>> ?? __ pass_arg0(pre_val);
>>>
>>> Why is this being changed?? Oh, pass_argN are static helpers not
>>> available outside macroAssembler_x86.cpp.? Maybe they should be
>>> exposed in some way, like public helpers in the x86 version of the
>>> MacroAssembler class, rather than copied inline here (and maybe other
>>> places?).
>> Fixed. (added a wrapper for this to MacroAssembler, as suggested)
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/interp_masm_x86.cpp
>>> Deleted these lines:
>>> 519?? // The resulting oop is null if the reference is not yet resolved.
>>> 520?? // It is Universe::the_null_sentinel() if the reference resolved
>>> to NULL via condy.
>>>
>>> I don't think those comment lines should be deleted.
>> Fixed.
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/gc/shared/modRefBarrierSetAssembler_x86.cpp
>>> 86 void ModRefBarrierSetAssembler::store_at(MacroAssembler* masm,
>>> DecoratorSet decorators, BasicType type,
>>> 87??????????????????????????????????????? Address dst, Register val,
>>> Register tmp1, Register tmp2) {
>>> 88?? if (type == T_OBJECT || type == T_ARRAY) {
>>> 89???? oop_store_at(masm, decorators, type, dst, val, tmp1, tmp2);
>>> 90?? } else {
>>> 91???? BarrierSetAssembler::store_at(masm, decorators, type, dst, val,
>>> tmp1, tmp2);
>>> 92?? }
>>> 93 }
>>>
>>> Doesn't the conditional conversion from store_at to oop_store_at
>>> actually indicate a bug in the caller? That is, calling store_at with
>>> a oop (T_OBJECT or T_ARRAY) value seems like a bug, and should be
>>> asserted against, rather than translating.
>>>
>>> And oop_store_at should assert that the value *is* an oop value.
>>>
>>> And should there be any verification that the decorators and the type
>>> are consistent?
>>>
>>> But maybe I'm not understanding the protocol around oop_store_at?
>>> There being no documentation, it seems entirely possible that I've
>>> misunderstood something here.? Maybe I'm being confused by
>>> similarities in naming with Access:: that don't hold?
>> The confusion roots in that Access and BarrierSetAssembler are not
>> structured exactly the same.
>>
>> Access provides store_at and oop_store_at. The reason for providing both
>> of these, is that I could not safely infer whether the passed in
>> parameters were oops or not without changing oop and narrowOop to always
>> be value objects, which I did not dare to do as the generated code was
>> worse.
>>
>> In BarrierSetAssembler, there is no such restriction. The type for the
>> access is always passed in to store_at/load_at as BasicType. It is the
>> responsibility of ModRefBarrierSetAssembler to filter away non-oop
>> references, and call oop_store_at for relevant accesses for ModRef. This
>> follows the same pattern that the arraycopy stubs used. This allows,
>> e.g. CardTableModRef to only override oop_store_at. This is similar to
>> how ModRefBarrierSet::AccessBarrier<decorators,
>> BarrierSetT>::oop_store_in_heap calls the concrete barriersets for help
>> generating that access. I hope this helps understanding the structuring.
>>
>> This is also the reason why G1BarrierSetAssembler::load_at checks
>> whether it is an oop that is loaded or not, because loads are not riding
>> on the ModRef layer, which only knows about oop stores.
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
>>> 88 void CardTableBarrierSetAssembler::store_check(MacroAssembler*
>>> masm, Register obj, Address dst) {
>>> 89?? // Does a store check for the oop in register obj. The content of
>>> 90?? // register obj is destroyed afterwards.
>>>
>>> The comment states obj is an oop, but when called by the precise case
>>> of oop_store_at, it is not an oop, but rather a derived pointer.? I
>>> think it's the comment that's wrong.
>> I changed the comment to refer to obj as an oop* instead of an oop.
>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>> I was surprised that oop_store_at is initially declared at the
>>> ModRefBarrierSetAssembler level, rather than at the
>>> BarrierSetAssembler level.
>>>
>>> I was also surprised to not see an oop_load_at.
>>>
>>> In Access we have _at suffixed operations paired with non-_at suffixed
>>> operations, the difference being the _at suffixed operations have a
>>> base object, to allow dealing with the brooks-ptr. I'm not finding any
>>> such distinction in the xxxAssembler API. Presumably I've missed
>>> something somewhere. How is that handled?
>> I think I previously already explained this one. ModRef does not know
>> about oop loads, only stores. Therefore, G1 must override load_at, and
>> not oop_load_at.
>>
>> Thanks,
>> /Erik
>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>>
>
From erik.osterlund at oracle.com Wed Apr 4 21:03:52 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Wed, 4 Apr 2018 23:03:52 +0200
Subject: RFR: 8199417: Modularize interpreter GC barriers
In-Reply-To: <722ff8a5-a919-cf07-31c6-637303ac1171@oracle.com>
References: <5AB8BDF9.4050106@oracle.com>
<3FFD79AD-84B8-4E9E-98E3-47ACBA01D91F@oracle.com>
<5AC4D555.9040800@oracle.com>
<722ff8a5-a919-cf07-31c6-637303ac1171@oracle.com>
Message-ID: <3fa43c25-7878-fa96-6b84-4518f1ca0eb0@oracle.com>
Hi Coleen,
On 2018-04-04 22:05, coleen.phillimore at oracle.com wrote:
>
> Thank you for keeping load_heap_oop in the macroAssembler, I like it
> and think it should be consistent with the rest of the platforms.
I'm glad you liked it.
> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01/src/hotspot/cpu/x86/templateTable_x86.cpp.udiff.html
>
>
> + do_oop_store(_masm, Address(rdx, 0), rax, IN_HEAP_ARRAY);
>
>
> What happens if someone misses IN_HEAP_ARRAY and puts IN_HEAP instead?
Then we will miss performing precise card marking, which we expect
should happen when either 1) storing into an array, or 2) store using
unsafe, which in turn could be into an array.
> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp.udiff.html
>
>
> + do_oop_store(_masm, element_address, noreg, IN_HEAP | IN_HEAP_ARRAY);
>
>
> Here it has both for aarch64.
do_oop_store in the templateTable code is always IN_HEAP. So that seems
redundant.
> I reviewed the x86 interpreter code, and will review the rest when/if
> people say that load_heap_oop is good.
Okay, thanks. In that case, I will start to polish the SPARC code with
similar wrappers meanwhile.
Thanks,
/Erik
> Thanks,
> Coleen
>
>
> On 4/4/18 9:38 AM, Erik ?sterlund wrote:
>> Hi Kim,
>>
>> Thank you for reviewing this.
>>
>> I have made a new webrev with proposed changes to the x86/x64 code
>> reflecting the concerns you and Coleen have.
>> I thought we should settle for something we like in the x86/x64 code
>> before going ahead and changing the other platforms too much (I don't
>> want to bug Martin and Roman too much before).
>>
>> New full webrev:
>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01/
>>
>> Incremental:
>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.00_01/
>>
>> On 2018-04-01 05:12, Kim Barrett wrote:
>>>> On Mar 26, 2018, at 5:31 AM, Erik ?sterlund
>>>> <erik.osterlund at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> The GC barriers for the interpreter are not as modular as they
>>>> could be. They currently use switch statements to check which GC
>>>> barrier set is being used, and call this or that barrier based on
>>>> that, in a way that assumes GCs only use write barriers.
>>>>
>>>> This patch modularizes this by generating accesses in the
>>>> interpreter with declarative semantics. Accesses to the heap may
>>>> now use store_at and load_at functions of the BarrierSetAssembler,
>>>> passing along appropriate arguments and decorators. Each concrete
>>>> BarrierSetAssembler can override the access completely or sprinkle
>>>> some appropriate GC barriers as necessary.
>>>>
>>>> Big thanks go to Martin Doerr and Roman Kennke, who helped plugging
>>>> this into S390, PPC and AArch64 respectively.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.00/
>>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8199417
>>>>
>>>> Thanks,
>>>> /Erik
>>> I've only looked at the x86 and generic code so far. I have some
>>> comments, but also a bunch of questions. I think I'm missing some
>>> things somewhere. I'm sending what I've got so far anyway, and will
>>> continue studying.
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>>> 354?? // flatten object address if needed
>>> 355?? // We do it regardless of precise because we need the registers
>>>
>>> There is no "precise" in this context.
>>
>> I thought "precise" was referring to the concept of precise card
>> marking, as opposed to the variable 'precise' that used to exist. I
>> have reworded the comment to reflect that.
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>>> 364 #ifndef _LP64
>>> 365?? InterpreterMacroAssembler *imasm =
>>> static_cast<InterpreterMacroAssembler*>(masm);
>>> 366 #endif
>>>
>>> In the old code, the function received an InterpreterMacroAssembler*.
>>>
>>> What is there about this context that lets us know the downcast is
>>> safe here?? Is oop_store_at only ever called with an IMA*?? If so,
>>> then why isn't that the parameter type.? If not, then what?
>>
>> Yes, this is indeed only used by the InterpreterMacroAssembler. But I
>> wanted the interface to use MacroAssembler. Why?
>>
>> 1) It's only 32 bit x86 that relies on this property, and I hope it
>> will go away soon, and the save bcp hack with it.
>> 2) previous load_heap_oop is used not only in the
>> InterpreterMacroAssembler, and I wanted the same assembler in load_at
>> and store_at.
>>
>> So for now it is only used in InterpreterMacroAssembler, and I doubt
>> that will change any time soon. I am hoping 32 bit support will be
>> dropped before that, and the hack will go away. For now, I have added
>> a virtual is_interpreter_masm() call that I use in an assert to make
>> sure this is not accidentally used in the wrong context until 32 bit
>> support is gone.
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>>> 753?? bs->load_at(_masm, IN_HEAP | ON_WEAK_OOP_REF, T_OBJECT,
>>> 754?????????????? rax, field_address, /*tmp1*/ rbx, /*tmp_thread*/
>>> rdx);
>>>
>>> This needs to distinguish between WEAK and PHANTOM references, else it
>>> will break ZGC's concurrent reference processing.? (At least so long as
>>> we still have to deal with finalization.)
>>
>> It does. This is ON_WEAK_OOP_REF. The get intrinsic is generated for
>> WeakReference (and SoftReference) only. PhantomReference does not
>> have a getter. Therefore, in all contexts this is intrinsified, it
>> will refer to an ON_WEAK_OOP_REF.
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>>> 698 address
>>> TemplateInterpreterGenerator::generate_Reference_get_entry(void) {
>>>
>>> Almost all the code here (and much of the commentary) was/is specific
>>> to G1 (or SATB collectors).? Shouldn't it all be in the barrier_set's
>>> load_at?? As it is now, if (say) we're using Parallel GC then I think
>>> there's a bunch of additional code being generated and executed here
>>> that wasn't present before.
>>
>> It is true that interpreter Reference.get() intrinsics with
>> Parallel/CMS/Serial currently run a few instructions more than they
>> need to pay for the abstraction. There is no doubt in my mind that
>> this abstraction is worth the cost. Reference.get in the interpreter
>> is not a hot path, and does not need to optimize every cycle.
>>
>> I changed the G1 comments to more general comments instead.
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/methodHandles_x86.cpp
>>> 170?? __ load_heap_oop(method_temp, Address(recv,
>>> NONZERO(java_lang_invoke_MethodHandle::form_offset_in_bytes())));
>>> =>
>>> 175?? bs->load_at(_masm, IN_HEAP, T_OBJECT, method_temp,
>>> Address(recv,
>>> NONZERO(java_lang_invoke_MethodHandle::form_offset_in_bytes())), t
>>>
>>> This doesn't look like an improvement in code readability to me.? Why
>>> can't bs->load_at be the implementation of "__ load_heap_oop" ?
>>>
>>> And the lines are getting really long; so long that webrev is cutting
>>> off the right end, so I can't review the new versions of the lines.
>>
>> Due to popular demand, I have done what you (and Coleen) both
>> proposed: retained the load_heap_oop abstraction.
>>
>> Before:
>> * load_heap_oop was the "raw" variant, similar to
>> oopDesc::load_decode_heap_oop, which no longer exists.
>>
>> Now:
>> * load_heap_oop calls MacroAssembler::access_load_at
>> * access_load_at grabs the active BarrierSetAssembler and calls
>> load_at on it.
>> ... same idea for stores.
>> * What used to be the raw versions for oop loads and stores, has
>> moved to BarrierSetAssembler::load_at/store_at.
>>
>> These accessors now optionally take temporary register and decorator
>> parameters than you don't have to supply:
>> * supplying temprary register is polite to the GC so its accesses can
>> be a bit better
>> * supplying decorators can be done if it is not a default access. For
>> example, AS_RAW can now be used to perform a raw load instead.
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/methodHandles_x86.cpp
>>> 363???????? __ load_heap_oop(temp2_defc, member_clazz);
>>> =>
>>> 368???????? BarrierSetAssembler* bs =
>>> BarrierSet::barrier_set()->barrier_set_assembler();
>>> 369???????? Register rthread = LP64_ONLY(r15_thread) NOT_LP64(noreg);
>>> 370???????? bs->load_at(_masm, IN_HEAP, T_OBJECT, temp2_defc,
>>> member_clazz, noreg, rthread);
>>>
>>> Similarly, this doesn't seem like an improvement to me.? And there are
>>> more like this.
>>
>> Fixed.
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/macroAssembler_x86.hpp
>>>
>>> It would reduce the clutter in this change to leave the as_Address
>>> declarations where they were, since that place is now public, rather
>>> than moving them to a different public section.
>>
>> Fixed.
>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>> Generally, it seems like it might be nice for the MacroAssembler class
>>> to have a reference to the barrier_set, or maybe even the bs's
>>> assembler, rather than looking them up in various places, and in
>>> different ways.? For example, I see each of
>>>
>>> ?? Universe::heap()->barrier_set()
>>> ?? BarrerSet::barrier_set()
>>>
>>> used in various different places *in new code*.? Some consistency
>>> would be nice.
>>
>> I think it seems fine to just fetch them only in the
>> access_load/store_at wrappers.
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/macroAssembler_x86.cpp
>>> 5249?? bs->load_at(this, IN_ROOT | ON_PHANTOM_OOP_REF, T_OBJECT,
>>> 5250?????????????? value, Address(value,
>>> -JNIHandles::weak_tag_value), tmp, thread);
>>> 5251?? verify_oop(value);
>>>
>>> This puts the verify_oop after the G1 pre-barrier, where in the old
>>> code verify_oop was before the pre-barrier. I remember the old order
>>> being intentional, though don't off-hand recall how important that
>>> was.? If for no other reason, it seems like the new order could rarely
>>> (due to bad timing) have a bad oop reported somewhere far away during
>>> SATB buffer processing, rather than at the point of the load.
>>>
>>> With the new version's order there could be one verify after the done
>>> label.? That's just a minor nit.
>>
>> Conversely, I think the new order is better and more GC agnostic.
>> It avoids, for example, sending in bad oops for verification with
>> ZGC. The more GC-agnostic interface is that after the load_at
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>>> 230 #ifdef _LP64
>>> 231???? if (c_rarg1 != thread) {
>>> 232?????? __ mov(c_rarg1, thread);
>>> 233???? }
>>> 234???? if (c_rarg0 != pre_val) {
>>> 235?????? __ mov(c_rarg0, pre_val);
>>> 236???? }
>>> 237 #else
>>> 238???? __ push(thread);
>>> 239???? __ push(pre_val);
>>> 240 #endif
>>>
>>> Old code used:
>>>
>>> ?? __ pass_arg1(thread);
>>> ?? __ pass_arg0(pre_val);
>>>
>>> Why is this being changed?? Oh, pass_argN are static helpers not
>>> available outside macroAssembler_x86.cpp.? Maybe they should be
>>> exposed in some way, like public helpers in the x86 version of the
>>> MacroAssembler class, rather than copied inline here (and maybe other
>>> places?).
>>
>> Fixed. (added a wrapper for this to MacroAssembler, as suggested)
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/interp_masm_x86.cpp
>>> Deleted these lines:
>>> 519?? // The resulting oop is null if the reference is not yet
>>> resolved.
>>> 520?? // It is Universe::the_null_sentinel() if the reference
>>> resolved to NULL via condy.
>>>
>>> I don't think those comment lines should be deleted.
>>
>> Fixed.
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/gc/shared/modRefBarrierSetAssembler_x86.cpp
>>> 86 void ModRefBarrierSetAssembler::store_at(MacroAssembler* masm,
>>> DecoratorSet decorators, BasicType type,
>>> 87??????????????????????????????????????? Address dst, Register val,
>>> Register tmp1, Register tmp2) {
>>> 88?? if (type == T_OBJECT || type == T_ARRAY) {
>>> 89???? oop_store_at(masm, decorators, type, dst, val, tmp1, tmp2);
>>> 90?? } else {
>>> 91???? BarrierSetAssembler::store_at(masm, decorators, type, dst,
>>> val, tmp1, tmp2);
>>> 92?? }
>>> 93 }
>>>
>>> Doesn't the conditional conversion from store_at to oop_store_at
>>> actually indicate a bug in the caller? That is, calling store_at with
>>> a oop (T_OBJECT or T_ARRAY) value seems like a bug, and should be
>>> asserted against, rather than translating.
>>>
>>> And oop_store_at should assert that the value *is* an oop value.
>>>
>>> And should there be any verification that the decorators and the type
>>> are consistent?
>>>
>>> But maybe I'm not understanding the protocol around oop_store_at?
>>> There being no documentation, it seems entirely possible that I've
>>> misunderstood something here.? Maybe I'm being confused by
>>> similarities in naming with Access:: that don't hold?
>>
>> The confusion roots in that Access and BarrierSetAssembler are not
>> structured exactly the same.
>>
>> Access provides store_at and oop_store_at. The reason for providing
>> both of these, is that I could not safely infer whether the passed in
>> parameters were oops or not without changing oop and narrowOop to
>> always be value objects, which I did not dare to do as the generated
>> code was worse.
>>
>> In BarrierSetAssembler, there is no such restriction. The type for
>> the access is always passed in to store_at/load_at as BasicType. It
>> is the responsibility of ModRefBarrierSetAssembler to filter away
>> non-oop references, and call oop_store_at for relevant accesses for
>> ModRef. This follows the same pattern that the arraycopy stubs used.
>> This allows, e.g. CardTableModRef to only override oop_store_at. This
>> is similar to how ModRefBarrierSet::AccessBarrier<decorators,
>> BarrierSetT>::oop_store_in_heap calls the concrete barriersets for
>> help generating that access. I hope this helps understanding the
>> structuring.
>>
>> This is also the reason why G1BarrierSetAssembler::load_at checks
>> whether it is an oop that is loaded or not, because loads are not
>> riding on the ModRef layer, which only knows about oop stores.
>>
>>> ------------------------------------------------------------------------------
>>>
>>> src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
>>> 88 void CardTableBarrierSetAssembler::store_check(MacroAssembler*
>>> masm, Register obj, Address dst) {
>>> 89?? // Does a store check for the oop in register obj. The content of
>>> 90?? // register obj is destroyed afterwards.
>>>
>>> The comment states obj is an oop, but when called by the precise case
>>> of oop_store_at, it is not an oop, but rather a derived pointer.? I
>>> think it's the comment that's wrong.
>>
>> I changed the comment to refer to obj as an oop* instead of an oop.
>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>> I was surprised that oop_store_at is initially declared at the
>>> ModRefBarrierSetAssembler level, rather than at the
>>> BarrierSetAssembler level.
>>>
>>> I was also surprised to not see an oop_load_at.
>>>
>>> In Access we have _at suffixed operations paired with non-_at suffixed
>>> operations, the difference being the _at suffixed operations have a
>>> base object, to allow dealing with the brooks-ptr. I'm not finding any
>>> such distinction in the xxxAssembler API. Presumably I've missed
>>> something somewhere. How is that handled?
>>
>> I think I previously already explained this one. ModRef does not know
>> about oop loads, only stores. Therefore, G1 must override load_at,
>> and not oop_load_at.
>>
>> Thanks,
>> /Erik
>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>>
>>
>
From david.holmes at oracle.com Wed Apr 4 22:12:35 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Apr 2018 08:12:35 +1000
Subject: Execution problems with Atomic Operations on OpenJDK10 for ARM5
Soft Float
In-Reply-To: <209e831bd10929184afdbedb7e811652@juanantonio.info>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
Message-ID: <15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
Hi,
This was already reported as:
https://bugs.openjdk.java.net/browse/JDK-8200580
to which I have responded and closed the bug as this is not a supported
platform.
As per the bug report this may be due to the change to AssumeMP to be
true, but there is no MP support for ARMv5.
David
On 4/04/2018 8:29 PM, bren at juanantonio.info wrote:
> Good morning,
>
> Mi name is Juan Antonio Bre?a Moral, I am developing a set of Java
> libraries for Lego Mindstorms EV3, an ARM5 robotics device and recently,
> we build OpenJDK 9 with success but with OpenJDK 10, we have found some
> problems when we execute some Java programs.
>
> Repository to build OpenJDK 9/10 for ARM5 Soft Float:
> https://github.com/ev3dev-lang-java/openjdk-ev3
>
> To test the JVM, I am using the following repo to test the VM:
> https://github.com/ev3dev-lang-java/vmbenchmarks
>
> And this is the output with the error:
>
> robot at ev3dev:~$ java -jar benchmarks.jar -f 1
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.openjdk.jmh.util.Utils
> (file:/home/robot/benchmarks.jar) to field java.io.Console.cs
> WARNING: Please consider reporting this to the maintainers of
> org.openjdk.jmh.util.Utils
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on this
> platform ================
>
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
> platform ================
>
>
> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on this
> platform ================
>
> [thread 4430 also had an error]
> [error occurred during error reporting ((null)), id 0xe0000000]
>
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
> platform ================
>
>
> [error occurred during error reporting (printing fatal error message),
> id 0xe0000000]
>
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
> platform ================
>
>
> [error occurred during error reporting (printing type of error), id
> 0xe0000000]
>
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
> platform ================
>
>
> [error occurred during error reporting (printing stack bounds), id
> 0xe0000000]
>
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
> platform ================
>
>
> [error occurred during error reporting (printing native stack), id
> 0xe0000000]
>
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
> platform ================
>
>
> [error occurred during error reporting (printing Java stack), id
> 0xe0000000]
>
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
> platform ================
>
>
> [error occurred during error reporting (printing target Java thread
> stack), id 0xe0000000]
>
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
> platform ================
>
>
> [error occurred during error reporting (printing siginfo), id 0xe0000000]
>
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
> platform ================
>
>
> [error occurred during error reporting (CDS archive access warning), id
> 0xe0000000]
>
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
> platform ================
>
>
> [error occurred during error reporting (printing register info), id
> 0xe0000000]
>
> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
> platform ================
>
>
> [Too many errors, abort]
> Aborted
>
> I think that in OpenJDK10 changed something in compare to OpenJDK9 in
> relation to ARM5 support.
>
> Any idea?
>
> Many thanks in advance.
>
> Cheers
>
> Juan Antonio
>
From kim.barrett at oracle.com Wed Apr 4 22:23:04 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 4 Apr 2018 18:23:04 -0400
Subject: RFR: 8200697: Add utility for spin wait with fallback to
yield/sleep
In-Reply-To: <9993b3a7-dc29-97a5-016f-d776c75898e0@oracle.com>
References: <E1CA91CD-9CF6-44D5-A7B7-0747AA648D65@oracle.com>
<9993b3a7-dc29-97a5-016f-d776c75898e0@oracle.com>
Message-ID: <46774664-B40E-453A-8953-5A46D8C96A55@oracle.com>
> On Apr 4, 2018, at 4:24 PM, coleen.phillimore at oracle.com wrote:
>
>
> This looks good to me. Looking forward to the other RFEs to use this.
> thanks,
> Coleen
Thanks.
From jcbeyler at google.com Wed Apr 4 22:23:47 2018
From: jcbeyler at google.com (JC Beyler)
Date: Wed, 04 Apr 2018 22:23:47 +0000
Subject: JEP 331: Low-Overhead Heap Profiling
In-Reply-To: <cfb1b563-2702-a0b8-b122-da0e46b3b26f@redhat.com>
References: <20180329171223.64A4C1973B3@eggemoggin.niobe.net>
<cfb1b563-2702-a0b8-b122-da0e46b3b26f@redhat.com>
Message-ID: <CAF9BGBz_167RNNsHVEzs1Q-eiyih5mzB3BrTt0_Vu67SQUuwVg@mail.gmail.com>
On Wed, Apr 4, 2018 at 3:41 AM Aleksey Shipilev <shade at redhat.com> wrote:
> On 03/29/2018 07:12 PM, mark.reinhold at oracle.com wrote:
> > New JEP Candidate: http://openjdk.java.net/jeps/331
>
> Interesting JEP!
>
> *) It would be nice to mention the implementation details in the JEP
> itself, i.e. where are the
> points it injects into GCs to sample? I assume it has to inject into
> CollectedHeap::allocate_tlab,
> and it has to cap the max TLAB sizes to get into allocation slowpath often
> enough?
>
My understanding was that a JEP was the idea and specification and that
more technical information like that was out of scope for the JEP
(implementations can change, etc.)
It actually does not cap the max TLAB sizes, it changes the end pointer to
force paths into "thinking" the tlab is full; then in the slowpath it
samples and fixes things the pointers up for the next sample.
>
> *) Since JC apparently has the prototype, it would be easier to put it
> somewhere, and link it into
> the JEP itself. Webrevs are interesting, but they get outdated pretty
> quickly, so maybe putting the
> whole thing in JDK Sandbox [1] is the way to go.
>
I've been keeping the webrevs up to date so there should be no real
problem. From what I read, you have to be a commiter for the JDK Sandbox,
no? So I'm not sure that would make sense there?
>
> Otherwise it leads to speculation, which raises the questions like below:
>
> *) Motivation says: "The downsides [of JFR] are that a) it is tied to a
> particular allocation
> implementation (TLABs), and misses allocations that don?t meet that
> pattern; b) it doesn?t allow the
> user to customize the sampling rate; c) it only logs allocations, so you
> cannot distinguish between
> live and dead objects."
>
> ...but then JEP apparently describes sampling the allocations via TLABs?
> So, the real difference is
> (b), allowing to customize the sampling rate, or do I miss something?
>
There are various differences between the JFR tlab events and this system.
First the JFR system provides a buffer event system, meaning you can miss
samples if the event buffer is full and threw out a sampling event before a
reader got to it. Second, you don't get a callback at the allocation spot,
so you cannot have a means to do an action at that sampling point, which
means you have no way of knowing when an object is effectively dead using
the JFR events. Hopefully that makes sense?
>
> *) Goals say: "Can give information about both live and dead Java objects."
>
> ...but there is not discussion what/how does it give information about
> the dead Java objects. I am
> struggling to imagine how allocation sampling would give this. Is the goal
> too broad, or some API is
> not described in the JEP?
>
Originally the JEP provided a means to the user to get that information
directly. Now because the sampling callback provides an oop, the user in
the agent can add a weak reference and use that to determine liveness.
Thanks,
Jc
From david.holmes at oracle.com Wed Apr 4 23:42:50 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Apr 2018 09:42:50 +1000
Subject: RFR: 8200697: Add utility for spin wait with fallback to
yield/sleep
In-Reply-To: <E1CA91CD-9CF6-44D5-A7B7-0747AA648D65@oracle.com>
References: <E1CA91CD-9CF6-44D5-A7B7-0747AA648D65@oracle.com>
Message-ID: <c0758ba9-a647-f6e4-2b21-b47f3fc15a42@oracle.com>
Hi Kim,
If this works you for then by all means use it.
Whether it is useful as a general utility is something I am doubtful of.
Degrading spin-loops are put in for performance reasons and generally
have to interact with surrounding code that captures exactly what is
being waited upon. There is also the issue of thread-state transitions
that need to be carefully managed.
Cheers,
David
On 5/04/2018 4:53 AM, Kim Barrett wrote:
> Please review this addition of SpinYield utility class.
>
> It initially supplies a very simple policy: spin a configured number
> of times, then switch to yielding or (eventually) sleeping. Other
> policies may replace this one or be provided as alternatives in the
> future.
>
> This is joint work with Robbin Ehn.
>
> Robbin and I have immediate uses for this utility in changes we are
> developing. In addition, there are some existing places that might be
> converted to use this utility (or perhaps some extended version of
> it), including SafepointSynchronize::begin, ReadStableMark,
> Thread::SpinAcquire, and ParallelTaskTerminator::offer_termination.
> Those existing potential uses are not being changed here; for now,
> we're just adding the utility in support of our in-development
> changes. We plan to file followup RFEs to consider converting those
> potential uses.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8200697
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8200697/open.00/
>
> Testing:
> Added unit test of basic functionality.
> Build and hs-tier1 (for gtest) on all Oracle platforms.
>
From Sergey.Bylokhov at oracle.com Thu Apr 5 00:33:54 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 4 Apr 2018 17:33:54 -0700
Subject: RFR: JDK-8196724: Change macosx deployment target to 10.9
In-Reply-To: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com>
References: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com>
Message-ID: <5fa6cb00-7070-cd2a-c5d9-ad256b17c5f9@oracle.com>
Looks fine.
On 04/04/2018 11:30, Erik Joelsson wrote:
> This patch changes the values for the macosx version min and max
> settings from 10.7 to 10.9. It also changes the stdlib from libstdc++ to
> libc++ (explicitly for Hotspot and implicitly everywhere else). This
> change is necessary to keep up with newer toolchain versions on Macosx
> where using the old and no longer maintained libstdc++ has been
> deprecated. This is done in preparation for bumping the preferred Xcode
> version used for builds at Oracle.
>
> The switch has been tested for both Hotspot and client.
>
> The switch triggered some new deprecation warnings which have been
> silenced and followup bugs have been filed on the concerned team.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196724
>
> Webrev: http://cr.openjdk.java.net/~erikj/8196724/webrev.01/index.html
>
> /Erik
>
--
Best regards, Sergey.
From felix.yang at linaro.org Thu Apr 5 01:33:50 2018
From: felix.yang at linaro.org (Felix Yang)
Date: Thu, 5 Apr 2018 09:33:50 +0800
Subject: RFR: 8200524 - AArch64: CPUFeature and Flag enums are not passed
through JVMCI
In-Reply-To: <17dc271bed3d4cb1b2c816680aeabbaa@NASANEXM01E.na.qualcomm.com>
References: <98b24cb083e34d6fa465a17bc9b81acd@NASANEXM01E.na.qualcomm.com>
<7dc80da1-3a55-717c-eb90-676d191c8c08@oracle.com>
<09892b14336d47469db1554c69db9aa8@NASANEXM01E.na.qualcomm.com>
<17dc271bed3d4cb1b2c816680aeabbaa@NASANEXM01E.na.qualcomm.com>
Message-ID: <CACc5Y6Tx8-UAVhrziJPbB83U=zBDs=d5A1rESdMCxCeJh3xa7A@mail.gmail.com>
That looks good to me (not an official reviewer).
There are some trailing spaces in your original patch, I have modified and
pushed: http://hg.openjdk.java.net/jdk/hs/rev/46b2f783116c
Make sure you have jcheck enabled next time. Reference:
http://openjdk.java.net/projects/code-tools/jcheck/
Thanks,
Felix
On 31 March 2018 at 01:48, stewartd.qdt <stewartd.qdt at qualcommdatacenter.com
> wrote:
> Might I get a sponsor for this change?
>
> http://cr.openjdk.java.net/~dstewart/8200524/webrev.01/
>
> Thank you,
> Daniel
>
> -----Original Message-----
> From: stewartd.qdt
> Sent: Friday, March 30, 2018 12:12 PM
> To: Vladimir Kozlov <vladimir.kozlov at oracle.com>; stewartd.qdt <
> stewartd.qdt at qualcommdatacenter.com>; hotspot-dev at openjdk.java.net
> Subject: RE: RFR: 8200524 - AArch64: CPUFeature and Flag enums are not
> passed through JVMCI
>
> Thanks, Vladimir.
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Friday, March 30, 2018 12:10 PM
> To: stewartd.qdt <stewartd.qdt at qualcommdatacenter.com>;
> hotspot-dev at openjdk.java.net
> Subject: Re: RFR: 8200524 - AArch64: CPUFeature and Flag enums are not
> passed through JVMCI
>
> Changes looks good to me. They follow the same code pattern as on other
> architectures.
>
> Thanks,
> Vladimir
>
> On 3/30/18 8:35 AM, stewartd.qdt wrote:
> > Please review this webrev [1] which implements the transfer of
> AArch64::CPUFeature flags and AArch64::Flag enums over the JVMCI interface.
> >
> > This patch sets the CPUFeature enums corresponding to which VM_Version
> flags are set. It also sets the Flag enums corresponding to which use flags
> have been set on the command line. This mirrors what is done for AMD64.
> >
> > The bug report is filed at [2].
> >
> > I am happy to modify the patch as necessary.
> >
> > Regards,
> > Daniel Stewart
> >
> > [1] - http://cr.openjdk.java.net/~dstewart/8200524/webrev.00/
> > [2] - https://bugs.openjdk.java.net/browse/JDK-8200524
> >
>
From david.holmes at oracle.com Thu Apr 5 02:23:14 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Apr 2018 12:23:14 +1000
Subject: Execution problems with Atomic Operations on OpenJDK10 for ARM5
Soft Float
In-Reply-To: <5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
<15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
<5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
Message-ID: <1409b536-0cb6-aeda-630a-9a66c0d4abe4@oracle.com>
On 5/04/2018 11:26 AM, bren at juanantonio.info wrote:
> Good night David,
>
> It is the first time that I report a Bug on OpenJDK and I didn?t receive
> any notification so I didn?t know the status of the Issue that I reported.
Sorry about that. You should have received some form of notification.
> Many thanks with the link about the Platforms supported:
> http://www.oracle.com/technetwork/java/javase/documentation/jdk10certconfig-4417031.html
>
>
> We will try to do Compilation with the solution.
>
> --- a/src/hotspot/cpu/arm/vm_version_arm_32.cpp
> +++ b/src/hotspot/cpu/arm/vm_version_arm_32.cpp
> @@ -298,6 +298,15 @@
> ???? FLAG_SET_DEFAULT(UseUnalignedAccesses, false);
> ?? }
>
> + if (arm_arch() == 5) {
> + if (FLAG_IS_DEFAULT(AssumeMP)) {
> + FLAG_SET_DEFAULT(AssumeMP, false);
> + else if (AssumeMP) {
> + warning("AssumeMP can not be true for ARMv5 as there is only
> uniprocessor support");
> + FLAG_SET_DEFAULT(AssumeMP, false);
> + }
> + }
> +
> ?? _is_initialized = true;
> ?}
>
> Runtime workaround: java -XX:-AssumeMP
>
> In our case, I would like to continue maintaining this support for the
> Device.
> What is the advice that you could give us?
You would have to keep the local copy of your source code patched and
produce your own builds. But if you also try to update with the mainline
OpenJDK code then you will very soon hit problems. In fact I'd be very
surprised if this works today, even if it builds, as we have not
provided any updates to ARM32 in a long time. The only supported way to
run on ARM32 is using the Zero interpreter as Adrian replied.
> What is AssumeMP?
Assume Multi-Processor.
When running on a MP system the VM has to use and generate code that
provides the correct level of atomicity and memory consistency - none of
which is necessary on a uniprocessor system. MP systems are the norm and
in the rare case we issue the additional memory synchronization
instructions they should be no-ops on a uniprocessor, so we are heading
towards stripping out uniprocessor support and only build in MP support
so that we don't need dynamic checks through the code to see if we are
MP or not. Switching AssumeMP to true was the first step in that process
(and avoided problems where the VM may be started with only one
processor available but then had additional ones added later.)
In any case there has never been any support for ARMv5 multiprocessors.
Cheers,
David
> For education, this device is pretty interesting for the whole Java
> community, this is the reason.
> I will inform with the results.
>
> Many thanks in advance.
>
> Cheers
>
> Juan Antonio
>
> El 2018-04-05 00:12, David Holmes escribi?:
>> Hi,
>>
>> This was already reported as:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8200580
>>
>> to which I have responded and closed the bug as this is not a
>> supported platform.
>>
>> As per the bug report this may be due to the change to AssumeMP to be
>> true, but there is no MP support for ARMv5.
>>
>> David
>>
>> On 4/04/2018 8:29 PM, bren at juanantonio.info wrote:
>>> Good morning,
>>>
>>> Mi name is Juan Antonio Bre?a Moral, I am developing a set of Java
>>> libraries for Lego Mindstorms EV3, an ARM5 robotics device and
>>> recently, we build OpenJDK 9 with success but with OpenJDK 10, we
>>> have found some problems when we execute some Java programs.
>>>
>>> Repository to build OpenJDK 9/10 for ARM5 Soft Float:
>>> https://github.com/ev3dev-lang-java/openjdk-ev3
>>>
>>> To test the JVM, I am using the following repo to test the VM:
>>> https://github.com/ev3dev-lang-java/vmbenchmarks
>>>
>>> And this is the output with the error:
>>>
>>> robot at ev3dev:~$ java -jar benchmarks.jar -f 1
>>> WARNING: An illegal reflective access operation has occurred
>>> WARNING: Illegal reflective access by org.openjdk.jmh.util.Utils
>>> (file:/home/robot/benchmarks.jar) to field java.io.Console.cs
>>> WARNING: Please consider reporting this to the maintainers of
>>> org.openjdk.jmh.util.Utils
>>> WARNING: Use --illegal-access=warn to enable warnings of further
>>> illegal reflective access operations
>>> WARNING: All illegal access operations will be denied in a future
>>> release
>>> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on this
>>> platform ================
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>> this platform ================
>>>
>>>
>>> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on this
>>> platform ================
>>>
>>> [thread 4430 also had an error]
>>> [error occurred during error reporting ((null)), id 0xe0000000]
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>> this platform ================
>>>
>>>
>>> [error occurred during error reporting (printing fatal error
>>> message), id 0xe0000000]
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>> this platform ================
>>>
>>>
>>> [error occurred during error reporting (printing type of error), id
>>> 0xe0000000]
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>> this platform ================
>>>
>>>
>>> [error occurred during error reporting (printing stack bounds), id
>>> 0xe0000000]
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>> this platform ================
>>>
>>>
>>> [error occurred during error reporting (printing native stack), id
>>> 0xe0000000]
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>> this platform ================
>>>
>>>
>>> [error occurred during error reporting (printing Java stack), id
>>> 0xe0000000]
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>> this platform ================
>>>
>>>
>>> [error occurred during error reporting (printing target Java thread
>>> stack), id 0xe0000000]
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>> this platform ================
>>>
>>>
>>> [error occurred during error reporting (printing siginfo), id
>>> 0xe0000000]
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>> this platform ================
>>>
>>>
>>> [error occurred during error reporting (CDS archive access warning),
>>> id 0xe0000000]
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>> this platform ================
>>>
>>>
>>> [error occurred during error reporting (printing register info), id
>>> 0xe0000000]
>>>
>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>> this platform ================
>>>
>>>
>>> [Too many errors, abort]
>>> Aborted
>>>
>>> I think that in OpenJDK10 changed something in compare to OpenJDK9 in
>>> relation to ARM5 support.
>>>
>>> Any idea?
>>>
>>> Many thanks in advance.
>>>
>>> Cheers
>>>
>>> Juan Antonio
>>>
From david.holmes at oracle.com Thu Apr 5 03:39:19 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Apr 2018 13:39:19 +1000
Subject: Execution problems with Atomic Operations on OpenJDK10 for ARM5
Soft Float
In-Reply-To: <4d8e64dffe182a1a9ef7afa94c380322@juanantonio.info>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
<15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
<5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
<1409b536-0cb6-aeda-630a-9a66c0d4abe4@oracle.com>
<4d8e64dffe182a1a9ef7afa94c380322@juanantonio.info>
Message-ID: <6d3224d7-edcb-56a9-81f0-04317277d367@oracle.com>
On 5/04/2018 1:30 PM, bren at juanantonio.info wrote:
> Hi David,
>
> Many thanks for the comments.
>
> In relation to the ARMV5 support, in the past Oracle released a version
> for Mindstorms:
> http://www.oracle.com/technetwork/java/embedded/downloads/javase/javaseemeddedev3-1982511.html
>
>
> but if you observe that release was Java 8.
Yes we started scaling back Java SE Embedded after 8 GA. Later 8u
versions do not support the same set of platforms. Java SE Embedded does
not exist in 9+
David
-----
> For Java 9, we could build JDK and JRI (Java Runtime Images)
> https://github.com/ev3dev-lang-java/openjdk-ev3/releases/tag/v0.4.5
>
> I wish with your local path suggestion, we could build OpenJDK 10.
> Later, we will try with OpenJDK11.
>
> I have to see how to automate the whole process on Travis CI.
>
> Cheers
>
> Juan Antonio
>
> El 2018-04-05 04:23, David Holmes escribi?:
>> On 5/04/2018 11:26 AM, bren at juanantonio.info wrote:
>>> Good night David,
>>>
>>> It is the first time that I report a Bug on OpenJDK and I didn?t
>>> receive any notification so I didn?t know the status of the Issue
>>> that I reported.
>>
>> Sorry about that. You should have received some form of notification.
>>
>>> Many thanks with the link about the Platforms supported:
>>> http://www.oracle.com/technetwork/java/javase/documentation/jdk10certconfig-4417031.html
>>> We will try to do Compilation with the solution.
>>>
>>> --- a/src/hotspot/cpu/arm/vm_version_arm_32.cpp
>>> +++ b/src/hotspot/cpu/arm/vm_version_arm_32.cpp
>>> @@ -298,6 +298,15 @@
>>> ????? FLAG_SET_DEFAULT(UseUnalignedAccesses, false);
>>> ??? }
>>>
>>> + if (arm_arch() == 5) {
>>> + if (FLAG_IS_DEFAULT(AssumeMP)) {
>>> + FLAG_SET_DEFAULT(AssumeMP, false);
>>> + else if (AssumeMP) {
>>> + warning("AssumeMP can not be true for ARMv5 as there is only
>>> uniprocessor support");
>>> + FLAG_SET_DEFAULT(AssumeMP, false);
>>> + }
>>> + }
>>> +
>>> ??? _is_initialized = true;
>>> ??}
>>>
>>> Runtime workaround: java -XX:-AssumeMP
>>>
>>> In our case, I would like to continue maintaining this support for
>>> the Device.
>>> What is the advice that you could give us?
>>
>> You would have to keep the local copy of your source code patched and
>> produce your own builds. But if you also try to update with the
>> mainline OpenJDK code then you will very soon hit problems. In fact
>> I'd be very surprised if this works today, even if it builds, as we
>> have not provided any updates to ARM32 in a long time. The only
>> supported way to run on ARM32 is using the Zero interpreter as Adrian
>> replied.
>>
>>> What is AssumeMP?
>>
>> Assume Multi-Processor.
>>
>> When running on a MP system the VM has to use and generate code that
>> provides the correct level of atomicity and memory consistency - none
>> of which is necessary on a uniprocessor system. MP systems are the
>> norm and in the rare case we issue the additional memory
>> synchronization instructions they should be no-ops on a uniprocessor,
>> so we are heading towards stripping out uniprocessor support and only
>> build in MP support so that we don't need dynamic checks through the
>> code to see if we are MP or not. Switching AssumeMP to true was the
>> first step in that process (and avoided problems where the VM may be
>> started with only one processor available but then had additional ones
>> added later.)
>>
>> In any case there has never been any support for ARMv5 multiprocessors.
>>
>> Cheers,
>> David
>>
>>> For education, this device is pretty interesting for the whole Java
>>> community, this is the reason.
>>
>>
>>> I will inform with the results.
>>>
>>> Many thanks in advance.
>>>
>>> Cheers
>>>
>>> Juan Antonio
>>>
>>> El 2018-04-05 00:12, David Holmes escribi?:
>>>> Hi,
>>>>
>>>> This was already reported as:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8200580
>>>>
>>>> to which I have responded and closed the bug as this is not a
>>>> supported platform.
>>>>
>>>> As per the bug report this may be due to the change to AssumeMP to be
>>>> true, but there is no MP support for ARMv5.
>>>>
>>>> David
>>>>
>>>> On 4/04/2018 8:29 PM, bren at juanantonio.info wrote:
>>>>> Good morning,
>>>>>
>>>>> Mi name is Juan Antonio Bre?a Moral, I am developing a set of Java
>>>>> libraries for Lego Mindstorms EV3, an ARM5 robotics device and
>>>>> recently, we build OpenJDK 9 with success but with OpenJDK 10, we
>>>>> have found some problems when we execute some Java programs.
>>>>>
>>>>> Repository to build OpenJDK 9/10 for ARM5 Soft Float:
>>>>> https://github.com/ev3dev-lang-java/openjdk-ev3
>>>>>
>>>>> To test the JVM, I am using the following repo to test the VM:
>>>>> https://github.com/ev3dev-lang-java/vmbenchmarks
>>>>>
>>>>> And this is the output with the error:
>>>>>
>>>>> robot at ev3dev:~$ java -jar benchmarks.jar -f 1
>>>>> WARNING: An illegal reflective access operation has occurred
>>>>> WARNING: Illegal reflective access by org.openjdk.jmh.util.Utils
>>>>> (file:/home/robot/benchmarks.jar) to field java.io.Console.cs
>>>>> WARNING: Please consider reporting this to the maintainers of
>>>>> org.openjdk.jmh.util.Utils
>>>>> WARNING: Use --illegal-access=warn to enable warnings of further
>>>>> illegal reflective access operations
>>>>> WARNING: All illegal access operations will be denied in a future
>>>>> release
>>>>> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on
>>>>> this platform ================
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>>> this platform ================
>>>>>
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on
>>>>> this platform ================
>>>>>
>>>>> [thread 4430 also had an error]
>>>>> [error occurred during error reporting ((null)), id 0xe0000000]
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>>> this platform ================
>>>>>
>>>>>
>>>>> [error occurred during error reporting (printing fatal error
>>>>> message), id 0xe0000000]
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>>> this platform ================
>>>>>
>>>>>
>>>>> [error occurred during error reporting (printing type of error), id
>>>>> 0xe0000000]
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>>> this platform ================
>>>>>
>>>>>
>>>>> [error occurred during error reporting (printing stack bounds), id
>>>>> 0xe0000000]
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>>> this platform ================
>>>>>
>>>>>
>>>>> [error occurred during error reporting (printing native stack), id
>>>>> 0xe0000000]
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>>> this platform ================
>>>>>
>>>>>
>>>>> [error occurred during error reporting (printing Java stack), id
>>>>> 0xe0000000]
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>>> this platform ================
>>>>>
>>>>>
>>>>> [error occurred during error reporting (printing target Java thread
>>>>> stack), id 0xe0000000]
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>>> this platform ================
>>>>>
>>>>>
>>>>> [error occurred during error reporting (printing siginfo), id
>>>>> 0xe0000000]
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>>> this platform ================
>>>>>
>>>>>
>>>>> [error occurred during error reporting (CDS archive access
>>>>> warning), id 0xe0000000]
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>>> this platform ================
>>>>>
>>>>>
>>>>> [error occurred during error reporting (printing register info), id
>>>>> 0xe0000000]
>>>>>
>>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>>> this platform ================
>>>>>
>>>>>
>>>>> [Too many errors, abort]
>>>>> Aborted
>>>>>
>>>>> I think that in OpenJDK10 changed something in compare to OpenJDK9
>>>>> in relation to ARM5 support.
>>>>>
>>>>> Any idea?
>>>>>
>>>>> Many thanks in advance.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Juan Antonio
>>>>>
From bren at juanantonio.info Thu Apr 5 01:26:10 2018
From: bren at juanantonio.info (bren at juanantonio.info)
Date: Thu, 05 Apr 2018 03:26:10 +0200
Subject: Execution problems with Atomic Operations on OpenJDK10 for ARM5
Soft Float
In-Reply-To: <15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
<15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
Message-ID: <5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
Good night David,
It is the first time that I report a Bug on OpenJDK and I didn?t receive
any notification so I didn?t know the status of the Issue that I
reported.
Many thanks with the link about the Platforms supported:
http://www.oracle.com/technetwork/java/javase/documentation/jdk10certconfig-4417031.html
We will try to do Compilation with the solution.
--- a/src/hotspot/cpu/arm/vm_version_arm_32.cpp
+++ b/src/hotspot/cpu/arm/vm_version_arm_32.cpp
@@ -298,6 +298,15 @@
FLAG_SET_DEFAULT(UseUnalignedAccesses, false);
}
+ if (arm_arch() == 5) {
+ if (FLAG_IS_DEFAULT(AssumeMP)) {
+ FLAG_SET_DEFAULT(AssumeMP, false);
+ else if (AssumeMP) {
+ warning("AssumeMP can not be true for ARMv5 as there is only
uniprocessor support");
+ FLAG_SET_DEFAULT(AssumeMP, false);
+ }
+ }
+
_is_initialized = true;
}
Runtime workaround: java -XX:-AssumeMP
In our case, I would like to continue maintaining this support for the
Device.
What is the advice that you could give us?
What is AssumeMP?
For education, this device is pretty interesting for the whole Java
community, this is the reason.
I will inform with the results.
Many thanks in advance.
Cheers
Juan Antonio
El 2018-04-05 00:12, David Holmes escribi?:
> Hi,
>
> This was already reported as:
>
> https://bugs.openjdk.java.net/browse/JDK-8200580
>
> to which I have responded and closed the bug as this is not a
> supported platform.
>
> As per the bug report this may be due to the change to AssumeMP to be
> true, but there is no MP support for ARMv5.
>
> David
>
> On 4/04/2018 8:29 PM, bren at juanantonio.info wrote:
>> Good morning,
>>
>> Mi name is Juan Antonio Bre?a Moral, I am developing a set of Java
>> libraries for Lego Mindstorms EV3, an ARM5 robotics device and
>> recently, we build OpenJDK 9 with success but with OpenJDK 10, we have
>> found some problems when we execute some Java programs.
>>
>> Repository to build OpenJDK 9/10 for ARM5 Soft Float:
>> https://github.com/ev3dev-lang-java/openjdk-ev3
>>
>> To test the JVM, I am using the following repo to test the VM:
>> https://github.com/ev3dev-lang-java/vmbenchmarks
>>
>> And this is the output with the error:
>>
>> robot at ev3dev:~$ java -jar benchmarks.jar -f 1
>> WARNING: An illegal reflective access operation has occurred
>> WARNING: Illegal reflective access by org.openjdk.jmh.util.Utils
>> (file:/home/robot/benchmarks.jar) to field java.io.Console.cs
>> WARNING: Please consider reporting this to the maintainers of
>> org.openjdk.jmh.util.Utils
>> WARNING: Use --illegal-access=warn to enable warnings of further
>> illegal reflective access operations
>> WARNING: All illegal access operations will be denied in a future
>> release
>> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on this
>> platform ================
>>
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
>> platform ================
>>
>>
>> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on this
>> platform ================
>>
>> [thread 4430 also had an error]
>> [error occurred during error reporting ((null)), id 0xe0000000]
>>
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
>> platform ================
>>
>>
>> [error occurred during error reporting (printing fatal error message),
>> id 0xe0000000]
>>
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
>> platform ================
>>
>>
>> [error occurred during error reporting (printing type of error), id
>> 0xe0000000]
>>
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
>> platform ================
>>
>>
>> [error occurred during error reporting (printing stack bounds), id
>> 0xe0000000]
>>
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
>> platform ================
>>
>>
>> [error occurred during error reporting (printing native stack), id
>> 0xe0000000]
>>
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
>> platform ================
>>
>>
>> [error occurred during error reporting (printing Java stack), id
>> 0xe0000000]
>>
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
>> platform ================
>>
>>
>> [error occurred during error reporting (printing target Java thread
>> stack), id 0xe0000000]
>>
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
>> platform ================
>>
>>
>> [error occurred during error reporting (printing siginfo), id
>> 0xe0000000]
>>
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
>> platform ================
>>
>>
>> [error occurred during error reporting (CDS archive access warning),
>> id 0xe0000000]
>>
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
>> platform ================
>>
>>
>> [error occurred during error reporting (printing register info), id
>> 0xe0000000]
>>
>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on this
>> platform ================
>>
>>
>> [Too many errors, abort]
>> Aborted
>>
>> I think that in OpenJDK10 changed something in compare to OpenJDK9 in
>> relation to ARM5 support.
>>
>> Any idea?
>>
>> Many thanks in advance.
>>
>> Cheers
>>
>> Juan Antonio
>>
From bren at juanantonio.info Thu Apr 5 03:30:57 2018
From: bren at juanantonio.info (bren at juanantonio.info)
Date: Thu, 05 Apr 2018 05:30:57 +0200
Subject: Execution problems with Atomic Operations on OpenJDK10 for ARM5
Soft Float
In-Reply-To: <1409b536-0cb6-aeda-630a-9a66c0d4abe4@oracle.com>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
<15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
<5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
<1409b536-0cb6-aeda-630a-9a66c0d4abe4@oracle.com>
Message-ID: <4d8e64dffe182a1a9ef7afa94c380322@juanantonio.info>
Hi David,
Many thanks for the comments.
In relation to the ARMV5 support, in the past Oracle released a version
for Mindstorms:
http://www.oracle.com/technetwork/java/embedded/downloads/javase/javaseemeddedev3-1982511.html
but if you observe that release was Java 8.
For Java 9, we could build JDK and JRI (Java Runtime Images)
https://github.com/ev3dev-lang-java/openjdk-ev3/releases/tag/v0.4.5
I wish with your local path suggestion, we could build OpenJDK 10.
Later, we will try with OpenJDK11.
I have to see how to automate the whole process on Travis CI.
Cheers
Juan Antonio
El 2018-04-05 04:23, David Holmes escribi?:
> On 5/04/2018 11:26 AM, bren at juanantonio.info wrote:
>> Good night David,
>>
>> It is the first time that I report a Bug on OpenJDK and I didn?t
>> receive any notification so I didn?t know the status of the Issue that
>> I reported.
>
> Sorry about that. You should have received some form of notification.
>
>> Many thanks with the link about the Platforms supported:
>> http://www.oracle.com/technetwork/java/javase/documentation/jdk10certconfig-4417031.html
>> We will try to do Compilation with the solution.
>>
>> --- a/src/hotspot/cpu/arm/vm_version_arm_32.cpp
>> +++ b/src/hotspot/cpu/arm/vm_version_arm_32.cpp
>> @@ -298,6 +298,15 @@
>> ???? FLAG_SET_DEFAULT(UseUnalignedAccesses, false);
>> ?? }
>>
>> + if (arm_arch() == 5) {
>> + if (FLAG_IS_DEFAULT(AssumeMP)) {
>> + FLAG_SET_DEFAULT(AssumeMP, false);
>> + else if (AssumeMP) {
>> + warning("AssumeMP can not be true for ARMv5 as there is only
>> uniprocessor support");
>> + FLAG_SET_DEFAULT(AssumeMP, false);
>> + }
>> + }
>> +
>> ?? _is_initialized = true;
>> ?}
>>
>> Runtime workaround: java -XX:-AssumeMP
>>
>> In our case, I would like to continue maintaining this support for the
>> Device.
>> What is the advice that you could give us?
>
> You would have to keep the local copy of your source code patched and
> produce your own builds. But if you also try to update with the
> mainline OpenJDK code then you will very soon hit problems. In fact
> I'd be very surprised if this works today, even if it builds, as we
> have not provided any updates to ARM32 in a long time. The only
> supported way to run on ARM32 is using the Zero interpreter as Adrian
> replied.
>
>> What is AssumeMP?
>
> Assume Multi-Processor.
>
> When running on a MP system the VM has to use and generate code that
> provides the correct level of atomicity and memory consistency - none
> of which is necessary on a uniprocessor system. MP systems are the
> norm and in the rare case we issue the additional memory
> synchronization instructions they should be no-ops on a uniprocessor,
> so we are heading towards stripping out uniprocessor support and only
> build in MP support so that we don't need dynamic checks through the
> code to see if we are MP or not. Switching AssumeMP to true was the
> first step in that process (and avoided problems where the VM may be
> started with only one processor available but then had additional ones
> added later.)
>
> In any case there has never been any support for ARMv5 multiprocessors.
>
> Cheers,
> David
>
>> For education, this device is pretty interesting for the whole Java
>> community, this is the reason.
>
>
>> I will inform with the results.
>>
>> Many thanks in advance.
>>
>> Cheers
>>
>> Juan Antonio
>>
>> El 2018-04-05 00:12, David Holmes escribi?:
>>> Hi,
>>>
>>> This was already reported as:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8200580
>>>
>>> to which I have responded and closed the bug as this is not a
>>> supported platform.
>>>
>>> As per the bug report this may be due to the change to AssumeMP to be
>>> true, but there is no MP support for ARMv5.
>>>
>>> David
>>>
>>> On 4/04/2018 8:29 PM, bren at juanantonio.info wrote:
>>>> Good morning,
>>>>
>>>> Mi name is Juan Antonio Bre?a Moral, I am developing a set of Java
>>>> libraries for Lego Mindstorms EV3, an ARM5 robotics device and
>>>> recently, we build OpenJDK 9 with success but with OpenJDK 10, we
>>>> have found some problems when we execute some Java programs.
>>>>
>>>> Repository to build OpenJDK 9/10 for ARM5 Soft Float:
>>>> https://github.com/ev3dev-lang-java/openjdk-ev3
>>>>
>>>> To test the JVM, I am using the following repo to test the VM:
>>>> https://github.com/ev3dev-lang-java/vmbenchmarks
>>>>
>>>> And this is the output with the error:
>>>>
>>>> robot at ev3dev:~$ java -jar benchmarks.jar -f 1
>>>> WARNING: An illegal reflective access operation has occurred
>>>> WARNING: Illegal reflective access by org.openjdk.jmh.util.Utils
>>>> (file:/home/robot/benchmarks.jar) to field java.io.Console.cs
>>>> WARNING: Please consider reporting this to the maintainers of
>>>> org.openjdk.jmh.util.Utils
>>>> WARNING: Use --illegal-access=warn to enable warnings of further
>>>> illegal reflective access operations
>>>> WARNING: All illegal access operations will be denied in a future
>>>> release
>>>> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on
>>>> this platform ================
>>>>
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>> this platform ================
>>>>
>>>>
>>>> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on
>>>> this platform ================
>>>>
>>>> [thread 4430 also had an error]
>>>> [error occurred during error reporting ((null)), id 0xe0000000]
>>>>
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>> this platform ================
>>>>
>>>>
>>>> [error occurred during error reporting (printing fatal error
>>>> message), id 0xe0000000]
>>>>
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>> this platform ================
>>>>
>>>>
>>>> [error occurred during error reporting (printing type of error), id
>>>> 0xe0000000]
>>>>
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>> this platform ================
>>>>
>>>>
>>>> [error occurred during error reporting (printing stack bounds), id
>>>> 0xe0000000]
>>>>
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>> this platform ================
>>>>
>>>>
>>>> [error occurred during error reporting (printing native stack), id
>>>> 0xe0000000]
>>>>
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>> this platform ================
>>>>
>>>>
>>>> [error occurred during error reporting (printing Java stack), id
>>>> 0xe0000000]
>>>>
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>> this platform ================
>>>>
>>>>
>>>> [error occurred during error reporting (printing target Java thread
>>>> stack), id 0xe0000000]
>>>>
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>> this platform ================
>>>>
>>>>
>>>> [error occurred during error reporting (printing siginfo), id
>>>> 0xe0000000]
>>>>
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>> this platform ================
>>>>
>>>>
>>>> [error occurred during error reporting (CDS archive access warning),
>>>> id 0xe0000000]
>>>>
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>> this platform ================
>>>>
>>>>
>>>> [error occurred during error reporting (printing register info), id
>>>> 0xe0000000]
>>>>
>>>> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported on
>>>> this platform ================
>>>>
>>>>
>>>> [Too many errors, abort]
>>>> Aborted
>>>>
>>>> I think that in OpenJDK10 changed something in compare to OpenJDK9
>>>> in relation to ARM5 support.
>>>>
>>>> Any idea?
>>>>
>>>> Many thanks in advance.
>>>>
>>>> Cheers
>>>>
>>>> Juan Antonio
>>>>
From fairoz.matte at oracle.com Thu Apr 5 05:25:26 2018
From: fairoz.matte at oracle.com (Fairoz Matte)
Date: Wed, 4 Apr 2018 22:25:26 -0700 (PDT)
Subject: Execution problems with Atomic Operations on OpenJDK10 for ARM5
Soft Float
In-Reply-To: <5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
<15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
<5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
Message-ID: <74fb02a1-e526-4ca6-b581-9f6a2ca05602@default>
Hi Juan Antonio,
> -----Original Message-----
> From: bren at juanantonio.info [mailto:bren at juanantonio.info]
>
> Good night David,
>
> It is the first time that I report a Bug on OpenJDK and I didn?t receive any
> notification so I didn?t know the status of the Issue that I reported.
Yes, there was some issue in the notification server, no emails sent to bug submitters. Generally you will receive e-mail, once issue is created in JDK.
Sorry about this.
Thanks David for pointing out the JDK issue.
Thanks,
Fairoz
>
> Many thanks with the link about the Platforms supported:
> http://www.oracle.com/technetwork/java/javase/documentation/jdk10cert
> config-4417031.html
>
> We will try to do Compilation with the solution.
>
> --- a/src/hotspot/cpu/arm/vm_version_arm_32.cpp
> +++ b/src/hotspot/cpu/arm/vm_version_arm_32.cpp
> @@ -298,6 +298,15 @@
> FLAG_SET_DEFAULT(UseUnalignedAccesses, false);
> }
>
> + if (arm_arch() == 5) {
> + if (FLAG_IS_DEFAULT(AssumeMP)) {
> + FLAG_SET_DEFAULT(AssumeMP, false);
> + else if (AssumeMP) {
> + warning("AssumeMP can not be true for ARMv5 as there is only
> uniprocessor support");
> + FLAG_SET_DEFAULT(AssumeMP, false);
> + }
> + }
> +
> _is_initialized = true;
> }
>
> Runtime workaround: java -XX:-AssumeMP
>
> In our case, I would like to continue maintaining this support for the Device.
> What is the advice that you could give us?
> What is AssumeMP?
>
> For education, this device is pretty interesting for the whole Java community,
> this is the reason.
>
> I will inform with the results.
>
> Many thanks in advance.
>
> Cheers
>
> Juan Antonio
>
> El 2018-04-05 00:12, David Holmes escribi?:
> > Hi,
> >
> > This was already reported as:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8200580
> >
> > to which I have responded and closed the bug as this is not a
> > supported platform.
> >
> > As per the bug report this may be due to the change to AssumeMP to be
> > true, but there is no MP support for ARMv5.
> >
> > David
> >
> > On 4/04/2018 8:29 PM, bren at juanantonio.info wrote:
> >> Good morning,
> >>
> >> Mi name is Juan Antonio Bre?a Moral, I am developing a set of Java
> >> libraries for Lego Mindstorms EV3, an ARM5 robotics device and
> >> recently, we build OpenJDK 9 with success but with OpenJDK 10, we
> >> have found some problems when we execute some Java programs.
> >>
> >> Repository to build OpenJDK 9/10 for ARM5 Soft Float:
> >> https://github.com/ev3dev-lang-java/openjdk-ev3
> >>
> >> To test the JVM, I am using the following repo to test the VM:
> >> https://github.com/ev3dev-lang-java/vmbenchmarks
> >>
> >> And this is the output with the error:
> >>
> >> robot at ev3dev:~$ java -jar benchmarks.jar -f 1
> >> WARNING: An illegal reflective access operation has occurred
> >> WARNING: Illegal reflective access by org.openjdk.jmh.util.Utils
> >> (file:/home/robot/benchmarks.jar) to field java.io.Console.cs
> >> WARNING: Please consider reporting this to the maintainers of
> >> org.openjdk.jmh.util.Utils
> >> WARNING: Use --illegal-access=warn to enable warnings of further
> >> illegal reflective access operations
> >> WARNING: All illegal access operations will be denied in a future
> >> release =============== DEBUG MESSAGE: Atomic load(jlong)
> unsupported
> >> on this platform ================
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> =============== DEBUG MESSAGE: Atomic load(jlong) unsupported on
> this
> >> platform ================
> >>
> >> [thread 4430 also had an error]
> >> [error occurred during error reporting ((null)), id 0xe0000000]
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> [error occurred during error reporting (printing fatal error
> >> message), id 0xe0000000]
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> [error occurred during error reporting (printing type of error), id
> >> 0xe0000000]
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> [error occurred during error reporting (printing stack bounds), id
> >> 0xe0000000]
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> [error occurred during error reporting (printing native stack), id
> >> 0xe0000000]
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> [error occurred during error reporting (printing Java stack), id
> >> 0xe0000000]
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> [error occurred during error reporting (printing target Java thread
> >> stack), id 0xe0000000]
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> [error occurred during error reporting (printing siginfo), id
> >> 0xe0000000]
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> [error occurred during error reporting (CDS archive access warning),
> >> id 0xe0000000]
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> [error occurred during error reporting (printing register info), id
> >> 0xe0000000]
> >>
> >> =============== DEBUG MESSAGE: Atomic store(jlong) unsupported
> on
> >> this platform ================
> >>
> >>
> >> [Too many errors, abort]
> >> Aborted
> >>
> >> I think that in OpenJDK10 changed something in compare to OpenJDK9 in
> >> relation to ARM5 support.
> >>
> >> Any idea?
> >>
> >> Many thanks in advance.
> >>
> >> Cheers
> >>
> >> Juan Antonio
> >>
From stefan.karlsson at oracle.com Thu Apr 5 06:11:29 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 5 Apr 2018 08:11:29 +0200
Subject: RFR: 8201136: Move GC flags from globals.hpp to GC specific files
Message-ID: <2acc1099-f7f9-d376-6e60-1c45775513b6@oracle.com>
Hi all,
Please review this patch to move GC flags out of globals.hpp and into GC
specific files.
?http://cr.openjdk.java.net/~stefank/8201136/webrev.01
?https://bugs.openjdk.java.net/browse/JDK-8201136
This is one step towards:
?https://bugs.openjdk.java.net/browse/JDK-8200729 - Conditional
compilation of GCs
With this patch we only have to update gc_globals.hpp when adding new GCs.
Thanks,
StefanK
From rohitarulraj at gmail.com Thu Apr 5 07:19:44 2018
From: rohitarulraj at gmail.com (Rohit Arul Raj)
Date: Thu, 5 Apr 2018 12:49:44 +0530
Subject: RFC: C2 Object Initialization - Using XMM/YMM registers
Message-ID: <CAPVMLfVcpTXpaTeMwo0Gg=NgDpkz+Z2cD+FP7mw6iHJH5R-+nw@mail.gmail.com>
Hi All,
I was going through the C2 object initialization (zeroing) code based
on the below bug entry:
https://bugs.openjdk.java.net/browse/JDK-8146801
Right now, for longer lengths we use "rep stos" instructions on x86. I
was experimenting with using XMM/YMM registers (on AMD EPYC processor)
and found that they do improve performance for certain lengths:
For lengths > 64 bytes - 512 bytes : improvement is in the range of 8% to 44%
For lengths > 512bytes : some lengths show slight
improvement in the range of 2% to 7%, others almost same as "rep stos"
numbers.
I have attached the complete performance data (data.txt) for reference .
Can we add this as an user option similar to UseXMMForArrayCopy?
I have used the same test case as in
(http://cr.openjdk.java.net/~shade/8146801/benchmarks.jar) with
additional sizes.
Initial Patch:
I haven't added the check for 32-bit mode as I need some help with the
code (description given below the patch).
The code is similar to the one used in array copy stubs (copy_bytes_forward).
diff --git a/src/hotspot/cpu/x86/globals_x86.hpp
b/src/hotspot/cpu/x86/globals_x86.hpp
--- a/src/hotspot/cpu/x86/globals_x86.hpp
+++ b/src/hotspot/cpu/x86/globals_x86.hpp
@@ -150,6 +150,9 @@
product(bool, UseUnalignedLoadStores, false, \
"Use SSE2 MOVDQU instruction for Arraycopy") \
\
+ product(bool, UseXMMForObjInit, false, \
+ "Use XMM/YMM MOVDQU instruction for Object Initialization") \
+ \
product(bool, UseFastStosb, false, \
"Use fast-string operation for zeroing: rep stosb") \
\
diff --git a/src/hotspot/cpu/x86/macroAssembler_x86.cpp
b/src/hotspot/cpu/x86/macroAssembler_x86.cpp
--- a/src/hotspot/cpu/x86/macroAssembler_x86.cpp
+++ b/src/hotspot/cpu/x86/macroAssembler_x86.cpp
@@ -7106,6 +7106,56 @@
if (UseFastStosb) {
shlptr(cnt, 3); // convert to number of bytes
rep_stosb();
+ } else if (UseXMMForObjInit && UseUnalignedLoadStores) {
+ Label L_loop, L_sloop, L_check, L_tail, L_end;
+ push(base);
+ if (UseAVX >= 2)
+ vpxor(xmm10, xmm10, xmm10, AVX_256bit);
+ else
+ vpxor(xmm10, xmm10, xmm10, AVX_128bit);
+
+ jmp(L_check);
+
+ BIND(L_loop);
+ if (UseAVX >= 2) {
+ vmovdqu(Address(base, 0), xmm10);
+ vmovdqu(Address(base, 32), xmm10);
+ } else {
+ movdqu(Address(base, 0), xmm10);
+ movdqu(Address(base, 16), xmm10);
+ movdqu(Address(base, 32), xmm10);
+ movdqu(Address(base, 48), xmm10);
+ }
+ addptr(base, 64);
+
+ BIND(L_check);
+ subptr(cnt, 8);
+ jccb(Assembler::greaterEqual, L_loop);
+ addptr(cnt, 4);
+ jccb(Assembler::less, L_tail);
+ // Copy trailing 32 bytes
+ if (UseAVX >= 2) {
+ vmovdqu(Address(base, 0), xmm10);
+ } else {
+ movdqu(Address(base, 0), xmm10);
+ movdqu(Address(base, 16), xmm10);
+ }
+ addptr(base, 32);
+ subptr(cnt, 4);
+
+ BIND(L_tail);
+ addptr(cnt, 4);
+ jccb(Assembler::lessEqual, L_end);
+ decrement(cnt);
+
+ BIND(L_sloop);
+ movptr(Address(base, 0), tmp);
+ addptr(base, 8);
+ decrement(cnt);
+ jccb(Assembler::greaterEqual, L_sloop);
+
+ BIND(L_end);
+ pop(base);
} else {
NOT_LP64(shlptr(cnt, 1);) // convert to number of 32-bit words
for 32-bit VM
rep_stos();
When I use XMM0 as a temporary register, the micro-benchmark crashes.
Saving and Restoring the XMM0 register before and after use works
fine.
Looking at the "hotspot/src/cpu/x86/vm/x86.ad" file, XMM0 as with
other XMM registers has been mentioned as Save-On-Call registers and
on Linux ABI, no register is preserved across function calls though
XMM0-XMM7 might hold parameters. So I assumed using XMM0 without
saving/restoring should be fine.
Is it incorrect use XMM* registers without saving/restoring them?
Using XMM10 register as temporary register works fine without having
to save and restore it.
Please let me know your comments.
Regards,
Rohit
-------------- next part --------------
-----------------------------------------------------------------------------------------------------------------
|S.No | Array | | JDK11 trunk code ns/op | JDK11 trunk - ymm 64b loop ns/op |
| | Size | Total | | |
| | | Size |-----------------------------------|-----------------------------------------------------|
| | | | Const |variance|Variable|variance| Const |variance|Variable|variance|%dif Con|%dif var|
|-----|--------|--------|-----------------------------------|-----------------------------------------------------|
| 1 | 0 | 0 | 8.59 | 0.00 | 8.98 | 0.01 | 8.59 | 0.00 | 8.98 | 0.01 | 0.01% | -0.03% |
| 2 | 1 | 8 | 8.98 | 0.00 | 9.42 | 0.02 | 8.98 | 0.01 | 9.43 | 0.02 | 0.01% | -0.10% |
| 3 | 2 | 8 | 8.98 | 0.00 | 9.43 | 0.01 | 8.98 | 0.00 | 9.43 | 0.02 | 0.01% | -0.05% |
| 4 | 4 | 16 | 9.38 | 0.00 | 9.76 | 0.02 | 9.38 | 0.00 | 9.75 | 0.01 | 0.02% | 0.05% |
| 5 | 8 | 32 | 10.29 | 0.03 | 10.63 | 0.00 | 10.27 | 0.00 | 10.64 | 0.01 | 0.18% | -0.09% |
| 6 | 16 | 64 | 12.10 | 0.02 | 12.57 | 0.02 | 12.09 | 0.01 | 12.55 | 0.01 | 0.08% | 0.18% |
| 7 | 24 | 96 | 15.21 | 0.47 | 20.66 | 0.59 | 12.71 | 0.20 | 12.78 | 0.04 | 16.45% | 38.15% |<==
| 8 | 32 | 128 | 16.83 | 0.01 | 23.40 | 0.59 | 15.37 | 0.06 | 15.55 | 0.06 | 8.69% | 33.54% |
| 9 | 40 | 160 | 18.99 | 0.02 | 24.53 | 0.69 | 17.32 | 0.05 | 17.57 | 0.04 | 8.80% | 28.37% |
| 10 | 56 | 224 | 27.28 | 0.26 | 31.04 | 0.21 | 21.85 | 0.14 | 22.77 | 0.04 | 19.88% | 26.65% |
| 11 | 64 | 256 | 31.02 | 0.13 | 51.65 | 0.59 | 24.73 | 0.14 | 29.22 | 0.16 | 20.27% | 43.42% |
| 12 | 96 | 384 | 59.82 | 0.10 | 64.09 | 0.12 | 50.46 | 0.11 | 53.13 | 0.24 | 15.64% | 17.09% |
| 13 | 128 | 512 | 69.83 | 0.59 | 71.77 | 0.61 | 63.34 | 0.13 | 64.45 | 0.62 | 9.29% | 10.20% |<==
| 14 | 136 | 544 | 74.07 | 1.01 | 74.98 | 0.32 | 68.93 | 0.27 | 69.37 | 0.21 | 6.94% | 7.48% |
| 15 | 256 | 1 KB | 121.87 | 0.29 | 122.32 | 0.21 | 117.21 | 0.50 | 119.35 | 0.24 | 3.83% | 2.43% |
| 16 | 512 | 2 KB | 219.58 | 1.11 | 223.36 | 0.47 | 216.32 | 5.19 | 220.73 | 0.24 | 1.49% | 1.18% |
| 17 | 808 | 3 KB | 323.24 | 0.64 | 342.78 | 2.15 | 319.93 | 0.81 | 331.41 | 0.46 | 1.02% | 3.32% |
| 18 | 1024 | 4 KB | 421.69 | 0.85 | 451.06 | 1.22 | 398.47 | 0.60 | 430.78 | 0.75 | 5.51% | 4.50% |
| 19 | 2048 | 8 KB | 857.81 | 0.77 | 865.11 | 0.95 | 810.42 | 0.50 | 847.25 | 0.52 | 5.53% | 2.06% |
| 20 | 4096 | 16 KB |1612.11 | 5.13 |1613.38 | 2.29 |1583.33 | 7.34 |1598.82 | 1.90 | 1.79% | 0.90% |
| 21 | 8192 | 32 KB |3100.39 | 3.48 |3094.99 | 4.22 |3067.74 | 2.86 |3069.04 | 16.91 | 1.05% | 0.84% |
| 22 | 16384 | 64 KB |6059.48 | 10.50 |6073.39 | 8.60 |5978.82 | 4.18 |5971.72 | 5.98 | 1.33% | 1.67% |
| 23 | 32768 | 128 KB |12109.75| 29.16 |12178.25| 34.66 |11880.35| 8.51 |11861.76| 12.38 | 1.89% | 2.60% |
| 24 | 65536 | 256 KB |24303.89| 26.84 |24404.13| 37.95 |23606.47| 15.52 |23624.83| 39.52 | 2.87% | 3.19% |
| 25 | 131072 | 512 KB |49467.66| 95.65 |49216.41| 42.92 |48873.85| 70.28 |48599.38| 195.03 | 1.20% | 1.25% |
| 26 | 262144 | 1 MB |102971.2|3149.34 |102631.9|3168.90 |100962.7|3610.16 |100691.8|3528.52 | 1.95% | 1.89% |
| 27 | 524288 | 2 MB |223155.5| 286.52 |224287.9| 324.00 |223133.0| 283.44 |222802.6| 517.78 | 0.01% | 0.66% |
| 28 |1048576 | 4 MB |447718.2| 221.75 |447240.2| 430.55 |445605.1| 617.14 |440841.5| 323.20 | 0.47% | 1.43% |
| 29 |2097152 | 8 MB |891545.5| 968.99 |890070.5| 502.85 |888538.5| 775.27 |880552.1|2235.50 | 0.34% | 1.07% |
-----------------------------------------------------------------------------------------------------------------
From erik.osterlund at oracle.com Thu Apr 5 08:09:37 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Thu, 5 Apr 2018 10:09:37 +0200
Subject: RFR (XS): 8201167: Remove MacroAssembler::cmp_heap_oop on x86
Message-ID: <5AC5D9C1.3030309@oracle.com>
Hi,
The MacroAssembler::cmp_heap_oop member function on x86 is not currently
used anywhere in hotspot. Moreover, it is no longer safe to use it with
modern GCs using load barriers. Since it is unsafe to use and is not
used today, it should be removed.
Webrev:
http://cr.openjdk.java.net/~eosterlund/8201167/webrev.00/
Thanks,
/Erik
From shade at redhat.com Thu Apr 5 08:20:57 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 5 Apr 2018 10:20:57 +0200
Subject: RFR (XS): 8201167: Remove MacroAssembler::cmp_heap_oop on x86
In-Reply-To: <5AC5D9C1.3030309@oracle.com>
References: <5AC5D9C1.3030309@oracle.com>
Message-ID: <3618269c-5a34-3bda-aba0-2ce5cc36cddc@redhat.com>
On 04/05/2018 10:09 AM, Erik ?sterlund wrote:
> The MacroAssembler::cmp_heap_oop member function on x86 is not currently used anywhere in hotspot.
> Moreover, it is no longer safe to use it with modern GCs using load barriers. Since it is unsafe to
> use and is not used today, it should be removed.
>
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8201167/webrev.00/
Yes, there is MacroAssembler::cmpoop for that.
Looks good!
-Aleksey
From thomas.schatzl at oracle.com Thu Apr 5 08:22:24 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 05 Apr 2018 10:22:24 +0200
Subject: RFR (XS): 8201167: Remove MacroAssembler::cmp_heap_oop on x86
In-Reply-To: <5AC5D9C1.3030309@oracle.com>
References: <5AC5D9C1.3030309@oracle.com>
Message-ID: <1522916544.2395.0.camel@oracle.com>
Hi,
On Thu, 2018-04-05 at 10:09 +0200, Erik ?sterlund wrote:
> Hi,
>
> The MacroAssembler::cmp_heap_oop member function on x86 is not
> currently used anywhere in hotspot. Moreover, it is no longer safe to
> use it with modern GCs using load barriers. Since it is unsafe to use
> and is not used today, it should be removed.
>
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8201167/webrev.00/
>
> Thanks,
> /Erik
looks good.
Thomas
From erik.osterlund at oracle.com Thu Apr 5 08:24:52 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Thu, 5 Apr 2018 10:24:52 +0200
Subject: RFR (XS): 8201167: Remove MacroAssembler::cmp_heap_oop on x86
In-Reply-To: <3618269c-5a34-3bda-aba0-2ce5cc36cddc@redhat.com>
References: <5AC5D9C1.3030309@oracle.com>
<3618269c-5a34-3bda-aba0-2ce5cc36cddc@redhat.com>
Message-ID: <5AC5DD54.20106@oracle.com>
Hi Aleksey,
Thanks for the review.
/Erik
On 2018-04-05 10:20, Aleksey Shipilev wrote:
> On 04/05/2018 10:09 AM, Erik ?sterlund wrote:
>> The MacroAssembler::cmp_heap_oop member function on x86 is not currently used anywhere in hotspot.
>> Moreover, it is no longer safe to use it with modern GCs using load barriers. Since it is unsafe to
>> use and is not used today, it should be removed.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8201167/webrev.00/
> Yes, there is MacroAssembler::cmpoop for that.
>
> Looks good!
>
> -Aleksey
From erik.osterlund at oracle.com Thu Apr 5 08:25:12 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Thu, 5 Apr 2018 10:25:12 +0200
Subject: RFR (XS): 8201167: Remove MacroAssembler::cmp_heap_oop on x86
In-Reply-To: <1522916544.2395.0.camel@oracle.com>
References: <5AC5D9C1.3030309@oracle.com> <1522916544.2395.0.camel@oracle.com>
Message-ID: <5AC5DD68.4090406@oracle.com>
Hi Thomas,
Thanks for the review.
/Erik
On 2018-04-05 10:22, Thomas Schatzl wrote:
> Hi,
>
> On Thu, 2018-04-05 at 10:09 +0200, Erik ?sterlund wrote:
>> Hi,
>>
>> The MacroAssembler::cmp_heap_oop member function on x86 is not
>> currently used anywhere in hotspot. Moreover, it is no longer safe to
>> use it with modern GCs using load barriers. Since it is unsafe to use
>> and is not used today, it should be removed.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8201167/webrev.00/
>>
>> Thanks,
>> /Erik
> looks good.
>
> Thomas
From shade at redhat.com Thu Apr 5 08:41:08 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 5 Apr 2018 10:41:08 +0200
Subject: RFR: 8200735: Move CMS specific code from binaryTreeDictionary
and freeList to CMS files
In-Reply-To: <2b2b9c73-c018-4316-0d27-b6c90c5534d0@oracle.com>
References: <71db7b0e-e2cb-cd13-a255-e5d4f8cb883d@oracle.com>
<03019539-9ca2-eb44-608d-34199984916e@redhat.com>
<fc32e69a-a29d-45dd-8497-7916ded53fb8@oracle.com>
<2b2b9c73-c018-4316-0d27-b6c90c5534d0@oracle.com>
Message-ID: <ad884c42-958c-f300-9d88-f2b0a59d1c73@redhat.com>
On 04/04/2018 08:02 PM, Stefan Karlsson wrote:
> I've updated the patch so that we maintain the order of the moved classes and functions:
> ?http://cr.openjdk.java.net/~stefank/8200735/webrev.02
> http://cr.openjdk.java.net/~stefank/8200735/webrev.02.delta
Okay.
-Aleksey
From shade at redhat.com Thu Apr 5 09:04:49 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 5 Apr 2018 11:04:49 +0200
Subject: RFR: 8201136: Move GC flags from globals.hpp to GC specific files
In-Reply-To: <2acc1099-f7f9-d376-6e60-1c45775513b6@oracle.com>
References: <2acc1099-f7f9-d376-6e60-1c45775513b6@oracle.com>
Message-ID: <248f33db-e183-92d8-5a45-ec93d6ff3566@redhat.com>
On 04/05/2018 08:11 AM, Stefan Karlsson wrote:
> Please review this patch to move GC flags out of globals.hpp and into GC specific files.
>
> ?http://cr.openjdk.java.net/~stefank/8201136/webrev.01
> ?https://bugs.openjdk.java.net/browse/JDK-8201136
Oooof, what a move! I like it, looks good.
*) In globals.hpp, L2987-..., you probably want to right-adjust the backslashes?
*) In gc_globals.hpp, we still have Use{CMS,Serial,G1,Parallel,...}GC -- is the intent to have these
in shared gc_globals.hpp, not in per-GC-globals.hpp, and check for GC support at init? In other
words, when conditional GC compilation arrives, we still have GC enabling flags available, but not
the GC-specific flags?
Thanks,
-Aleksey
From robbin.ehn at oracle.com Thu Apr 5 09:26:49 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Thu, 5 Apr 2018 11:26:49 +0200
Subject: RFR: 8201136: Move GC flags from globals.hpp to GC specific files
In-Reply-To: <248f33db-e183-92d8-5a45-ec93d6ff3566@redhat.com>
References: <2acc1099-f7f9-d376-6e60-1c45775513b6@oracle.com>
<248f33db-e183-92d8-5a45-ec93d6ff3566@redhat.com>
Message-ID: <8f8146da-9359-3082-46b4-e096ad0f700f@oracle.com>
On 2018-04-05 11:04, Aleksey Shipilev wrote:
> On 04/05/2018 08:11 AM, Stefan Karlsson wrote:
>> Please review this patch to move GC flags out of globals.hpp and into GC specific files.
>>
>> ?http://cr.openjdk.java.net/~stefank/8201136/webrev.01
>> ?https://bugs.openjdk.java.net/browse/JDK-8201136
>
> Oooof, what a move! I like it, looks good.
+1
/Robbin
>
> *) In globals.hpp, L2987-..., you probably want to right-adjust the backslashes?
>
> *) In gc_globals.hpp, we still have Use{CMS,Serial,G1,Parallel,...}GC -- is the intent to have these
> in shared gc_globals.hpp, not in per-GC-globals.hpp, and check for GC support at init? In other
> words, when conditional GC compilation arrives, we still have GC enabling flags available, but not
> the GC-specific flags?
>
> Thanks,
> -Aleksey
>
From stefan.karlsson at oracle.com Thu Apr 5 09:34:32 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 5 Apr 2018 11:34:32 +0200
Subject: RFR: 8200735: Move CMS specific code from binaryTreeDictionary
and freeList to CMS files
In-Reply-To: <ad884c42-958c-f300-9d88-f2b0a59d1c73@redhat.com>
References: <71db7b0e-e2cb-cd13-a255-e5d4f8cb883d@oracle.com>
<03019539-9ca2-eb44-608d-34199984916e@redhat.com>
<fc32e69a-a29d-45dd-8497-7916ded53fb8@oracle.com>
<2b2b9c73-c018-4316-0d27-b6c90c5534d0@oracle.com>
<ad884c42-958c-f300-9d88-f2b0a59d1c73@redhat.com>
Message-ID: <af37d467-a0c4-bddd-86c6-404e91f9902e@oracle.com>
Thanks!
StefanK
On 2018-04-05 10:41, Aleksey Shipilev wrote:
> On 04/04/2018 08:02 PM, Stefan Karlsson wrote:
>> I've updated the patch so that we maintain the order of the moved classes and functions:
>> ?http://cr.openjdk.java.net/~stefank/8200735/webrev.02
>> http://cr.openjdk.java.net/~stefank/8200735/webrev.02.delta
>
> Okay.
>
> -Aleksey
>
From stefan.johansson at oracle.com Thu Apr 5 09:42:39 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Thu, 5 Apr 2018 11:42:39 +0200
Subject: RFR: 8201136: Move GC flags from globals.hpp to GC specific files
In-Reply-To: <2acc1099-f7f9-d376-6e60-1c45775513b6@oracle.com>
References: <2acc1099-f7f9-d376-6e60-1c45775513b6@oracle.com>
Message-ID: <d94b1488-946e-8df0-0fbe-2a35d4c8bd19@oracle.com>
On 2018-04-05 08:11, Stefan Karlsson wrote:
> Hi all,
>
> Please review this patch to move GC flags out of globals.hpp and into GC
> specific files.
>
> ?http://cr.openjdk.java.net/~stefank/8201136/webrev.01
> ?https://bugs.openjdk.java.net/browse/JDK-8201136
>
Really nice! It would be even nicer with a few newlines in the VM_FLAGS
and GC_FLAGS macros, I think it would improve readability.
I also used PrintFlagsFinal and checked that no flags were lost in the
move.
Thanks,
Stefan
> This is one step towards:
> ?https://bugs.openjdk.java.net/browse/JDK-8200729 - Conditional
> compilation of GCs
>
> With this patch we only have to update gc_globals.hpp when adding new GCs.
>
> Thanks,
> StefanK
From stefan.karlsson at oracle.com Thu Apr 5 09:46:37 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 5 Apr 2018 11:46:37 +0200
Subject: RFR: 8201136: Move GC flags from globals.hpp to GC specific files
In-Reply-To: <d94b1488-946e-8df0-0fbe-2a35d4c8bd19@oracle.com>
References: <2acc1099-f7f9-d376-6e60-1c45775513b6@oracle.com>
<d94b1488-946e-8df0-0fbe-2a35d4c8bd19@oracle.com>
Message-ID: <97145397-ddba-b2ed-bdbe-b68e2d44b788@oracle.com>
On 2018-04-05 11:42, Stefan Johansson wrote:
>
>
> On 2018-04-05 08:11, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to move GC flags out of globals.hpp and into
>> GC specific files.
>>
>> ??http://cr.openjdk.java.net/~stefank/8201136/webrev.01
>> ??https://bugs.openjdk.java.net/browse/JDK-8201136
>>
> Really nice! It would be even nicer with a few newlines in the VM_FLAGS
> and GC_FLAGS macros, I think it would improve readability.
>
> I also used PrintFlagsFinal and checked that no flags were lost in the
> move.
Thanks StefanJ!
Here are new webrevs with a cleanup patch proposed by StefanJ. Look at
the patch to see the correct indentation.
http://cr.openjdk.java.net/~stefank/8201136/webrev.02.delta
http://cr.openjdk.java.net/~stefank/8201136/webrev.02
Thanks,
StefanK
>
> Thanks,
> Stefan
>
>> This is one step towards:
>> ??https://bugs.openjdk.java.net/browse/JDK-8200729 - Conditional
>> compilation of GCs
>>
>> With this patch we only have to update gc_globals.hpp when adding new
>> GCs.
>>
>> Thanks,
>> StefanK
From stefan.karlsson at oracle.com Thu Apr 5 09:46:56 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 5 Apr 2018 11:46:56 +0200
Subject: RFR: 8201136: Move GC flags from globals.hpp to GC specific files
In-Reply-To: <8f8146da-9359-3082-46b4-e096ad0f700f@oracle.com>
References: <2acc1099-f7f9-d376-6e60-1c45775513b6@oracle.com>
<248f33db-e183-92d8-5a45-ec93d6ff3566@redhat.com>
<8f8146da-9359-3082-46b4-e096ad0f700f@oracle.com>
Message-ID: <9a373b0d-5e04-2b30-d005-8c613464afa9@oracle.com>
Thanks, Robbin.
StefanK
On 2018-04-05 11:26, Robbin Ehn wrote:
> On 2018-04-05 11:04, Aleksey Shipilev wrote:
>> On 04/05/2018 08:11 AM, Stefan Karlsson wrote:
>>> Please review this patch to move GC flags out of globals.hpp and into
>>> GC specific files.
>>>
>>> ??http://cr.openjdk.java.net/~stefank/8201136/webrev.01
>>> ??https://bugs.openjdk.java.net/browse/JDK-8201136
>>
>> Oooof, what a move! I like it, looks good.
>
> +1
>
> /Robbin
>
>>
>> *) In globals.hpp, L2987-..., you probably want to right-adjust the
>> backslashes?
>>
>> *) In gc_globals.hpp, we still have Use{CMS,Serial,G1,Parallel,...}GC
>> -- is the intent to have these
>> in shared gc_globals.hpp, not in per-GC-globals.hpp, and check for GC
>> support at init? In other
>> words, when conditional GC compilation arrives, we still have GC
>> enabling flags available, but not
>> the GC-specific flags?
>>
>> Thanks,
>> -Aleksey
>>
From stefan.karlsson at oracle.com Thu Apr 5 09:58:03 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 5 Apr 2018 11:58:03 +0200
Subject: RFR: 8201136: Move GC flags from globals.hpp to GC specific files
In-Reply-To: <248f33db-e183-92d8-5a45-ec93d6ff3566@redhat.com>
References: <2acc1099-f7f9-d376-6e60-1c45775513b6@oracle.com>
<248f33db-e183-92d8-5a45-ec93d6ff3566@redhat.com>
Message-ID: <e05212ec-ebc5-a845-85a2-8c616690b4fe@oracle.com>
On 2018-04-05 11:04, Aleksey Shipilev wrote:
> On 04/05/2018 08:11 AM, Stefan Karlsson wrote:
>> Please review this patch to move GC flags out of globals.hpp and into GC specific files.
>>
>> ?http://cr.openjdk.java.net/~stefank/8201136/webrev.01
>> ?https://bugs.openjdk.java.net/browse/JDK-8201136
>
> Oooof, what a move! I like it, looks good.
Thanks, Aleksey.
>
> *) In globals.hpp, L2987-..., you probably want to right-adjust the backslashes?
I sent an updated webrev to my answer to StefanJ's review. I hope that
looks good enough.
>
> *) In gc_globals.hpp, we still have Use{CMS,Serial,G1,Parallel,...}GC -- is the intent to have these
> in shared gc_globals.hpp, not in per-GC-globals.hpp, and check for GC support at init? In other
> words, when conditional GC compilation arrives, we still have GC enabling flags available, but not
> the GC-specific flags?
The current state of my patch guards most usages of the
Use{CMS,Serial,G1,Parallel,...}GC flags with the appropriate
INCLUDE_<GC> guard. I'm not sure if it is possible to take it all the
way and guard all usages, but I try and we'll see if it is possible.
What do you think? Should we try to move the flags to their respective
<gc>_globals.hpp file?
Thanks,
StefanK
>
> Thanks,
> -Aleksey
>
From stefan.karlsson at oracle.com Thu Apr 5 10:03:47 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 5 Apr 2018 12:03:47 +0200
Subject: RFR: 8201168: Move GC command line constraint functions to GC
specific files
Message-ID: <99b6d120-44bf-b243-7fa1-5a5cb9c44b8b@oracle.com>
Hi all,
Please review this patch to move the GC flag constraint functions into
GC specific files.
http://cr.openjdk.java.net/~stefank/8201168/webrev.01
https://bugs.openjdk.java.net/browse/JDK-8201168
This is one step towards:
https://bugs.openjdk.java.net/browse/JDK-8200729 - Conditional
compilation of GCs
I know that this conflicts with Gerards rename of the flags to JVMFlags,
but I don't want to wait for that to get pushed before publishing this
review request.
Thanks,
StefanK
From adinn at redhat.com Thu Apr 5 10:23:33 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 5 Apr 2018 11:23:33 +0100
Subject: RFR: 8200735: Move CMS specific code from binaryTreeDictionary
and freeList to CMS files
In-Reply-To: <71db7b0e-e2cb-cd13-a255-e5d4f8cb883d@oracle.com>
References: <71db7b0e-e2cb-cd13-a255-e5d4f8cb883d@oracle.com>
Message-ID: <9b205105-1cd9-e672-8046-8c9fd4225536@redhat.com>
Hi Stefan,
On 04/04/18 14:22, Stefan Karlsson wrote:
> [Sending to hotspot-dev because this changes both GC and Metaspace code]
>
> Please review this patch to move CMS specific code out of the
> binaryTreeDictionary.*pp and freeList.*hpp files into CMS files.
I'm only really familiar with this code from the metaspace side but this
cleanup looks good to me (thanks also for the 2nd webrev which is
definitely an improvement wrt reviewing).
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
From stefan.karlsson at oracle.com Thu Apr 5 10:25:56 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 5 Apr 2018 12:25:56 +0200
Subject: RFR: 8200735: Move CMS specific code from binaryTreeDictionary
and freeList to CMS files
In-Reply-To: <9b205105-1cd9-e672-8046-8c9fd4225536@redhat.com>
References: <71db7b0e-e2cb-cd13-a255-e5d4f8cb883d@oracle.com>
<9b205105-1cd9-e672-8046-8c9fd4225536@redhat.com>
Message-ID: <7929d470-d31f-9c6c-7056-89e631d1e3d6@oracle.com>
Thanks, Andrew!
StefanK
On 2018-04-05 12:23, Andrew Dinn wrote:
> Hi Stefan,
>
> On 04/04/18 14:22, Stefan Karlsson wrote:
>> [Sending to hotspot-dev because this changes both GC and Metaspace code]
>>
>> Please review this patch to move CMS specific code out of the
>> binaryTreeDictionary.*pp and freeList.*hpp files into CMS files.
> I'm only really familiar with this code from the metaspace side but this
> cleanup looks good to me (thanks also for the 2nd webrev which is
> definitely an improvement wrt reviewing).
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>
From gunter.haug at sap.com Thu Apr 5 10:28:19 2018
From: gunter.haug at sap.com (Haug, Gunter)
Date: Thu, 5 Apr 2018 10:28:19 +0000
Subject: RFR(S): 8200720: Print accumulated number of allocated bytes in
thread dump
Message-ID: <171FA571-AFEC-4E88-B681-D10F8DFD1639@sap.com>
Hi,
can I please have a review and a sponsor for the following enhancement:
http://cr.openjdk.java.net/~ghaug/webrevs/8200720
https://bugs.openjdk.java.net/browse/JDK-8200720
We at SAP have extended the thread dumps (obtained by jstack or jcmd) by several fields providing thread specific information. These extensions are quite popular with our support team. With some knowledge of the architecture of the application, they often allow for quick and simple diagnosis of a running system. Therefore we would like to contribute these enhancements.
I took the quite simple accumulated number of bytes allocated by a thread as an example. This only works with TLAB active. Provided it is known how the application should behave, a misbehaving thread can identified easily.
There is no measurable overhead for this enhancement. However, it may be a problem that the format of the output is changed. Tools parsing the output may have to be changed.
Here is an example of the output generated:
---------------------------------------------------------
"main" #1 prio=5 os_prio=31 allocated=243048448B tid=0x00007fca98000800 nid=0x1d03 waiting on condition [0x0000000109baa000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(java.base/Native Method)
...
---------------------------------------------------------
As mentioned above, we have a whole bunch of other enhancements to the thread dump similar to this one and would be willing to contribute them if there is any interest.
Thanks and best regards,
Gunter
From shade at redhat.com Thu Apr 5 10:39:15 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 5 Apr 2018 12:39:15 +0200
Subject: RFR: 8201136: Move GC flags from globals.hpp to GC specific files
In-Reply-To: <e05212ec-ebc5-a845-85a2-8c616690b4fe@oracle.com>
References: <2acc1099-f7f9-d376-6e60-1c45775513b6@oracle.com>
<248f33db-e183-92d8-5a45-ec93d6ff3566@redhat.com>
<e05212ec-ebc5-a845-85a2-8c616690b4fe@oracle.com>
Message-ID: <f0fd3386-7ba7-584a-59b4-16af78f12e3b@redhat.com>
On 04/05/2018 11:58 AM, Stefan Karlsson wrote:
>> *) In globals.hpp, L2987-..., you probably want to right-adjust the backslashes?
>
> I sent an updated webrev to my answer to StefanJ's review. I hope that looks good enough.
Ok, that looks good.
>> *) In gc_globals.hpp, we still have Use{CMS,Serial,G1,Parallel,...}GC -- is the intent to have these
>> in shared gc_globals.hpp, not in per-GC-globals.hpp, and check for GC support at init? In other
>> words, when conditional GC compilation arrives, we still have GC enabling flags available, but not
>> the GC-specific flags?
>
> The current state of my patch guards most usages of the Use{CMS,Serial,G1,Parallel,...}GC flags with
> the appropriate INCLUDE_<GC> guard. I'm not sure if it is possible to take it all the way and guard
> all usages, but I try and we'll see if it is possible.
>
> What do you think? Should we try to move the flags to their respective <gc>_globals.hpp file?
Meh. On one hand, it is really an UX question: should, say, Minimal VM barf with "Unrecognized VM
option: UseG1GC" or say "G1 is not supported"? I think it should do the former, which means UseG1GC
should be in gc_globals.hpp.
Guard-wise, it seems more convenient to have:
#ifdef INCLUDE_G1
if (UseG1GC) {
// <G1-specific thing>
}
#endif
...because the protected block may reference G1-specific classes.
This looks more awkward:
if (UseG1GC) {
#ifdef INCLUDE_G1
// <G1-specific thing>
#endif
}
UseG1GC in gc_globals.hpp allows both, and moving UseG1GC to g1_globals.hpp allows only the first form.
But doing the first form probably makes one-off checks and asserts that include UseG1GC in shared
parts more awkward, because we would need to take care of INCLUDE_G1 on those paths, which would
give raise to crud like:
if (... || G1_ONLY(UseG1GC) NOT_G1(true)) ...
...instead of just:
if (... || UseG1GC) ...
I am leaning towards having Use*GC flags in gc_globals.hpp. I was wondering if that is intentional,
or just preserving the status quo.
Aside, it would be interesting to see if we can easily make --disable-g1gc (or whatever it is called
in the build-configurable GC RFE) to turn UseG1GC to compile-time constant, so that the whole thing
would fold.
Thanks,
-Aleksey
From shade at redhat.com Thu Apr 5 11:00:23 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 5 Apr 2018 13:00:23 +0200
Subject: RFR: 8200759: Move GC entries in vmStructs.cpp to GC specific
files
In-Reply-To: <8f9ef0fb-14b6-fca8-04ac-1ce49a3a11f0@oracle.com>
References: <8f9ef0fb-14b6-fca8-04ac-1ce49a3a11f0@oracle.com>
Message-ID: <f9bdd388-f14d-4c7e-051b-19a0a8bf7ef6@redhat.com>
On 04/04/2018 09:37 PM, Stefan Karlsson wrote:
> Hi all,
>
> Please review this patch to move GC specific entries in vmStructs.cpp out to GC specific files.
>
> http://cr.openjdk.java.net/~stefank/8200759/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8200759
*) It feels awkward to move JavaThread::_satb_mark_queue and JavaThread::_dirty_card_queue, to
VM_STRUCTS_G1GC, since it is guarded by INCLUDE_ALL_GCS. VM_STRUCTS_GC seems more fitting. (Trivia:
Shenandoah uses those things too, so they are "shared", even though the implementation is indeed in
vm/gc/g1).
*) I'd do:
#ifdef INCLUDE_ALL_GCS
declare_constant_with_value("satbMarkQueueBufferOffset", ...
declare_constant_with_value("satbMarkQueueIndexOffset", ...
declare_constant_with_value("satbMarkQueueActiveOffset", ...
#endif
...instead of:
ALL_GCS_ONLY(declare_constant_with_value("satbMarkQueueBufferOffset", ...)
ALL_GCS_ONLY(declare_constant_with_value("satbMarkQueueIndexOffset", ...)
ALL_GCS_ONLY(declare_constant_with_value("satbMarkQueueActiveOffset", ...)
It would be easier with multiple GCs wanting to have a piece of it. For example, it would be easier
for Shenandoah to do:
#ifdef (INCLUDE_G1 || INCLUDE_SHENANDOAH)
declare_constant_with_value("satbMarkQueueBufferOffset", ...
declare_constant_with_value("satbMarkQueueIndexOffset", ...
declare_constant_with_value("satbMarkQueueActiveOffset", ...
#endif
In other words, ease off on ALL_GCS_ONLY macro, because it is not easily composable.
Ditto for e.g.:
154 ALL_GCS_ONLY(VM_TYPES_CMSGC(declare_type, \
155 declare_toplevel_type, \
156 declare_integer_type)) \
157 ALL_GCS_ONLY(VM_TYPES_G1GC(declare_type, \
158 declare_toplevel_type, \
159 declare_integer_type)) \
160 ALL_GCS_ONLY(VM_TYPES_PARALLELGC(declare_type, \
161 declare_toplevel_type, \
162 declare_integer_type)) \
...because you would later like to do:
#ifdef INCLUDE_CMS
VM_TYPES_CMSGC(declare_type, \
declare_toplevel_type, \
integer_type)) \
#endif
#ifdef INCLUDE_G1
VM_TYPES_G1GC(declare_type, \
declare_toplevel_type, \
integer_type)) \
#endif
Thanks,
-Aleksey
From shade at redhat.com Thu Apr 5 11:08:54 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 5 Apr 2018 13:08:54 +0200
Subject: JEP 331: Low-Overhead Heap Profiling
In-Reply-To: <CAF9BGBz_167RNNsHVEzs1Q-eiyih5mzB3BrTt0_Vu67SQUuwVg@mail.gmail.com>
References: <20180329171223.64A4C1973B3@eggemoggin.niobe.net>
<cfb1b563-2702-a0b8-b122-da0e46b3b26f@redhat.com>
<CAF9BGBz_167RNNsHVEzs1Q-eiyih5mzB3BrTt0_Vu67SQUuwVg@mail.gmail.com>
Message-ID: <19dc905f-dbdd-ac8d-6092-1fe26e56cb24@redhat.com>
On 04/05/2018 12:23 AM, JC Beyler wrote:
> On Wed, Apr 4, 2018 at 3:41 AM Aleksey Shipilev <shade at redhat.com <mailto:shade at redhat.com>> wrote:
> *) It would be nice to mention the implementation details in the JEP itself, i.e. where are the
> points it injects into GCs to sample? I assume it has to inject into CollectedHeap::allocate_tlab,
> and it has to cap the max TLAB sizes to get into allocation slowpath often enough?
>
> My understanding was that a JEP was the idea and specification and that more technical information
> like that was out of scope for the JEP (implementations can change, etc.)
Well, yes. But if you have the implementation ideas, it is better to demonstrate them along with the
idea. Discussing implementation approaches serves several purposes: a) it empirically proves the
idea is implementable; b) it highlights tricky design decisions the implementation has to force,
which aids the understanding of the scope; c) it prevents handwaving against existing approaches :)
> It actually does not cap the max TLAB sizes, it changes the end pointer to force paths into
> "thinking" the tlab is full; then in the slowpath it samples and fixes things the pointers up for
> the next sample.
Ooof. So this has implications for JEP scope, and thus should be mentioned.
> *) Since JC apparently has the prototype, it would be easier to put it somewhere, and link it into
> the JEP itself. Webrevs are interesting, but they get outdated pretty quickly, so maybe putting the
> whole thing in JDK Sandbox [1] is the way to go.
>
> I've been keeping the webrevs up to date so there should be no real problem. From what I read, you
> have to be a commiter for the JDK Sandbox, no? So I'm not sure that would make sense there?
Right, you have to be a Committer. Link the webrev to the JEP then?
> *) Motivation says: "The downsides [of JFR] are that a) it is tied to a particular allocation
> implementation (TLABs), and misses allocations that don?t meet that pattern; b) it doesn?t allow the
> user to customize the sampling rate; c) it only logs allocations, so you cannot distinguish between
> live and dead objects."
>
> ?...but then JEP apparently describes sampling the allocations via TLABs? So, the real difference is
> (b), allowing to customize the sampling rate, or do I miss something?
>
> There are various differences between the JFR tlab events and this system. First the JFR system
> provides a buffer event system, meaning you can miss samples if the event buffer is full and threw
> out a sampling event before a reader got to it. Second, you don't get a callback at the allocation
> spot, so you cannot have a means to do an action at that sampling point, which means you have no way
> of knowing when an object is effectively dead using the JFR events. Hopefully that makes sense?
This paragraph should be in JEP text then?
>
> *) Goals say: "Can give information about both live and dead Java objects."
>
> ?...but there is not discussion what/how does it give information about the dead Java objects. I am
> struggling to imagine how allocation sampling would give this. Is the goal too broad, or some API is
> not described in the JEP?
>
> Originally the JEP provided a means to the user to get that information directly. Now because the
> sampling callback provides an oop, the user in the agent can add a weak reference and use that to
> determine liveness.
Ooof! I guess that technically works. Please mention it.
-Aleksey
From stefan.karlsson at oracle.com Thu Apr 5 11:47:57 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 5 Apr 2018 13:47:57 +0200
Subject: RFR: 8200759: Move GC entries in vmStructs.cpp to GC specific
files
In-Reply-To: <f9bdd388-f14d-4c7e-051b-19a0a8bf7ef6@redhat.com>
References: <8f9ef0fb-14b6-fca8-04ac-1ce49a3a11f0@oracle.com>
<f9bdd388-f14d-4c7e-051b-19a0a8bf7ef6@redhat.com>
Message-ID: <356436c3-574a-51be-a5e4-532b5e06bb28@oracle.com>
On 2018-04-05 13:00, Aleksey Shipilev wrote:
> On 04/04/2018 09:37 PM, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to move GC specific entries in vmStructs.cpp out to GC specific files.
>>
>> http://cr.openjdk.java.net/~stefank/8200759/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8200759
>
> *) It feels awkward to move JavaThread::_satb_mark_queue and JavaThread::_dirty_card_queue, to
> VM_STRUCTS_G1GC, since it is guarded by INCLUDE_ALL_GCS. VM_STRUCTS_GC seems more fitting. (Trivia:
> Shenandoah uses those things too, so they are "shared", even though the implementation is indeed in
> vm/gc/g1).
My follow-up changes change this to INCLUDE_G1GC, so in that sense this
I don't think it's that awkward.
However, if Shenandoah needs to use this then I agree that it needs to
be moved. I don't think it needs to be done for this change though.
>
> *) I'd do:
>
> #ifdef INCLUDE_ALL_GCS
> declare_constant_with_value("satbMarkQueueBufferOffset", ...
> declare_constant_with_value("satbMarkQueueIndexOffset", ...
> declare_constant_with_value("satbMarkQueueActiveOffset", ...
> #endif
>
> ...instead of:
>
> ALL_GCS_ONLY(declare_constant_with_value("satbMarkQueueBufferOffset", ...)
> ALL_GCS_ONLY(declare_constant_with_value("satbMarkQueueIndexOffset", ...)
> ALL_GCS_ONLY(declare_constant_with_value("satbMarkQueueActiveOffset", ...)
>
> It would be easier with multiple GCs wanting to have a piece of it. For example, it would be easier
> for Shenandoah to do:
>
> #ifdef (INCLUDE_G1 || INCLUDE_SHENANDOAH)
> declare_constant_with_value("satbMarkQueueBufferOffset", ...
> declare_constant_with_value("satbMarkQueueIndexOffset", ...
> declare_constant_with_value("satbMarkQueueActiveOffset", ...
> #endif
>
> In other words, ease off on ALL_GCS_ONLY macro, because it is not easily composable.
>
> Ditto for e.g.:
>
> 154 ALL_GCS_ONLY(VM_TYPES_CMSGC(declare_type, \
> 155 declare_toplevel_type, \
> 156 declare_integer_type)) \
> 157 ALL_GCS_ONLY(VM_TYPES_G1GC(declare_type, \
> 158 declare_toplevel_type, \
> 159 declare_integer_type)) \
> 160 ALL_GCS_ONLY(VM_TYPES_PARALLELGC(declare_type, \
> 161 declare_toplevel_type, \
> 162 declare_integer_type)) \
>
> ...because you would later like to do:
>
> #ifdef INCLUDE_CMS
> VM_TYPES_CMSGC(declare_type, \
> declare_toplevel_type, \
> integer_type)) \
> #endif
> #ifdef INCLUDE_G1
> VM_TYPES_G1GC(declare_type, \
> declare_toplevel_type, \
> integer_type)) \
> #endif
I can't really use your suggested constructs, because it won't compile.
StefanK
>
> Thanks,
> -Aleksey
>
From stefan.johansson at oracle.com Thu Apr 5 11:45:21 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Thu, 5 Apr 2018 13:45:21 +0200
Subject: RFR: 8201136: Move GC flags from globals.hpp to GC specific files
In-Reply-To: <97145397-ddba-b2ed-bdbe-b68e2d44b788@oracle.com>
References: <2acc1099-f7f9-d376-6e60-1c45775513b6@oracle.com>
<d94b1488-946e-8df0-0fbe-2a35d4c8bd19@oracle.com>
<97145397-ddba-b2ed-bdbe-b68e2d44b788@oracle.com>
Message-ID: <18eba187-da48-4cad-d096-e0f94dfebaae@oracle.com>
On 2018-04-05 11:46, Stefan Karlsson wrote:
> On 2018-04-05 11:42, Stefan Johansson wrote:
>>
>>
>> On 2018-04-05 08:11, Stefan Karlsson wrote:
>>> Hi all,
>>>
>>> Please review this patch to move GC flags out of globals.hpp and into
>>> GC specific files.
>>>
>>> ??http://cr.openjdk.java.net/~stefank/8201136/webrev.01
>>> ??https://bugs.openjdk.java.net/browse/JDK-8201136
>>>
>> Really nice! It would be even nicer with a few newlines in the
>> VM_FLAGS and GC_FLAGS macros, I think it would improve readability.
>>
>> I also used PrintFlagsFinal and checked that no flags were lost in the
>> move.
>
> Thanks StefanJ!
>
> Here are new webrevs with a cleanup patch proposed by StefanJ. Look at
> the patch to see the correct indentation.
>
> http://cr.openjdk.java.net/~stefank/8201136/webrev.02.delta
> http://cr.openjdk.java.net/~stefank/8201136/webrev.02
>
Look fantastic :)
StefanJ
> Thanks,
> StefanK
>
>>
>> Thanks,
>> Stefan
>>
>>> This is one step towards:
>>> ??https://bugs.openjdk.java.net/browse/JDK-8200729 - Conditional
>>> compilation of GCs
>>>
>>> With this patch we only have to update gc_globals.hpp when adding new
>>> GCs.
>>>
>>> Thanks,
>>> StefanK
From glaubitz at physik.fu-berlin.de Thu Apr 5 12:30:39 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Thu, 5 Apr 2018 14:30:39 +0200
Subject: Hotspot segfaulting on Linux SPARC
Message-ID: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
Hi!
Wasn't there recently a bug that caused crashes on Solaris SPARC and that
consequently fixed? I'm asking because I know Linux SPARC isn't officially
supported so it doesn't get as much love as Solaris SPARC and I am seeing
a crash that affects Linux SPARC only:
Creating support/interim-jmods/java.base.jmod
/bin/rm -f /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/support/interim-jmods/java.base.jmod /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/support/interim-jmods/temp/java.base.jmod
/srv/openjdk/hs/build/linux-sparcv9-normal-server-release/jdk/bin/jmod -J-XX:+UseSerialGC -J-Xms32M -J-Xmx512M -J-XX:TieredStopAtLevel=1 create \
--module-version 11-internal \
--target-platform 'linux-sparcv9' \
--module-path /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/support/interim-jmods \
--exclude '**{_the.*,_*.marker,*.diz,*.debuginfo,*.dSYM/**,*.dSYM,*.pdb,*.map}' \
--libs /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/support/modules_libs/java.base --cmds /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/support/modules_cmds/java.base --config /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/support/modules_conf/java.base --class-path /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/jdk/modules/java.base --header-files /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/support/modules_include/java.base --legal-notices "/srv/openjdk/hs/build/linux-sparcv9-normal-server-release/support/modules_legal/java.base:/srv/openjdk/hs/src/java.base/share/legal" /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/support/interim-jmods/temp/java.base.jmod
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xffff800108d99b48, pid=25458, tid=25459
#
# JRE version: OpenJDK Runtime Environment (11.0) (build 11-internal+0-adhoc.glaubitz.hs)
# Java VM: OpenJDK 64-Bit Server VM (11-internal+0-adhoc.glaubitz.hs, mixed mode, tiered, compressed oops, serial gc, linux-sparc)
# Problematic frame:
# J 278 c1 java.nio.file.Files$$Lambda$6.apply(Ljava/lang/Object;)Ljava/lang/Object; java.base (8 bytes) @ 0xffff800108d99b48 [0xffff800108d99aa0+0x00000000000000a8]
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /srv/openjdk/hs/make/hs_err_pid25458.log
Could not load hsdis-sparcv9.so; library not loadable; PrintAssembly is disabled
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
make[3]: *** [CreateJmods.gmk:137: /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/images/jmods/java.se.jmod] Aborted
make[3]: Leaving directory '/srv/openjdk/hs/make'
make[2]: *** [make/Main.gmk:309: java.se-jmod] Error 2
make[2]: *** Waiting for unfinished jobs....
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xffff800108d8f528, pid=25492, tid=25503
#
# JRE version: OpenJDK Runtime Environment (11.0) (build 11-internal+0-adhoc.glaubitz.hs)
# Java VM: OpenJDK 64-Bit Server VM (11-internal+0-adhoc.glaubitz.hs, mixed mode, tiered, compressed oops, serial gc, linux-sparc)
# Problematic frame:
# J 257 c1 sun.nio.fs.UnixFileAttributes$UnixAsBasicFileAttributes.isRegularFile()Z java.base (8 bytes) @ 0xffff800108d8f528 [0xffff800108d8f4a0+0x0000000000000088]
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /srv/openjdk/hs/make/hs_err_pid25492.log
Could not load hsdis-sparcv9.so; library not loadable; PrintAssembly is disabled
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
make[3]: *** [CreateJmods.gmk:137: /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/images/jmods/java.security.jgss.jmod] Aborted
make[3]: Leaving directory '/srv/openjdk/hs/make'
make[2]: *** [make/Main.gmk:309: java.security.jgss-jmod] Error 2
/bin/mv /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/support/jmods/java.scripting.jmod /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/images/jmods/java.scripting.jmod
make[3]: Leaving directory '/srv/openjdk/hs/make'
/bin/mv /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/support/jmods/java.rmi.jmod /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/images/jmods/java.rmi.jmod
make[3]: Leaving directory '/srv/openjdk/hs/make'
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xffff800108eca754, pid=25396, tid=25405
#
# JRE version: OpenJDK Runtime Environment (11.0) (build 11-internal+0-adhoc.glaubitz.hs)
# Java VM: OpenJDK 64-Bit Server VM (11-internal+0-adhoc.glaubitz.hs, mixed mode, tiered, compressed oops, serial gc, linux-sparc)
# Problematic frame:
# J 1080 c1 java.util.regex.Pattern$$Lambda$33.is(I)Z java.base (9 bytes) @ 0xffff800108eca754 [0xffff800108eca6a0+0x00000000000000b4]
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /srv/openjdk/hs/make/hs_err_pid25396.log
Compiled method (c1) 21949 1082 1 java.util.regex.Pattern$CharPropertyGreedy::match (122 bytes)
total in heap [0xffff800108ecae10,0xffff800108ecb4e8] = 1752
relocation [0xffff800108ecaf88,0xffff800108ecafe0] = 88
main code [0xffff800108ecafe0,0xffff800108ecb1e0] = 512
stub code [0xffff800108ecb1e0,0xffff800108ecb370] = 400
metadata [0xffff800108ecb370,0xffff800108ecb398] = 40
scopes data [0xffff800108ecb398,0xffff800108ecb440] = 168
scopes pcs [0xffff800108ecb440,0xffff800108ecb4d0] = 144
dependencies [0xffff800108ecb4d0,0xffff800108ecb4d8] = 8
nul chk table [0xffff800108ecb4d8,0xffff800108ecb4e8] = 16
Could not load hsdis-sparcv9.so; library not loadable; PrintAssembly is disabled
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
make[3]: *** [CreateJmods.gmk:137: /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/images/jmods/java.management.jmod] Aborted
make[3]: Leaving directory '/srv/openjdk/hs/make'
make[2]: *** [make/Main.gmk:309: java.management-jmod] Error 2
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xffff800108d41820, pid=25562, tid=25566
#
# JRE version: OpenJDK Runtime Environment (11.0) (build 11-internal+0-adhoc.glaubitz.hs)
# Java VM: OpenJDK 64-Bit Server VM (11-internal+0-adhoc.glaubitz.hs, mixed mode, tiered, compressed oops, serial gc, linux-sparc)
# Problematic frame:
# J 6 c1 java.lang.String.charAt(I)C java.base (25 bytes) @ 0xffff800108d41820 [0xffff800108d41760+0x00000000000000c0]
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /srv/openjdk/hs/make/hs_err_pid25562.log
Could not load hsdis-sparcv9.so; library not loadable; PrintAssembly is disabled
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
make[3]: *** [CreateJmods.gmk:137: /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/images/jmods/java.desktop.jmod] Aborted
make[3]: Leaving directory '/srv/openjdk/hs/make'
make[2]: *** [make/Main.gmk:309: java.desktop-jmod] Error 2
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xffff800108ecdd28, pid=25565, tid=25567
#
# JRE version: OpenJDK Runtime Environment (11.0) (build 11-internal+0-adhoc.glaubitz.hs)
# Java VM: OpenJDK 64-Bit Server VM (11-internal+0-adhoc.glaubitz.hs, mixed mode, tiered, compressed oops, serial gc, linux-sparc)
# Problematic frame:
# J 1090 c1 java.io.BufferedOutputStream.write(I)V java.base (35 bytes) @ 0xffff800108ecdd28 [0xffff800108ecdb40+0x00000000000001e8]
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /srv/openjdk/hs/make/hs_err_pid25565.log
Compiled method (c1) 23056 1255 1 java.util.zip.ZipOutputStream::writeEXT (73 bytes)
total in heap [0xffff800108f07810,0xffff800108f07e78] = 1640
relocation [0xffff800108f07988,0xffff800108f079f8] = 112
main code [0xffff800108f07a00,0xffff800108f07b40] = 320
stub code [0xffff800108f07b40,0xffff800108f07d58] = 536
metadata [0xffff800108f07d58,0xffff800108f07d98] = 64
scopes data [0xffff800108f07d98,0xffff800108f07dd0] = 56
scopes pcs [0xffff800108f07dd0,0xffff800108f07e60] = 144
dependencies [0xffff800108f07e60,0xffff800108f07e68] = 8
nul chk table [0xffff800108f07e68,0xffff800108f07e78] = 16
Could not load hsdis-sparcv9.so; library not loadable; PrintAssembly is disabled
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
make[3]: *** [CreateJmods.gmk:137: /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/support/interim-jmods/java.base.jmod] Aborted
make[3]: Leaving directory '/srv/openjdk/hs/make'
make[2]: *** [make/Main.gmk:447: java.base-interim-jmod] Error 2
make[2]: Leaving directory '/srv/openjdk/hs'
ERROR: Build failed for target 'images' in configuration 'linux-sparcv9-normal-server-release' (exit code 2)
make[2]: Entering directory '/srv/openjdk/hs'
[ -f /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/javacservers/server.port ] && /bin/echo Stopping sjavac server && /usr/bin/touch /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/javacservers/server.port.stop; true
/bin/date '+%Y %m %d %H %M %S' | /usr/bin/nawk '{ print $1,$2,$3,$4,$5,$6,($4*3600+$5*60+$6) }' > /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/build-times/build_time_end_TOTAL
/bin/date '+%Y-%m-%d %H:%M:%S' > /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/build-times/build_time_end_TOTAL_human_readable
/bin/echo `/bin/cat /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/build-times/build_time_start_TOTAL` `/bin/cat /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/build-times/build_time_end_TOTAL` TOTAL | /usr/bin/nawk '{ F=$7; T=$14; if (F > T) { T+=3600*24 }; D=T-F; H=int(D/3600); M=int((D-H*3600)/60); S=D-H*3600-M*60; printf("%02d:%02d:%02d %s\n",H,M,S,$15); }' > /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/build-times/build_time_diff_TOTAL
/usr/bin/printf -- "----- Build times -------\nStart %s\nEnd %s\n%s\n%s\n-------------------------\n" "`/bin/cat /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/build-times/build_time_start_TOTAL_human_readable`" "`/bin/cat /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/build-times/build_time_end_TOTAL_human_readable`" "`/bin/ls /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/build-times/build_time_diff_* | /bin/grep -v _TOTAL | /usr/bin/xargs /bin/cat | /usr/bin/sort -k 2`" "`/bin/cat /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/make-support/build-times/build_time_diff_TOTAL`" > >(/usr/bin/tee -a /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/build.log) 2> >(/usr/bin/tee -a /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/build.log >&2) && wait
----- Build times -------
Start 2018-04-05 12:17:02
End 2018-04-05 12:17:56
00:00:54 TOTAL
-------------------------
if /bin/grep -q "recipe for target .* failed" /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/build.log 2> /dev/null; then /usr/bin/printf "\n=== Make failed targets repeated here ===\n" ; /bin/grep "recipe for target .* failed" /srv/openjdk/hs/build/linux-sparcv9-normal-server-release/build.log ; /usr/bin/printf "=== End of repeated output ===\n" ; /usr/bin/printf "\nHint: Try searching the build log for the name of the first failed target.\n" ; else /usr/bin/printf "\nNo indication of failed target found.\n" ; /usr/bin/printf "Hint: Try searching the build log for '] Error'.\n" ; fi
No indication of failed target found.
Hint: Try searching the build log for '] Error'.
/usr/bin/printf "Hint: See doc/building.html#troubleshooting for assistance.\n\n"
Hint: See doc/building.html#troubleshooting for assistance.
make[2]: Leaving directory '/srv/openjdk/hs'
make[1]: *** [/srv/openjdk/hs/make/Init.gmk:296: main] Error 2
make[1]: Leaving directory '/srv/openjdk/hs'
make: *** [/srv/openjdk/hs/make/Init.gmk:186: images] Error 2
Backtrace is:
(gdb) bt
#0 0xffff80010063fb9c in __libc_signal_restore_set (set=0xffff80010195b168) at ../sysdeps/unix/sysv/linux/nptl-signals.h:80
#1 __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#2 0xffff800100641144 in __GI_abort () at abort.c:79
#3 0xffff8001011ae030 in os::abort (dump_core=<optimized out>, siginfo=0xffff80010195c7a0, context=0xffff80010195c7a0) at /srv/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:1423
#4 0xffff8001013be518 in VMError::report_and_die (id=id at entry=4, message=message at entry=0x0, detail_fmt=detail_fmt at entry=0xffff8001014708a8 "%s", detail_args=detail_args at entry=0xffff80010195b790, thread=thread at entry=0x0,
pc=pc at entry=0x6bfd000003e8 <error: Cannot access memory at address 0x6bfd000003e8>, siginfo=0xffff80010195b990, context=0xffff80010195b990, filename=0x0, lineno=0, size=0)
at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1504
#5 0xffff8001013bef68 in VMError::report_and_die (thread=thread at entry=0x0, sig=sig at entry=4, pc=pc at entry=0x6bfd000003e8 <error: Cannot access memory at address 0x6bfd000003e8>, siginfo=siginfo at entry=0xffff80010195b990,
context=context at entry=0xffff80010195b990, detail_fmt=0xffff8001014708a8 "%s") at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1219
#6 0xffff8001013befb4 in VMError::report_and_die (thread=thread at entry=0x0, sig=sig at entry=4, pc=0x6bfd000003e8 <error: Cannot access memory at address 0x6bfd000003e8>, siginfo=siginfo at entry=0xffff80010195b990,
context=context at entry=0xffff80010195b990) at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1225
#7 0xffff8001013bf330 in crash_handler (sig=<optimized out>, info=0xffff80010195b990, ucVoid=0xffff80010195b990) at /srv/openjdk/hs/src/hotspot/os/posix/vmError_posix.cpp:140
#8 <signal handler called>
#9 arrayOopDesc::length_offset_in_bytes () at /srv/openjdk/hs/src/hotspot/share/oops/arrayOop.hpp:78
#10 arrayOopDesc::length (this=0x7a030ce80) at /srv/openjdk/hs/src/hotspot/share/oops/arrayOop.hpp:97
#11 oopDesc::size_given_klass (klass=0x7aaac4e38, this=0x7a030ce80) at /srv/openjdk/hs/src/hotspot/share/oops/oop.inline.hpp:191
#12 oopDesc::size (this=0x7a030ce80) at /srv/openjdk/hs/src/hotspot/share/oops/oop.inline.hpp:160
#13 ContiguousSpace::block_start_const (this=0xffff8001040181a0, p=0x7a05c3100) at /srv/openjdk/hs/src/hotspot/share/gc/shared/space.cpp:585
#14 0xffff800100e52614 in Space::block_start (p=<optimized out>, this=0xffff8001040181a0) at /srv/openjdk/hs/src/hotspot/share/gc/shared/space.inline.hpp:39
#15 GenerationBlockStartClosure::do_space (this=0xffff80010195bec8, s=0xffff8001040181a0) at /srv/openjdk/hs/src/hotspot/share/gc/shared/generation.cpp:202
#16 0xffff800100d0ac38 in DefNewGeneration::space_iterate (this=0xffff800104017630, blk=0xffff80010195bec8, usedOnly=<optimized out>) at /srv/openjdk/hs/src/hotspot/share/gc/serial/defNewGeneration.cpp:521
#17 0xffff800100e51b04 in Generation::block_start (this=0xffff800104017630, p=0x7a05c3100) at /srv/openjdk/hs/src/hotspot/share/gc/shared/generation.cpp:211
#18 0xffff800100e2a1dc in GenCollectedHeap::block_start (this=0xffff800104016b80, addr=0x7a05c3100) at /srv/openjdk/hs/src/hotspot/share/gc/shared/genCollectedHeap.cpp:1083
#19 0xffff8001011a5ad0 in os::print_location (st=st at entry=0xffff800101670758 <VMError::log>, x=32755167488, verbose=verbose at entry=false) at /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:1071
#20 0xffff8001011b9030 in os::print_register_info (st=st at entry=0xffff800101670758 <VMError::log>, context=0xffff80010195c7a0) at /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp:263
#21 0xffff8001013bd590 in VMError::report (st=st at entry=0xffff800101670758 <VMError::log>, _verbose=_verbose at entry=true) at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:748
#22 0xffff8001013be5cc in VMError::report_and_die (id=id at entry=11, message=message at entry=0x0, detail_fmt=detail_fmt at entry=0xffff8001014708a8 "%s", detail_args=detail_args at entry=0xffff80010195c4f0,
thread=thread at entry=0xffff800104011000, pc=pc at entry=0xffff800108d502c8 "\300\\ ", siginfo=0xffff80010195c7a0, context=0xffff80010195c7a0, filename=0x0, lineno=0, size=0)
at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1405
#23 0xffff8001013bef68 in VMError::report_and_die (thread=thread at entry=0xffff800104011000, sig=sig at entry=11, pc=pc at entry=0xffff800108d502c8 "\300\\ ", siginfo=siginfo at entry=0xffff80010195c7a0, context=context at entry=0xffff80010195c7a0,
detail_fmt=0xffff8001014708a8 "%s") at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1219
#24 0xffff8001013befb4 in VMError::report_and_die (thread=thread at entry=0xffff800104011000, sig=sig at entry=11, pc=pc at entry=0xffff800108d502c8 "\300\\ ", siginfo=siginfo at entry=0xffff80010195c7a0, context=context at entry=0xffff80010195c7a0)
at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1225
#25 0xffff8001011b9764 in JVM_handle_linux_signal (sig=sig at entry=11, info=info at entry=0xffff80010195c7a0, ucVoid=ucVoid at entry=0xffff80010195c7a0, abort_if_unrecognized=abort_if_unrecognized at entry=1)
at /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp:646
#26 0xffff8001011ac80c in signalHandler (sig=<optimized out>, info=0xffff80010195c7a0, uc=0xffff80010195c7a0) at /srv/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:4396
#27 <signal handler called>
#28 0xffff800108d502c8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From stewartd.qdt at qualcommdatacenter.com Thu Apr 5 12:41:33 2018
From: stewartd.qdt at qualcommdatacenter.com (stewartd.qdt)
Date: Thu, 5 Apr 2018 12:41:33 +0000
Subject: RFR: 8200524 - AArch64: CPUFeature and Flag enums are not passed
through JVMCI
In-Reply-To: <CACc5Y6Tx8-UAVhrziJPbB83U=zBDs=d5A1rESdMCxCeJh3xa7A@mail.gmail.com>
References: <98b24cb083e34d6fa465a17bc9b81acd@NASANEXM01E.na.qualcomm.com>
<7dc80da1-3a55-717c-eb90-676d191c8c08@oracle.com>
<09892b14336d47469db1554c69db9aa8@NASANEXM01E.na.qualcomm.com>
<17dc271bed3d4cb1b2c816680aeabbaa@NASANEXM01E.na.qualcomm.com>
<CACc5Y6Tx8-UAVhrziJPbB83U=zBDs=d5A1rESdMCxCeJh3xa7A@mail.gmail.com>
Message-ID: <061ad60f3850458e9a4fc2090923f897@NASANEXM01E.na.qualcomm.com>
Thanks Felix!
From: Felix Yang [mailto:felix.yang at linaro.org]
Sent: Wednesday, April 4, 2018 9:34 PM
To: stewartd.qdt <stewartd.qdt at qualcommdatacenter.com>
Cc: hotspot-dev at openjdk.java.net
Subject: Re: RFR: 8200524 - AArch64: CPUFeature and Flag enums are not passed through JVMCI
That looks good to me (not an official reviewer).
There are some trailing spaces in your original patch, I have modified and pushed: http://hg.openjdk.java.net/jdk/hs/rev/46b2f783116c
Make sure you have jcheck enabled next time. Reference: http://openjdk.java.net/projects/code-tools/jcheck/
Thanks,
Felix
On 31 March 2018 at 01:48, stewartd.qdt <stewartd.qdt at qualcommdatacenter.com<mailto:stewartd.qdt at qualcommdatacenter.com>> wrote:
Might I get a sponsor for this change?
http://cr.openjdk.java.net/~dstewart/8200524/webrev.01/
Thank you,
Daniel
-----Original Message-----
From: stewartd.qdt
Sent: Friday, March 30, 2018 12:12 PM
To: Vladimir Kozlov <vladimir.kozlov at oracle.com<mailto:vladimir.kozlov at oracle.com>>; stewartd.qdt <stewartd.qdt at qualcommdatacenter.com<mailto:stewartd.qdt at qualcommdatacenter.com>>; hotspot-dev at openjdk.java.net<mailto:hotspot-dev at openjdk.java.net>
Subject: RE: RFR: 8200524 - AArch64: CPUFeature and Flag enums are not passed through JVMCI
Thanks, Vladimir.
-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com<mailto:vladimir.kozlov at oracle.com>]
Sent: Friday, March 30, 2018 12:10 PM
To: stewartd.qdt <stewartd.qdt at qualcommdatacenter.com<mailto:stewartd.qdt at qualcommdatacenter.com>>; hotspot-dev at openjdk.java.net<mailto:hotspot-dev at openjdk.java.net>
Subject: Re: RFR: 8200524 - AArch64: CPUFeature and Flag enums are not passed through JVMCI
Changes looks good to me. They follow the same code pattern as on other architectures.
Thanks,
Vladimir
On 3/30/18 8:35 AM, stewartd.qdt wrote:
> Please review this webrev [1] which implements the transfer of AArch64::CPUFeature flags and AArch64::Flag enums over the JVMCI interface.
>
> This patch sets the CPUFeature enums corresponding to which VM_Version flags are set. It also sets the Flag enums corresponding to which use flags have been set on the command line. This mirrors what is done for AMD64.
>
> The bug report is filed at [2].
>
> I am happy to modify the patch as necessary.
>
> Regards,
> Daniel Stewart
>
> [1] - http://cr.openjdk.java.net/~dstewart/8200524/webrev.00/
> [2] - https://bugs.openjdk.java.net/browse/JDK-8200524
>
From shade at redhat.com Thu Apr 5 15:09:18 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 5 Apr 2018 17:09:18 +0200
Subject: RFR: 8200759: Move GC entries in vmStructs.cpp to GC specific
files
In-Reply-To: <356436c3-574a-51be-a5e4-532b5e06bb28@oracle.com>
References: <8f9ef0fb-14b6-fca8-04ac-1ce49a3a11f0@oracle.com>
<f9bdd388-f14d-4c7e-051b-19a0a8bf7ef6@redhat.com>
<356436c3-574a-51be-a5e4-532b5e06bb28@oracle.com>
Message-ID: <008bf5c3-1d86-2d81-0ba4-fd276d9a3088@redhat.com>
On 04/05/2018 01:47 PM, Stefan Karlsson wrote:
>> *) It feels awkward to move JavaThread::_satb_mark_queue and JavaThread::_dirty_card_queue, to
>> VM_STRUCTS_G1GC, since it is guarded by INCLUDE_ALL_GCS. VM_STRUCTS_GC seems more fitting. (Trivia:
>> Shenandoah uses those things too, so they are "shared", even though the implementation is indeed in
>> vm/gc/g1).
>
> My follow-up changes change this to INCLUDE_G1GC, so in that sense this I don't think it's that
> awkward.
>
> However, if Shenandoah needs to use this then I agree that it needs to be moved. I don't think it
> needs to be done for this change though.
Yeah, it would probably move under JDK-8154343 later.
>> #ifdef INCLUDE_CMS
>> ??? VM_TYPES_CMSGC(declare_type,??????????????????????? \
>> ?????????????????? declare_toplevel_type,?????????????? \
>> ?????????????????? integer_type))?????????????????????? \
>> #endif
>> #ifdef INCLUDE_G1
>> ??? VM_TYPES_G1GC(declare_type,??????????????????????? \
>> ?????????????????? declare_toplevel_type,????????????? \
>> ?????????????????? integer_type))????????????????????? \
>> #endif
>
> I can't really use your suggested constructs, because it won't compile.
Ah, because ifdef is inside the macro. Nevermind.
-Aleksey
From shade at redhat.com Thu Apr 5 15:43:04 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 5 Apr 2018 17:43:04 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
Message-ID: <11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
On 04/05/2018 02:30 PM, John Paul Adrian Glaubitz wrote:
> # Problematic frame:
> # J 278 c1 java.nio.file.Files$$Lambda$6.apply(Ljava/lang/Object;)Ljava/lang/Object; java.base (8
> bytes) @ 0xffff800108d99b48 [0xffff800108d99aa0+0x00000000000000a8]
This looks like a compiler/GC bug. Try building fastdebug, maybe it shall assert meaningfully? Also,
si_addr is probably meaningful.
> #7? 0xffff8001013bf330 in crash_handler (sig=<optimized out>, info=0xffff80010195b990,
> ucVoid=0xffff80010195b990) at /srv/openjdk/hs/src/hotspot/os/posix/vmError_posix.cpp:140
> #8? <signal handler called>
> #9? arrayOopDesc::length_offset_in_bytes () at /srv/openjdk/hs/src/hotspot/share/oops/arrayOop.hpp:78
> #10 arrayOopDesc::length (this=0x7a030ce80) at /srv/openjdk/hs/src/hotspot/share/oops/arrayOop.hpp:97
> #11 oopDesc::size_given_klass (klass=0x7aaac4e38, this=0x7a030ce80) at
> /srv/openjdk/hs/src/hotspot/share/oops/oop.inline.hpp:191
> #12 oopDesc::size (this=0x7a030ce80) at /srv/openjdk/hs/src/hotspot/share/oops/oop.inline.hpp:160
> #13 ContiguousSpace::block_start_const (this=0xffff8001040181a0, p=0x7a05c3100) at
> /srv/openjdk/hs/src/hotspot/share/gc/shared/space.cpp:585
> #14 0xffff800100e52614 in Space::block_start (p=<optimized out>, this=0xffff8001040181a0) at
> /srv/openjdk/hs/src/hotspot/share/gc/shared/space.inline.hpp:39
> #15 GenerationBlockStartClosure::do_space (this=0xffff80010195bec8, s=0xffff8001040181a0) at
> /srv/openjdk/hs/src/hotspot/share/gc/shared/generation.cpp:202
> #16 0xffff800100d0ac38 in DefNewGeneration::space_iterate (this=0xffff800104017630,
> blk=0xffff80010195bec8, usedOnly=<optimized out>) at
> /srv/openjdk/hs/src/hotspot/share/gc/serial/defNewGeneration.cpp:521
> #17 0xffff800100e51b04 in Generation::block_start (this=0xffff800104017630, p=0x7a05c3100) at
> /srv/openjdk/hs/src/hotspot/share/gc/shared/generation.cpp:211
> #18 0xffff800100e2a1dc in GenCollectedHeap::block_start (this=0xffff800104016b80, addr=0x7a05c3100)
> at /srv/openjdk/hs/src/hotspot/share/gc/shared/genCollectedHeap.cpp:1083
> #19 0xffff8001011a5ad0 in os::print_location (st=st at entry=0xffff800101670758 <VMError::log>,
> x=32755167488, verbose=verbose at entry=false) at /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:1071
> #20 0xffff8001011b9030 in os::print_register_info (st=st at entry=0xffff800101670758 <VMError::log>,
> context=0xffff80010195c7a0) at /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp:263
> #21 0xffff8001013bd590 in VMError::report (st=st at entry=0xffff800101670758 <VMError::log>,
> _verbose=_verbose at entry=true) at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:748
> #22 0xffff8001013be5cc in VMError::report_and_die (id=id at entry=11, message=message at entry=0x0,
> detail_fmt=detail_fmt at entry=0xffff8001014708a8 "%s", detail_args=detail_args at entry=0xffff80010195c4f0,
This is suspicious, because it looks like the double-fault during reporting the original error.
Looks as if the arrayOop at 0x7a030ce80 is bad -- and maybe that is the reason why C1-compiled Java
code failed?
-Aleksey
From glaubitz at physik.fu-berlin.de Thu Apr 5 15:49:05 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Thu, 5 Apr 2018 17:49:05 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
Message-ID: <087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
On 04/05/2018 05:43 PM, Aleksey Shipilev wrote:
> On 04/05/2018 02:30 PM, John Paul Adrian Glaubitz wrote:
>> # Problematic frame:
>> # J 278 c1 java.nio.file.Files$$Lambda$6.apply(Ljava/lang/Object;)Ljava/lang/Object; java.base (8
>> bytes) @ 0xffff800108d99b48 [0xffff800108d99aa0+0x00000000000000a8]
>
> This looks like a compiler/GC bug. Try building fastdebug, maybe it shall assert meaningfully? Also,
> si_addr is probably meaningful.
Right, I somehow completely forgot to enable debugging. Will rebuild with fastdebug.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From jcbeyler at google.com Thu Apr 5 16:01:45 2018
From: jcbeyler at google.com (JC Beyler)
Date: Thu, 05 Apr 2018 16:01:45 +0000
Subject: RFR(S): 8200720: Print accumulated number of allocated bytes in
thread dump
In-Reply-To: <171FA571-AFEC-4E88-B681-D10F8DFD1639@sap.com>
References: <171FA571-AFEC-4E88-B681-D10F8DFD1639@sap.com>
Message-ID: <CAF9BGBx1fixaHdb-edT+BXu-YnFMo-UpuYg43jXuifNL00L0Aw@mail.gmail.com>
Hi Gunter,
I really am new to the Java scene so I really am not speaking about the
implementation and its potential integration into the code. Or even would
the feature be accepted or not, however, from what I've seen in the webrev
you provided:
- In theory, adding to Thread is not really accepted and a side structure
is better, perhaps we could piggy back on the same structure, since I'm
trying to add one called ThreadHeapSampler, we could rename it to
ThreadHeapInformation and both use that (see
http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.10/src/hotspot/share/runtime/threadHeapSampler.cpp.html)
in order to not have different structures provide similar information
topics.
- bytes_in_tlab should be words_in_tlab if I'm not mistaken
- seems like you are missing allocations that do not fit in the TLAB due
to too big, no?
On another note, depending on what your users want, this might not be
relevant:
We actually implemented a similar approach but it was on top of the
sampling technique I'm pushing currently. It provides the same information
you do but also the bytes allocated still live for a given thread due to
how our internal system is implemented (because our users preferred to know
how much a thread was holding instead of how much a thread allocated). With
the work I'm doing here (via JDK-8171119), it might be reasonable and
do-able to have the sampling system provide this information on the native
agent side (and thus you can do your implementation and provide the data to
your users without this change). Would this perhaps be of interest to you?
We could build an example test and you can test it on your side and I can
test it on mine and we can see how far off either technique is in regards
to the information about per thread allocation?
I have not done the overhead calculation of this in a long time, we could
wrap that together and see if that's acceptable. I'm not sure you get a 0%
as you do but it would be small.
Thanks,
Jc
On Thu, Apr 5, 2018 at 3:28 AM Haug, Gunter <gunter.haug at sap.com> wrote:
> Hi,
>
> can I please have a review and a sponsor for the following enhancement:
>
> http://cr.openjdk.java.net/~ghaug/webrevs/8200720
> https://bugs.openjdk.java.net/browse/JDK-8200720
>
> We at SAP have extended the thread dumps (obtained by jstack or jcmd) by
> several fields providing thread specific information. These extensions are
> quite popular with our support team. With some knowledge of the
> architecture of the application, they often allow for quick and simple
> diagnosis of a running system. Therefore we would like to contribute these
> enhancements.
>
> I took the quite simple accumulated number of bytes allocated by a thread
> as an example. This only works with TLAB active. Provided it is known how
> the application should behave, a misbehaving thread can identified easily.
>
> There is no measurable overhead for this enhancement. However, it may be a
> problem that the format of the output is changed. Tools parsing the output
> may have to be changed.
>
> Here is an example of the output generated:
>
> ---------------------------------------------------------
> "main" #1 prio=5 os_prio=31 allocated=243048448B tid=0x00007fca98000800
> nid=0x1d03 waiting on condition [0x0000000109baa000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(java.base/Native Method)
> ...
> ---------------------------------------------------------
>
> As mentioned above, we have a whole bunch of other enhancements to the
> thread dump similar to this one and would be willing to contribute them if
> there is any interest.
>
> Thanks and best regards,
> Gunter
>
>
From jcbeyler at google.com Thu Apr 5 16:05:22 2018
From: jcbeyler at google.com (JC Beyler)
Date: Thu, 05 Apr 2018 16:05:22 +0000
Subject: JEP 331: Low-Overhead Heap Profiling
In-Reply-To: <19dc905f-dbdd-ac8d-6092-1fe26e56cb24@redhat.com>
References: <20180329171223.64A4C1973B3@eggemoggin.niobe.net>
<cfb1b563-2702-a0b8-b122-da0e46b3b26f@redhat.com>
<CAF9BGBz_167RNNsHVEzs1Q-eiyih5mzB3BrTt0_Vu67SQUuwVg@mail.gmail.com>
<19dc905f-dbdd-ac8d-6092-1fe26e56cb24@redhat.com>
Message-ID: <CAF9BGByMimzf94oZJ7S1Xxw8-yOc7yuHP-+xnESFrhGXK5ReZQ@mail.gmail.com>
Hi Aleksey,
I inlined my answers :)
On Thu, Apr 5, 2018 at 4:09 AM Aleksey Shipilev <shade at redhat.com> wrote:
> On 04/05/2018 12:23 AM, JC Beyler wrote:
> > On Wed, Apr 4, 2018 at 3:41 AM Aleksey Shipilev <shade at redhat.com
> <mailto:shade at redhat.com>> wrote:
> > *) It would be nice to mention the implementation details in the JEP
> itself, i.e. where are the
> > points it injects into GCs to sample? I assume it has to inject into
> CollectedHeap::allocate_tlab,
> > and it has to cap the max TLAB sizes to get into allocation slowpath
> often enough?
> >
> > My understanding was that a JEP was the idea and specification and that
> more technical information
> > like that was out of scope for the JEP (implementations can change, etc.)
>
> Well, yes. But if you have the implementation ideas, it is better to
> demonstrate them along with the
> idea. Discussing implementation approaches serves several purposes: a) it
> empirically proves the
> idea is implementable; b) it highlights tricky design decisions the
> implementation has to force,
> which aids the understanding of the scope; c) it prevents handwaving
> against existing approaches :)
>
Fair enough, I've added an implementation design/state with a link to the
current webrev at the end of the JEP issue
<https://bugs.openjdk.java.net/browse/JDK-8171119>. Let me know if that is
what you had in mind.
>
> > It actually does not cap the max TLAB sizes, it changes the end pointer
> to force paths into
> > "thinking" the tlab is full; then in the slowpath it samples and fixes
> things the pointers up for
> > the next sample.
>
> Ooof. So this has implications for JEP scope, and thus should be mentioned.
>
Perhaps, again I saw the JEP as a different level of abstraction and this
is more in the details of implementation. However, I have added a full
explanation of this into the JEP at the end, let me know if it makes sense.
For convenience, let me copy-paste what I wrote there:
"
2) The TLAB structure is augmented with a new allocation_end pointer and a
current_end pointer. If the sampling is disabled, the two pointers are
always equal and the code performs as before. If the sampling is enabled,
the current_end is modified to be where the next sample point is requested.
Then, any fast path will "think" the TLAB is full at that point and go down
the slow path, which is explained in (3)
"
>
>
> > *) Since JC apparently has the prototype, it would be easier to put
> it somewhere, and link it into
> > the JEP itself. Webrevs are interesting, but they get outdated
> pretty quickly, so maybe putting the
> > whole thing in JDK Sandbox [1] is the way to go.
> >
> > I've been keeping the webrevs up to date so there should be no real
> problem. From what I read, you
> > have to be a commiter for the JDK Sandbox, no? So I'm not sure that
> would make sense there?
>
> Right, you have to be a Committer. Link the webrev to the JEP then?
>
I added the link and a few paragraphs on the implementation.
>
>
> > *) Motivation says: "The downsides [of JFR] are that a) it is tied
> to a particular allocation
> > implementation (TLABs), and misses allocations that don?t meet that
> pattern; b) it doesn?t allow the
> > user to customize the sampling rate; c) it only logs allocations, so
> you cannot distinguish between
> > live and dead objects."
> >
> > ...but then JEP apparently describes sampling the allocations via
> TLABs? So, the real difference is
> > (b), allowing to customize the sampling rate, or do I miss something?
> >
> > There are various differences between the JFR tlab events and this
> system. First the JFR system
> > provides a buffer event system, meaning you can miss samples if the
> event buffer is full and threw
> > out a sampling event before a reader got to it. Second, you don't get a
> callback at the allocation
> > spot, so you cannot have a means to do an action at that sampling point,
> which means you have no way
> > of knowing when an object is effectively dead using the JFR events.
> Hopefully that makes sense?
>
> This paragraph should be in JEP text then?
>
Done, I revamped and edited the section into this now:
"There are multiple alternatives to the system presented in this JEP. The
introduction presented two already: The Java Flight Recorder
<http://openjdk.java.net/jeps/328> system provides an interesting
alternative but is not perfect due to it not allowing the sampling size to
be set and not providing a callback.
The JFR system does use the TLAB creation as a means to track memory
allocation but, instead of a callback, JFR events use a buffer system that
can lead to missing some sampled allocations. Finally, the JFR event system
does not provide a means to track objects that have been garbage collected,
which means it is not possible currently to have a system provide
information about live and garbage collected objects using the JFR event
system."
Let me know if that works for you.
>
> >
> > *) Goals say: "Can give information about both live and dead Java
> objects."
> >
> > ...but there is not discussion what/how does it give information
> about the dead Java objects. I am
> > struggling to imagine how allocation sampling would give this. Is
> the goal too broad, or some API is
> > not described in the JEP?
> >
> > Originally the JEP provided a means to the user to get that information
> directly. Now because the
> > sampling callback provides an oop, the user in the agent can add a weak
> reference and use that to
> > determine liveness.
> Ooof! I guess that technically works. Please mention it.
>
I did already add it here:
"E) What the Java agent can do
The user of the callback can then pick up a stacktrace at the moment of the
callback using the JVMTI GetStackTrace method for example. The oop obtained
by the callback can be also wrapped into a JNI weak reference to help
determine when the object has been garbage collected. The idea behind that
is to provide data on what objects were sampled and are still considered
live or garbage collected, which can be a good means to understand the
job's behavior.
The sampling rate will provide a different sampling precision but also can
be a means to mitigate overhead due to the profiling. Using a sampling rate
of 512k and the sampling solution, the overhead should be low enough that a
user could reasonably leave the system on by default."
------
I also have the proof of concept in tests here
<http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.10/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorGCTest.java.html>
and
the native implementation is here
<http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.10/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/libHeapMonitorTest.c.html>
.
Let me know if my additions to the JEP are what you were looking for and is
there anything else you think I should add information about!
Thanks for reviewing it!
Jc
From gerard.ziemski at oracle.com Thu Apr 5 17:46:25 2018
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Thu, 5 Apr 2018 12:46:25 -0500
Subject: RFR (XL) 8081519 Split globals.hpp to factor out the Flag class
In-Reply-To: <D6E4A4E8-8356-4694-BD9C-03AB5FA5BC65@oracle.com>
References: <D6E4A4E8-8356-4694-BD9C-03AB5FA5BC65@oracle.com>
Message-ID: <6656E162-56BE-4E75-8343-7567715F30C7@oracle.com>
Hi all,
Here is webrev 2 with the following additions:
#1 Factor FlagSetting class out of "runtime/flags/jvmFlag.hpp" and into its own "runtime/flags/flagSetting.hpp", so that FlagSetting class can extend from ?public StackObj? (thanks Coleen)
#2 change the hierarchy from ?runtime/jvmFlag/? to "runtime/flags/? (thanks David)
#3 Fix the header files, so that both closed and open repository build with and without precompiled headers
#4 Add ?runtime/flags/*.hpp? headers to ?precompiled.hpp?
The number of touched files got even longer - sorry about that and big thank you for taking your time to review!
Running final Mach5 hs_tier1-5 tests? (it passed earlier iterations). Passes local builds (on Mac OS X) with and without precompiled headers for both closed and open repos and both debug and product versions (should I try any other build varations?)
http://cr.openjdk.java.net/~gziemski/8081519_rev2
cheers
> On Mar 29, 2018, at 2:01 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
>
> Hi all,
>
> Please review this large and tedious (sorry), but simple fix that accomplishes the following:
>
> #1 factor out the command option flag related APIs out of globals.hpp/.cpp into its own dedicated files, i.e. jvmFlag.hpp/.cpp
> #2 merge Flag (too generic name) and CommandLineFlag classes and rename them as JVMFlag
> #3 cleanup globals.hpp includes originally added by the JEP-245
>
> Note: the renamed file retain their history, but one needs to add ?follow? flag, ex. ?hg log -f file?
>
> https://bugs.openjdk.java.net/browse/JDK-8081519
> http://cr.openjdk.java.net/~gziemski/8081519_rev1
>
> Passes Mach5 hs_tier1-tier5, jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges tests.
>
>
> cheers
From vladimir.kozlov at oracle.com Thu Apr 5 18:08:57 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 5 Apr 2018 11:08:57 -0700
Subject: RFC: C2 Object Initialization - Using XMM/YMM registers
In-Reply-To: <CAPVMLfVcpTXpaTeMwo0Gg=NgDpkz+Z2cD+FP7mw6iHJH5R-+nw@mail.gmail.com>
References: <CAPVMLfVcpTXpaTeMwo0Gg=NgDpkz+Z2cD+FP7mw6iHJH5R-+nw@mail.gmail.com>
Message-ID: <f21029be-c4a7-8104-6d4b-e6bbd13525b9@oracle.com>
Good suggestion, Rohit
I created new RFE. Please add you suggestion and performance data there:
https://bugs.openjdk.java.net/browse/JDK-8201193
Thanks,
Vladimir
On 4/5/18 12:19 AM, Rohit Arul Raj wrote:
> Hi All,
>
> I was going through the C2 object initialization (zeroing) code based
> on the below bug entry:
> https://bugs.openjdk.java.net/browse/JDK-8146801
>
> Right now, for longer lengths we use "rep stos" instructions on x86. I
> was experimenting with using XMM/YMM registers (on AMD EPYC processor)
> and found that they do improve performance for certain lengths:
>
> For lengths > 64 bytes - 512 bytes : improvement is in the range of 8% to 44%
> For lengths > 512bytes : some lengths show slight
> improvement in the range of 2% to 7%, others almost same as "rep stos"
> numbers.
>
> I have attached the complete performance data (data.txt) for reference .
> Can we add this as an user option similar to UseXMMForArrayCopy?
>
> I have used the same test case as in
> (http://cr.openjdk.java.net/~shade/8146801/benchmarks.jar) with
> additional sizes.
>
> Initial Patch:
> I haven't added the check for 32-bit mode as I need some help with the
> code (description given below the patch).
> The code is similar to the one used in array copy stubs (copy_bytes_forward).
>
> diff --git a/src/hotspot/cpu/x86/globals_x86.hpp
> b/src/hotspot/cpu/x86/globals_x86.hpp
> --- a/src/hotspot/cpu/x86/globals_x86.hpp
> +++ b/src/hotspot/cpu/x86/globals_x86.hpp
> @@ -150,6 +150,9 @@
> product(bool, UseUnalignedLoadStores, false, \
> "Use SSE2 MOVDQU instruction for Arraycopy") \
> \
> + product(bool, UseXMMForObjInit, false, \
> + "Use XMM/YMM MOVDQU instruction for Object Initialization") \
> + \
> product(bool, UseFastStosb, false, \
> "Use fast-string operation for zeroing: rep stosb") \
> \
> diff --git a/src/hotspot/cpu/x86/macroAssembler_x86.cpp
> b/src/hotspot/cpu/x86/macroAssembler_x86.cpp
> --- a/src/hotspot/cpu/x86/macroAssembler_x86.cpp
> +++ b/src/hotspot/cpu/x86/macroAssembler_x86.cpp
> @@ -7106,6 +7106,56 @@
> if (UseFastStosb) {
> shlptr(cnt, 3); // convert to number of bytes
> rep_stosb();
> + } else if (UseXMMForObjInit && UseUnalignedLoadStores) {
> + Label L_loop, L_sloop, L_check, L_tail, L_end;
> + push(base);
> + if (UseAVX >= 2)
> + vpxor(xmm10, xmm10, xmm10, AVX_256bit);
> + else
> + vpxor(xmm10, xmm10, xmm10, AVX_128bit);
> +
> + jmp(L_check);
> +
> + BIND(L_loop);
> + if (UseAVX >= 2) {
> + vmovdqu(Address(base, 0), xmm10);
> + vmovdqu(Address(base, 32), xmm10);
> + } else {
> + movdqu(Address(base, 0), xmm10);
> + movdqu(Address(base, 16), xmm10);
> + movdqu(Address(base, 32), xmm10);
> + movdqu(Address(base, 48), xmm10);
> + }
> + addptr(base, 64);
> +
> + BIND(L_check);
> + subptr(cnt, 8);
> + jccb(Assembler::greaterEqual, L_loop);
> + addptr(cnt, 4);
> + jccb(Assembler::less, L_tail);
> + // Copy trailing 32 bytes
> + if (UseAVX >= 2) {
> + vmovdqu(Address(base, 0), xmm10);
> + } else {
> + movdqu(Address(base, 0), xmm10);
> + movdqu(Address(base, 16), xmm10);
> + }
> + addptr(base, 32);
> + subptr(cnt, 4);
> +
> + BIND(L_tail);
> + addptr(cnt, 4);
> + jccb(Assembler::lessEqual, L_end);
> + decrement(cnt);
> +
> + BIND(L_sloop);
> + movptr(Address(base, 0), tmp);
> + addptr(base, 8);
> + decrement(cnt);
> + jccb(Assembler::greaterEqual, L_sloop);
> +
> + BIND(L_end);
> + pop(base);
> } else {
> NOT_LP64(shlptr(cnt, 1);) // convert to number of 32-bit words
> for 32-bit VM
> rep_stos();
>
>
> When I use XMM0 as a temporary register, the micro-benchmark crashes.
> Saving and Restoring the XMM0 register before and after use works
> fine.
>
> Looking at the "hotspot/src/cpu/x86/vm/x86.ad" file, XMM0 as with
> other XMM registers has been mentioned as Save-On-Call registers and
> on Linux ABI, no register is preserved across function calls though
> XMM0-XMM7 might hold parameters. So I assumed using XMM0 without
> saving/restoring should be fine.
>
> Is it incorrect use XMM* registers without saving/restoring them?
> Using XMM10 register as temporary register works fine without having
> to save and restore it.
>
> Please let me know your comments.
>
> Regards,
> Rohit
>
From serguei.spitsyn at oracle.com Thu Apr 5 21:07:36 2018
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 5 Apr 2018 14:07:36 -0700
Subject: JEP 331: Low-Overhead Heap Profiling
In-Reply-To: <CAF9BGByMimzf94oZJ7S1Xxw8-yOc7yuHP-+xnESFrhGXK5ReZQ@mail.gmail.com>
References: <20180329171223.64A4C1973B3@eggemoggin.niobe.net>
<cfb1b563-2702-a0b8-b122-da0e46b3b26f@redhat.com>
<CAF9BGBz_167RNNsHVEzs1Q-eiyih5mzB3BrTt0_Vu67SQUuwVg@mail.gmail.com>
<19dc905f-dbdd-ac8d-6092-1fe26e56cb24@redhat.com>
<CAF9BGByMimzf94oZJ7S1Xxw8-yOc7yuHP-+xnESFrhGXK5ReZQ@mail.gmail.com>
Message-ID: <19755e74-61bb-cc70-c1c1-c373dbdda822@oracle.com>
Hi Jc and Aleksey,
Please, find a couple of comments below.
On 4/5/18 09:05, JC Beyler wrote:
> Hi Aleksey,
>
> I inlined my answers :)
>
> On Thu, Apr 5, 2018 at 4:09 AM Aleksey Shipilev <shade at redhat.com> wrote:
>
>> On 04/05/2018 12:23 AM, JC Beyler wrote:
>>> On Wed, Apr 4, 2018 at 3:41 AM Aleksey Shipilev <shade at redhat.com
>> <mailto:shade at redhat.com>> wrote:
>>> *) It would be nice to mention the implementation details in the JEP
>> itself, i.e. where are the
>>> points it injects into GCs to sample? I assume it has to inject into
>> CollectedHeap::allocate_tlab,
>>> and it has to cap the max TLAB sizes to get into allocation slowpath
>> often enough?
>>> My understanding was that a JEP was the idea and specification and that
>> more technical information
>>> like that was out of scope for the JEP (implementations can change, etc.)
>> Well, yes. But if you have the implementation ideas, it is better to
>> demonstrate them along with the
>> idea. Discussing implementation approaches serves several purposes: a) it
>> empirically proves the
>> idea is implementable; b) it highlights tricky design decisions the
>> implementation has to force,
>> which aids the understanding of the scope; c) it prevents handwaving
>> against existing approaches :)
>>
> Fair enough, I've added an implementation design/state with a link to the
> current webrev at the end of the JEP issue
> <https://bugs.openjdk.java.net/browse/JDK-8171119>. Let me know if that is
> what you had in mind.
>
>
>>> It actually does not cap the max TLAB sizes, it changes the end pointer
>> to force paths into
>>> "thinking" the tlab is full; then in the slowpath it samples and fixes
>> things the pointers up for
>>> the next sample.
>> Ooof. So this has implications for JEP scope, and thus should be mentioned.
>>
> Perhaps, again I saw the JEP as a different level of abstraction and this
> is more in the details of implementation. However, I have added a full
> explanation of this into the JEP at the end, let me know if it makes sense.
> For convenience, let me copy-paste what I wrote there:
>
> "
> 2) The TLAB structure is augmented with a new allocation_end pointer and a
> current_end pointer. If the sampling is disabled, the two pointers are
> always equal and the code performs as before. If the sampling is enabled,
> the current_end is modified to be where the next sample point is requested.
> Then, any fast path will "think" the TLAB is full at that point and go down
> the slow path, which is explained in (3)
> "
>
>
>>
>>> *) Since JC apparently has the prototype, it would be easier to put
>> it somewhere, and link it into
>>> the JEP itself. Webrevs are interesting, but they get outdated
>> pretty quickly, so maybe putting the
>>> whole thing in JDK Sandbox [1] is the way to go.
>>>
>>> I've been keeping the webrevs up to date so there should be no real
>> problem. From what I read, you
>>> have to be a commiter for the JDK Sandbox, no? So I'm not sure that
>> would make sense there?
>>
>> Right, you have to be a Committer. Link the webrev to the JEP then?
>>
> I added the link and a few paragraphs on the implementation.
>
>
>>
>>> *) Motivation says: "The downsides [of JFR] are that a) it is tied
>> to a particular allocation
>>> implementation (TLABs), and misses allocations that don?t meet that
>> pattern; b) it doesn?t allow the
>>> user to customize the sampling rate; c) it only logs allocations, so
>> you cannot distinguish between
>>> live and dead objects."
>>>
>>> ...but then JEP apparently describes sampling the allocations via
>> TLABs? So, the real difference is
>>> (b), allowing to customize the sampling rate, or do I miss something?
>>>
>>> There are various differences between the JFR tlab events and this
>> system. First the JFR system
>>> provides a buffer event system, meaning you can miss samples if the
>> event buffer is full and threw
>>> out a sampling event before a reader got to it. Second, you don't get a
>> callback at the allocation
>>> spot, so you cannot have a means to do an action at that sampling point,
>> which means you have no way
>>> of knowing when an object is effectively dead using the JFR events.
>> Hopefully that makes sense?
>>
>> This paragraph should be in JEP text then?
>>
> Done, I revamped and edited the section into this now:
>
>
> "There are multiple alternatives to the system presented in this JEP. The
> introduction presented two already: The Java Flight Recorder
> <http://openjdk.java.net/jeps/328> system provides an interesting
> alternative but is not perfect due to it not allowing the sampling size to
> be set and not providing a callback.
>
> The JFR system does use the TLAB creation as a means to track memory
> allocation but, instead of a callback, JFR events use a buffer system that
> can lead to missing some sampled allocations. Finally, the JFR event system
> does not provide a means to track objects that have been garbage collected,
> which means it is not possible currently to have a system provide
> information about live and garbage collected objects using the JFR event
> system."
I'd like to highlight an important difference with the JFR.
The JEP adds new feature into the JVMTI which is an important
API/framework for various development and monitoring tools.
Now, a JVMTI agent can use a low overhead heap profiling API along with
the rest of JVMTI functionality.
It provides great flexibility to the tools.
For instance, it is up to the agent to decide if a stack trace needs to
be collected at each event point.
> Let me know if that works for you.
>
>
>
>>> *) Goals say: "Can give information about both live and dead Java
>> objects."
>>> ...but there is not discussion what/how does it give information
>> about the dead Java objects. I am
>>> struggling to imagine how allocation sampling would give this. Is
>> the goal too broad, or some API is
>>> not described in the JEP?
>>>
>>> Originally the JEP provided a means to the user to get that information
>> directly. Now because the
>>> sampling callback provides an oop, the user in the agent can add a weak
>> reference and use that to
>>> determine liveness.
>
>> Ooof! I guess that technically works. Please mention it.
>>
> I did already add it here:
>
>
> "E) What the Java agent can do
I'd suggest to replace the "Java agent" with the "JVMTI agent" for accuracy.
The term "Java agent" is used for JPLIS agents that are based on the
java.lang.instrument API:
https://docs.oracle.com/javase/8/docs/technotes/guides/instrumentation/index.html
Thanks,
Serguei
> The user of the callback can then pick up a stacktrace at the moment of the
> callback using the JVMTI GetStackTrace method for example. The oop obtained
> by the callback can be also wrapped into a JNI weak reference to help
> determine when the object has been garbage collected. The idea behind that
> is to provide data on what objects were sampled and are still considered
> live or garbage collected, which can be a good means to understand the
> job's behavior.
>
> The sampling rate will provide a different sampling precision but also can
> be a means to mitigate overhead due to the profiling. Using a sampling rate
> of 512k and the sampling solution, the overhead should be low enough that a
> user could reasonably leave the system on by default."
>
>
> ------
>
>
> I also have the proof of concept in tests here
> <http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.10/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorGCTest.java.html>
> and
> the native implementation is here
> <http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.10/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/libHeapMonitorTest.c.html>
> .
>
> Let me know if my additions to the JEP are what you were looking for and is
> there anything else you think I should add information about!
>
> Thanks for reviewing it!
> Jc
From jcbeyler at google.com Thu Apr 5 22:04:36 2018
From: jcbeyler at google.com (JC Beyler)
Date: Thu, 05 Apr 2018 22:04:36 +0000
Subject: JEP 331: Low-Overhead Heap Profiling
In-Reply-To: <19755e74-61bb-cc70-c1c1-c373dbdda822@oracle.com>
References: <20180329171223.64A4C1973B3@eggemoggin.niobe.net>
<cfb1b563-2702-a0b8-b122-da0e46b3b26f@redhat.com>
<CAF9BGBz_167RNNsHVEzs1Q-eiyih5mzB3BrTt0_Vu67SQUuwVg@mail.gmail.com>
<19dc905f-dbdd-ac8d-6092-1fe26e56cb24@redhat.com>
<CAF9BGByMimzf94oZJ7S1Xxw8-yOc7yuHP-+xnESFrhGXK5ReZQ@mail.gmail.com>
<19755e74-61bb-cc70-c1c1-c373dbdda822@oracle.com>
Message-ID: <CAF9BGBxSt4GNYxb8+BsozDjbbKdSEaTE1nEJaXmv5NGyF0rRHw@mail.gmail.com>
Added your comments to the text Serguei and changed the name of the section
to JVMTI agent.
Thanks!
Jc
On Thu, Apr 5, 2018 at 2:07 PM serguei.spitsyn at oracle.com <
serguei.spitsyn at oracle.com> wrote:
> Hi Jc and Aleksey,
>
> Please, find a couple of comments below.
>
>
> On 4/5/18 09:05, JC Beyler wrote:
> > Hi Aleksey,
> >
> > I inlined my answers :)
> >
> > On Thu, Apr 5, 2018 at 4:09 AM Aleksey Shipilev <shade at redhat.com>
> wrote:
> >
> >> On 04/05/2018 12:23 AM, JC Beyler wrote:
> >>> On Wed, Apr 4, 2018 at 3:41 AM Aleksey Shipilev <shade at redhat.com
> >> <mailto:shade at redhat.com>> wrote:
> >>> *) It would be nice to mention the implementation details in the JEP
> >> itself, i.e. where are the
> >>> points it injects into GCs to sample? I assume it has to inject
> into
> >> CollectedHeap::allocate_tlab,
> >>> and it has to cap the max TLAB sizes to get into allocation
> slowpath
> >> often enough?
> >>> My understanding was that a JEP was the idea and specification and that
> >> more technical information
> >>> like that was out of scope for the JEP (implementations can change,
> etc.)
> >> Well, yes. But if you have the implementation ideas, it is better to
> >> demonstrate them along with the
> >> idea. Discussing implementation approaches serves several purposes: a)
> it
> >> empirically proves the
> >> idea is implementable; b) it highlights tricky design decisions the
> >> implementation has to force,
> >> which aids the understanding of the scope; c) it prevents handwaving
> >> against existing approaches :)
> >>
> > Fair enough, I've added an implementation design/state with a link to the
> > current webrev at the end of the JEP issue
> > <https://bugs.openjdk.java.net/browse/JDK-8171119>. Let me know if that
> is
> > what you had in mind.
> >
> >
> >>> It actually does not cap the max TLAB sizes, it changes the end pointer
> >> to force paths into
> >>> "thinking" the tlab is full; then in the slowpath it samples and fixes
> >> things the pointers up for
> >>> the next sample.
> >> Ooof. So this has implications for JEP scope, and thus should be
> mentioned.
> >>
> > Perhaps, again I saw the JEP as a different level of abstraction and this
> > is more in the details of implementation. However, I have added a full
> > explanation of this into the JEP at the end, let me know if it makes
> sense.
> > For convenience, let me copy-paste what I wrote there:
> >
> > "
> > 2) The TLAB structure is augmented with a new allocation_end pointer and
> a
> > current_end pointer. If the sampling is disabled, the two pointers are
> > always equal and the code performs as before. If the sampling is enabled,
> > the current_end is modified to be where the next sample point is
> requested.
> > Then, any fast path will "think" the TLAB is full at that point and go
> down
> > the slow path, which is explained in (3)
> > "
> >
> >
> >>
> >>> *) Since JC apparently has the prototype, it would be easier to
> put
> >> it somewhere, and link it into
> >>> the JEP itself. Webrevs are interesting, but they get outdated
> >> pretty quickly, so maybe putting the
> >>> whole thing in JDK Sandbox [1] is the way to go.
> >>>
> >>> I've been keeping the webrevs up to date so there should be no real
> >> problem. From what I read, you
> >>> have to be a commiter for the JDK Sandbox, no? So I'm not sure that
> >> would make sense there?
> >>
> >> Right, you have to be a Committer. Link the webrev to the JEP then?
> >>
> > I added the link and a few paragraphs on the implementation.
> >
> >
> >>
> >>> *) Motivation says: "The downsides [of JFR] are that a) it is tied
> >> to a particular allocation
> >>> implementation (TLABs), and misses allocations that don?t meet
> that
> >> pattern; b) it doesn?t allow the
> >>> user to customize the sampling rate; c) it only logs allocations,
> so
> >> you cannot distinguish between
> >>> live and dead objects."
> >>>
> >>> ...but then JEP apparently describes sampling the allocations via
> >> TLABs? So, the real difference is
> >>> (b), allowing to customize the sampling rate, or do I miss
> something?
> >>>
> >>> There are various differences between the JFR tlab events and this
> >> system. First the JFR system
> >>> provides a buffer event system, meaning you can miss samples if the
> >> event buffer is full and threw
> >>> out a sampling event before a reader got to it. Second, you don't get a
> >> callback at the allocation
> >>> spot, so you cannot have a means to do an action at that sampling
> point,
> >> which means you have no way
> >>> of knowing when an object is effectively dead using the JFR events.
> >> Hopefully that makes sense?
> >>
> >> This paragraph should be in JEP text then?
> >>
> > Done, I revamped and edited the section into this now:
> >
> >
> > "There are multiple alternatives to the system presented in this JEP. The
> > introduction presented two already: The Java Flight Recorder
> > <http://openjdk.java.net/jeps/328> system provides an interesting
> > alternative but is not perfect due to it not allowing the sampling size
> to
> > be set and not providing a callback.
> >
> > The JFR system does use the TLAB creation as a means to track memory
> > allocation but, instead of a callback, JFR events use a buffer system
> that
> > can lead to missing some sampled allocations. Finally, the JFR event
> system
> > does not provide a means to track objects that have been garbage
> collected,
> > which means it is not possible currently to have a system provide
> > information about live and garbage collected objects using the JFR event
> > system."
>
> I'd like to highlight an important difference with the JFR.
> The JEP adds new feature into the JVMTI which is an important
> API/framework for various development and monitoring tools.
> Now, a JVMTI agent can use a low overhead heap profiling API along with
> the rest of JVMTI functionality.
> It provides great flexibility to the tools.
> For instance, it is up to the agent to decide if a stack trace needs to
> be collected at each event point.
>
>
> > Let me know if that works for you.
> >
> >
> >
> >>> *) Goals say: "Can give information about both live and dead Java
> >> objects."
> >>> ...but there is not discussion what/how does it give information
> >> about the dead Java objects. I am
> >>> struggling to imagine how allocation sampling would give this. Is
> >> the goal too broad, or some API is
> >>> not described in the JEP?
> >>>
> >>> Originally the JEP provided a means to the user to get that information
> >> directly. Now because the
> >>> sampling callback provides an oop, the user in the agent can add a weak
> >> reference and use that to
> >>> determine liveness.
> >
> >> Ooof! I guess that technically works. Please mention it.
> >>
> > I did already add it here:
> >
> >
> > "E) What the Java agent can do
>
> I'd suggest to replace the "Java agent" with the "JVMTI agent" for
> accuracy.
> The term "Java agent" is used for JPLIS agents that are based on the
> java.lang.instrument API:
>
> https://docs.oracle.com/javase/8/docs/technotes/guides/instrumentation/index.html
>
>
> Thanks,
> Serguei
>
> > The user of the callback can then pick up a stacktrace at the moment of
> the
> > callback using the JVMTI GetStackTrace method for example. The oop
> obtained
> > by the callback can be also wrapped into a JNI weak reference to help
> > determine when the object has been garbage collected. The idea behind
> that
> > is to provide data on what objects were sampled and are still considered
> > live or garbage collected, which can be a good means to understand the
> > job's behavior.
> >
> > The sampling rate will provide a different sampling precision but also
> can
> > be a means to mitigate overhead due to the profiling. Using a sampling
> rate
> > of 512k and the sampling solution, the overhead should be low enough
> that a
> > user could reasonably leave the system on by default."
> >
> >
> > ------
> >
> >
> > I also have the proof of concept in tests here
> > <
> http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.10/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorGCTest.java.html
> >
> > and
> > the native implementation is here
> > <
> http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.10/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/libHeapMonitorTest.c.html
> >
> > .
> >
> > Let me know if my additions to the JEP are what you were looking for and
> is
> > there anything else you think I should add information about!
> >
> > Thanks for reviewing it!
> > Jc
>
>
From kim.barrett at oracle.com Thu Apr 5 23:38:56 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 5 Apr 2018 19:38:56 -0400
Subject: RFR: 8199417: Modularize interpreter GC barriers
In-Reply-To: <5AC4D555.9040800@oracle.com>
References: <5AB8BDF9.4050106@oracle.com>
<3FFD79AD-84B8-4E9E-98E3-47ACBA01D91F@oracle.com>
<5AC4D555.9040800@oracle.com>
Message-ID: <80295FD9-254E-4670-AB47-E2A4B36C4143@oracle.com>
> On Apr 4, 2018, at 9:38 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>
> Hi Kim,
>
> Thank you for reviewing this.
>
> I have made a new webrev with proposed changes to the x86/x64 code reflecting the concerns you and Coleen have.
> I thought we should settle for something we like in the x86/x64 code before going ahead and changing the other platforms too much (I don't want to bug Martin and Roman too much before).
>
> New full webrev:
> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01/
>
> Incremental:
> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.00_01/
This looks better, and you've mostly answered the issues I've raised
so far. Some further discussion inline below.
Other things have come up and I'm not going to be able to properly get
back to this soon; don't hold up on my account, just drop me as a
reviewer.
> On 2018-04-01 05:12, Kim Barrett wrote:
>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>> 364 #ifndef _LP64
>> 365 InterpreterMacroAssembler *imasm = static_cast<InterpreterMacroAssembler*>(masm);
>> 366 #endif
>>
>> In the old code, the function received an InterpreterMacroAssembler*.
>>
>> What is there about this context that lets us know the downcast is
>> safe here? Is oop_store_at only ever called with an IMA*? If so,
>> then why isn't that the parameter type. If not, then what?
>
> Yes, this is indeed only used by the InterpreterMacroAssembler. But I wanted the interface to use MacroAssembler. Why?
>
> 1) It's only 32 bit x86 that relies on this property, and I hope it will go away soon, and the save bcp hack with it.
> 2) previous load_heap_oop is used not only in the InterpreterMacroAssembler, and I wanted the same assembler in load_at and store_at.
>
> So for now it is only used in InterpreterMacroAssembler, and I doubt that will change any time soon. I am hoping 32 bit support will be dropped before that, and the hack will go away. For now, I have added a virtual is_interpreter_masm() call that I use in an assert to make sure this is not accidentally used in the wrong context until 32 bit support is gone.
The comment plus the new assert satisfies my complaint.
>> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> 698 address TemplateInterpreterGenerator::generate_Reference_get_entry(void) {
>>
>> Almost all the code here (and much of the commentary) was/is specific
>> to G1 (or SATB collectors). Shouldn't it all be in the barrier_set's
>> load_at? As it is now, if (say) we're using Parallel GC then I think
>> there's a bunch of additional code being generated and executed here
>> that wasn't present before.
>
> It is true that interpreter Reference.get() intrinsics with Parallel/CMS/Serial currently run a few instructions more than they need to pay for the abstraction. There is no doubt in my mind that this abstraction is worth the cost. Reference.get in the interpreter is not a hot path, and does not need to optimize every cycle.
>
> I changed the G1 comments to more general comments instead.
Good point on this not being a hot path.
"Preserve the sender sp in case the pre-barrier
calls the runtime"
s/the pre-barrier/a load barrier/
>> src/hotspot/cpu/x86/gc/shared/modRefBarrierSetAssembler_x86.cpp
>> 86 void ModRefBarrierSetAssembler::store_at(MacroAssembler* masm, DecoratorSet decorators, BasicType type,
>> 87 Address dst, Register val, Register tmp1, Register tmp2) {
>> 88 if (type == T_OBJECT || type == T_ARRAY) {
>> 89 oop_store_at(masm, decorators, type, dst, val, tmp1, tmp2);
>> 90 } else {
>> 91 BarrierSetAssembler::store_at(masm, decorators, type, dst, val, tmp1, tmp2);
>> 92 }
>> 93 }
>>
>> Doesn't the conditional conversion from store_at to oop_store_at
>> actually indicate a bug in the caller? That is, calling store_at with
>> a oop (T_OBJECT or T_ARRAY) value seems like a bug, and should be
>> asserted against, rather than translating.
>>
>> And oop_store_at should assert that the value *is* an oop value.
>>
>> And should there be any verification that the decorators and the type
>> are consistent?
>>
>> But maybe I'm not understanding the protocol around oop_store_at?
>> There being no documentation, it seems entirely possible that I've
>> misunderstood something here. Maybe I'm being confused by
>> similarities in naming with Access:: that don't hold?
>
> The confusion roots in that Access and BarrierSetAssembler are not structured exactly the same.
>
> Access provides store_at and oop_store_at. The reason for providing both of these, is that I could not safely infer whether the passed in parameters were oops or not without changing oop and narrowOop to always be value objects, which I did not dare to do as the generated code was worse.
>
> In BarrierSetAssembler, there is no such restriction. The type for the access is always passed in to store_at/load_at as BasicType. It is the responsibility of ModRefBarrierSetAssembler to filter away non-oop references, and call oop_store_at for relevant accesses for ModRef. This follows the same pattern that the arraycopy stubs used. This allows, e.g. CardTableModRef to only override oop_store_at. This is similar to how ModRefBarrierSet::AccessBarrier<decorators, BarrierSetT>::oop_store_in_heap calls the concrete barriersets for help generating that access. I hope this helps understanding the structuring.
>
> This is also the reason why G1BarrierSetAssembler::load_at checks whether it is an oop that is loaded or not, because loads are not riding on the ModRef layer, which only knows about oop stores.
I see. The naming congurence, along with my having glazed over the
fact that oop_store_at is protected rather than public, led me astray.
I don't have any better suggestions for naming. I would have found
some comments describing the protocols helpful.
Shouldn't ModRef::oop_store_at be pure virtual? That would have
helped my understanding too.
From jesper.wilhelmsson at oracle.com Fri Apr 6 00:37:16 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Fri, 6 Apr 2018 02:37:16 +0200
Subject: Merging jdk/hs with jdk/jdk
In-Reply-To: <8819CAD3-AF29-463E-8A76-14440CF37D2B@oracle.com>
References: <8819CAD3-AF29-463E-8A76-14440CF37D2B@oracle.com>
Message-ID: <952F85EF-BB76-4645-AC05-F843DB83881B@oracle.com>
Hi all,
I've gotten only positive feedback on this suggestion. The next step
is to propose a date and outline the steps needed to go through with
this change.
The proposed date is April 12 (Thursday next week).
The steps are:
1. jdk/hs is closed for pushes at 8 pm PST on April 12. This is when
the hotspot nightly takes the snapshot of jdk/hs and starts the nightly
tests. Please note that this is a hard deadline as the system is
automated and will take the snapshot on time.
2. The Thursday snapshot will then be sent through the regular product
integration testing (PIT) which runs over the weekend.
3. On Friday, April 13, the hotspot nightly and the hotspot CI (post
integration testing) will be reconfigured to look at jdk/jdk.
4. The goal is to get the PIT analysis done by Wednesday, April 18.
At this point the PIT snapshot will be pushed to jdk/jdk.
5. Once the PIT snapshot has been pushed to jdk/jdk, the jdk/jdk
repository will be open for hotspot changes.
In order to minimize the risk of merge conflicts when pushing the
PIT snapshot to jdk/jdk, we will not open for hotspot changes
until after the snapshot has been pushed.
It is important that everyone that has a new change in the snapshot
are available on Monday / Tuesday (April 16-17) to handle any
problems that might arise as a result of the change. If you know that
you will not be available these days, make sure someone else can
cover your change, or hold your push until after the merge is done.
Thanks,
/Jesper
> On 14 Mar 2018, at 22:00, jesper.wilhelmsson at oracle.com wrote:
>
> All,
>
> Over the last couple of years we have left behind a graph of
> integration forests where each component in the JVM had its own
> line of development. Today all HotSpot development is done in the
> same repository, jdk/hs [1]. As a result of merging we have seen
> several positive effects, ranging from less confusion around
> where and how to do things, and reduced time for fixes to
> propagate, to significantly better cooperation between the
> components, and improved quality of the product. We would like to
> improve further and therefore we suggest to merge jdk/hs into
> jdk/jdk [2].
>
> As before, we expect this change to build a stronger team spirit
> between the merged areas, and contribute to less confusion -
> especially around ramp down phases and similar. We also expect
> further improvements in quality as changes that cause problems in
> a different area are found faster and can be dealt with
> immediately.
>
> In the same way as we did in the past, we suggest to try this out
> as an experiment for at least two weeks (giving us some time to
> adapt in case of issues). Monitoring and evaluation of the new
> structure will take place continuously, with an option to revert
> back if things do not work out. The experiment would keep going
> for at least a few months, after which we will evaluate it and
> depending on the results consider making it the new standard. If
> so, the jdk/hs forest will eventually be retired. As part of this
> merge we can also retire the newly setup submit-hs [3] repository
> and do all testing using the submit repo based on jdk/jdk [4].
>
> Much like what we have done in the past we would leave the jdk/hs
> forest around until we see if the experiment works out. We would
> also lock it down so that no accidental pushes are made to
> it. Once the jdk/hs forest is locked down, any work in flight
> based on it would have to be rebased on jdk/jdk.
>
> We tried this approach during the last few months of JDK 10
> development and it worked out fine there.
>
> Please let us know if you have any feedback or questions!
>
> Thanks,
> /Jesper
>
> [1] http://hg.openjdk.java.net/jdk/hs <http://hg.openjdk.java.net/jdk/hs>
> [2] http://hg.openjdk.java.net/jdk/jdk <http://hg.openjdk.java.net/jdk/jdk>
> [3] http://hg.openjdk.java.net/jdk/submit-hs <http://hg.openjdk.java.net/jdk/submit-hs>
> [4] http://hg.openjdk.java.net/jdk/submit <http://hg.openjdk.java.net/jdk/submit>
From rohitarulraj at gmail.com Fri Apr 6 05:04:52 2018
From: rohitarulraj at gmail.com (Rohit Arul Raj)
Date: Fri, 6 Apr 2018 10:34:52 +0530
Subject: RFC: C2 Object Initialization - Using XMM/YMM registers
In-Reply-To: <f21029be-c4a7-8104-6d4b-e6bbd13525b9@oracle.com>
References: <CAPVMLfVcpTXpaTeMwo0Gg=NgDpkz+Z2cD+FP7mw6iHJH5R-+nw@mail.gmail.com>
<f21029be-c4a7-8104-6d4b-e6bbd13525b9@oracle.com>
Message-ID: <CAPVMLfVxaDT2qvGaSzyC4pPxD1FNQ3zaGPhL+CNbRYS9PM1CsQ@mail.gmail.com>
On Thu, Apr 5, 2018 at 11:38 PM, Vladimir Kozlov
<vladimir.kozlov at oracle.com> wrote:
> Good suggestion, Rohit
>
> I created new RFE. Please add you suggestion and performance data there:
>
> https://bugs.openjdk.java.net/browse/JDK-8201193
>
Thanks Vladimir.
I don't have an account/access to JDK bug data base yet. Is there any
other way around it?
Can I send in a request for Author role?
Regards,
Rohit
>
> On 4/5/18 12:19 AM, Rohit Arul Raj wrote:
>>
>> Hi All,
>>
>> I was going through the C2 object initialization (zeroing) code based
>> on the below bug entry:
>> https://bugs.openjdk.java.net/browse/JDK-8146801
>>
>> Right now, for longer lengths we use "rep stos" instructions on x86. I
>> was experimenting with using XMM/YMM registers (on AMD EPYC processor)
>> and found that they do improve performance for certain lengths:
>>
>> For lengths > 64 bytes - 512 bytes : improvement is in the range of 8% to
>> 44%
>> For lengths > 512bytes : some lengths show slight
>> improvement in the range of 2% to 7%, others almost same as "rep stos"
>> numbers.
>>
>> I have attached the complete performance data (data.txt) for reference .
>> Can we add this as an user option similar to UseXMMForArrayCopy?
>>
>> I have used the same test case as in
>> (http://cr.openjdk.java.net/~shade/8146801/benchmarks.jar) with
>> additional sizes.
>>
>> Initial Patch:
>> I haven't added the check for 32-bit mode as I need some help with the
>> code (description given below the patch).
>> The code is similar to the one used in array copy stubs
>> (copy_bytes_forward).
>>
>> diff --git a/src/hotspot/cpu/x86/globals_x86.hpp
>> b/src/hotspot/cpu/x86/globals_x86.hpp
>> --- a/src/hotspot/cpu/x86/globals_x86.hpp
>> +++ b/src/hotspot/cpu/x86/globals_x86.hpp
>> @@ -150,6 +150,9 @@
>> product(bool, UseUnalignedLoadStores, false,
>> \
>> "Use SSE2 MOVDQU instruction for Arraycopy")
>> \
>>
>> \
>> + product(bool, UseXMMForObjInit, false,
>> \
>> + "Use XMM/YMM MOVDQU instruction for Object Initialization")
>> \
>> +
>> \
>> product(bool, UseFastStosb, false,
>> \
>> "Use fast-string operation for zeroing: rep stosb")
>> \
>>
>> \
>> diff --git a/src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> b/src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> --- a/src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> +++ b/src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> @@ -7106,6 +7106,56 @@
>> if (UseFastStosb) {
>> shlptr(cnt, 3); // convert to number of bytes
>> rep_stosb();
>> + } else if (UseXMMForObjInit && UseUnalignedLoadStores) {
>> + Label L_loop, L_sloop, L_check, L_tail, L_end;
>> + push(base);
>> + if (UseAVX >= 2)
>> + vpxor(xmm10, xmm10, xmm10, AVX_256bit);
>> + else
>> + vpxor(xmm10, xmm10, xmm10, AVX_128bit);
>> +
>> + jmp(L_check);
>> +
>> + BIND(L_loop);
>> + if (UseAVX >= 2) {
>> + vmovdqu(Address(base, 0), xmm10);
>> + vmovdqu(Address(base, 32), xmm10);
>> + } else {
>> + movdqu(Address(base, 0), xmm10);
>> + movdqu(Address(base, 16), xmm10);
>> + movdqu(Address(base, 32), xmm10);
>> + movdqu(Address(base, 48), xmm10);
>> + }
>> + addptr(base, 64);
>> +
>> + BIND(L_check);
>> + subptr(cnt, 8);
>> + jccb(Assembler::greaterEqual, L_loop);
>> + addptr(cnt, 4);
>> + jccb(Assembler::less, L_tail);
>> + // Copy trailing 32 bytes
>> + if (UseAVX >= 2) {
>> + vmovdqu(Address(base, 0), xmm10);
>> + } else {
>> + movdqu(Address(base, 0), xmm10);
>> + movdqu(Address(base, 16), xmm10);
>> + }
>> + addptr(base, 32);
>> + subptr(cnt, 4);
>> +
>> + BIND(L_tail);
>> + addptr(cnt, 4);
>> + jccb(Assembler::lessEqual, L_end);
>> + decrement(cnt);
>> +
>> + BIND(L_sloop);
>> + movptr(Address(base, 0), tmp);
>> + addptr(base, 8);
>> + decrement(cnt);
>> + jccb(Assembler::greaterEqual, L_sloop);
>> +
>> + BIND(L_end);
>> + pop(base);
>> } else {
>> NOT_LP64(shlptr(cnt, 1);) // convert to number of 32-bit words
>> for 32-bit VM
>> rep_stos();
>>
>>
>> When I use XMM0 as a temporary register, the micro-benchmark crashes.
>> Saving and Restoring the XMM0 register before and after use works
>> fine.
>>
>> Looking at the "hotspot/src/cpu/x86/vm/x86.ad" file, XMM0 as with
>> other XMM registers has been mentioned as Save-On-Call registers and
>> on Linux ABI, no register is preserved across function calls though
>> XMM0-XMM7 might hold parameters. So I assumed using XMM0 without
>> saving/restoring should be fine.
>>
>> Is it incorrect use XMM* registers without saving/restoring them?
>> Using XMM10 register as temporary register works fine without having
>> to save and restore it.
>>
>> Please let me know your comments.
>>
>> Regards,
>> Rohit
>>
>
From stefan.karlsson at oracle.com Fri Apr 6 08:00:31 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 6 Apr 2018 10:00:31 +0200
Subject: RFR: 8200759: Move GC entries in vmStructs.cpp to GC specific
files
In-Reply-To: <8f9ef0fb-14b6-fca8-04ac-1ce49a3a11f0@oracle.com>
References: <8f9ef0fb-14b6-fca8-04ac-1ce49a3a11f0@oracle.com>
Message-ID: <25075b38-dd87-5d07-dbc8-137798d49931@oracle.com>
Hi all,
Since I have a few follow-up changes that depend on the ALL_GCS_ONLY
macro introduced in this patch, I'm going to extract that part into a
separate RFE, so that if any of the following patches need to be backed
out (for some reason) I won't have to back out this change.
This is the piece I'm going to push separately:
http://cr.openjdk.java.net/~stefank/8200759/webrev.01/src/hotspot/share/utilities/macros.hpp.udiff.html
Thanks,
StefanK
On 2018-04-04 21:37, Stefan Karlsson wrote:
> Hi all,
>
> Please review this patch to move GC specific entries in vmStructs.cpp
> out to GC specific files.
>
> http://cr.openjdk.java.net/~stefank/8200759/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8200759
>
> This patch is done in preparation for:
> ?https://bugs.openjdk.java.net/browse/JDK-8200729 - Conditional
> compilation of GCs
>
> This patch also has the nice feature that it removes multiple usages of
> the GC specific defines in vmStructs.cpp. When new GCs are added only
> three defines need to be added to vmStructs_gc.hpp.
>
> Tested locally with test/hotspot/jtreg/serviceability/sa, but will run
> this through mach5 to find potantial missing includes / forward
> declarations.
>
> Thanks,
> StefanK
From stefan.johansson at oracle.com Fri Apr 6 08:23:20 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Fri, 6 Apr 2018 10:23:20 +0200
Subject: RFR(S): 8200720: Print accumulated number of allocated bytes in
thread dump
In-Reply-To: <171FA571-AFEC-4E88-B681-D10F8DFD1639@sap.com>
References: <171FA571-AFEC-4E88-B681-D10F8DFD1639@sap.com>
Message-ID: <721b10fe-742a-4d4b-0b97-44258664a408@oracle.com>
Hi Gunter,
On 2018-04-05 12:28, Haug, Gunter wrote:
> Hi,
>
> can I please have a review and a sponsor for the following enhancement:
>
> http://cr.openjdk.java.net/~ghaug/webrevs/8200720
> https://bugs.openjdk.java.net/browse/JDK-8200720
>
There is already accounting of allocated bytes on Thread:
jlong _allocated_bytes; // Cumulative number of bytes allocated on
// the Java heap
The value is updated at TLAB refills and allocations outside the TLAB,
so it already includes the type allocations JC is mentioning. Any reason
this can't be used instead of adding your new accounting?
To include bytes allocated in the current TLAB you can call:
Thread::cooked_allocated_bytes();
Thanks,
Stefan
> We at SAP have extended the thread dumps (obtained by jstack or jcmd) by several fields providing thread specific information. These extensions are quite popular with our support team. With some knowledge of the architecture of the application, they often allow for quick and simple diagnosis of a running system. Therefore we would like to contribute these enhancements.
>
> I took the quite simple accumulated number of bytes allocated by a thread as an example. This only works with TLAB active. Provided it is known how the application should behave, a misbehaving thread can identified easily.
>
> There is no measurable overhead for this enhancement. However, it may be a problem that the format of the output is changed. Tools parsing the output may have to be changed.
>
> Here is an example of the output generated:
>
> ---------------------------------------------------------
> "main" #1 prio=5 os_prio=31 allocated=243048448B tid=0x00007fca98000800 nid=0x1d03 waiting on condition [0x0000000109baa000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(java.base/Native Method)
> ...
> ---------------------------------------------------------
>
> As mentioned above, we have a whole bunch of other enhancements to the thread dump similar to this one and would be willing to contribute them if there is any interest.
>
> Thanks and best regards,
> Gunter
>
From magnus.ihse.bursie at oracle.com Fri Apr 6 10:57:01 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 6 Apr 2018 12:57:01 +0200
Subject: RFR: JDK-8201236 Straighten out dtrace build logic
Message-ID: <760d77ab-77c8-451a-2f02-fceaaeef38b8@oracle.com>
The dtrace build logic was copied straight out of the old Hotspot build
system, and is quite convoluted.
It should be split into the separate parts it actually contains of:
1) A gensrc step which runs with other gensrc ahead of compilation
2) Two independent libraries that can be build at any time
3) Two special dtrace-generated .o files that must be linked with the JVM
I have also cleaned up includes in generateJvmOffsets.cpp.
I have verified with COMPARE_BUILD that no changes has happened in any
native library.
Bug: https://bugs.openjdk.java.net/browse/JDK-8201236
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8201236-straighten-out-dtrace/webrev.01
/Magnus
From shade at redhat.com Fri Apr 6 12:55:32 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 6 Apr 2018 14:55:32 +0200
Subject: RFR 8199868: Support JNI critical functions in object pinning API
In-Reply-To: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com>
References: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com>
Message-ID: <bca06cab-610e-c46c-a51d-175a18138cfc@redhat.com>
On 04/04/2018 07:47 PM, Zhengyu Gu wrote:
> Please review this patch that adds JNI critical native support to object pinning.
>
> Shenandoah does not block GC while JNI critical session is in progress. This patch allows it to pin
> all incoming array objects before critical native call, and unpin them after call completes.
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8199868
> Webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.00/
Looks good to me, but somebody more savvy with runtime stub generation should take a closer look.
*) Should probably be "Why we are here?"
2867 assert(Universe::heap()->supports_object_pinning(), "Why we here?");
2876 assert(Universe::heap()->supports_object_pinning(), "Why we here?");
Thanks,
-Aleksey
From glaubitz at physik.fu-berlin.de Fri Apr 6 13:02:39 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Fri, 6 Apr 2018 15:02:39 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
Message-ID: <34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
On 04/05/2018 05:49 PM, John Paul Adrian Glaubitz wrote:
> Right, I somehow completely forgot to enable debugging. Will rebuild with fastdebug.
Backtrace with fastdebug:
(gdb) bt
#0 0xffff80010060bb9c in __libc_signal_restore_set (set=0xffff800102637358) at ../sysdeps/unix/sysv/linux/nptl-signals.h:80
#1 __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#2 0xffff80010060d144 in __GI_abort () at abort.c:79
#3 0xffff800101a5807c in os::abort (dump_core=<optimized out>, siginfo=0x0, context=0x0) at /srv/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:1423
#4 0xffff800101e73e84 in VMError::report_and_die (id=id at entry=-536870912, message=message at entry=0xffff800101fd2528 "assert((((intptr_t)sp & (wordSize-1)) == 0)) failed", detail_fmt=detail_fmt at entry=0xffff800101fd2500 "frame constructor passed an invalid sp",
detail_args=detail_args at entry=0xffff800102637ab0, thread=thread at entry=0x0, pc=pc at entry=0x0, siginfo=0x0, context=0x0, filename=0xffff800101fd2298 "/srv/openjdk/hs/src/hotspot/cpu/sparc/frame_sparc.cpp", lineno=331, size=0)
at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1504
#5 0xffff800101e74cc0 in VMError::report_and_die (thread=0x0, context=context at entry=0x0, filename=filename at entry=0xffff800101fd2298 "/srv/openjdk/hs/src/hotspot/cpu/sparc/frame_sparc.cpp", lineno=lineno at entry=331,
message=message at entry=0xffff800101fd2528 "assert((((intptr_t)sp & (wordSize-1)) == 0)) failed", detail_fmt=detail_fmt at entry=0xffff800101fd2500 "frame constructor passed an invalid sp", detail_args=<optimized out>)
at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1244
#6 0xffff8001010e5d74 in report_vm_error (file=0xffff800101fd2298 "/srv/openjdk/hs/src/hotspot/cpu/sparc/frame_sparc.cpp", line=line at entry=331, error_msg=0xffff800101fd2528 "assert((((intptr_t)sp & (wordSize-1)) == 0)) failed",
detail_fmt=0xffff800101fd2500 "frame constructor passed an invalid sp") at /srv/openjdk/hs/src/hotspot/share/utilities/debug.cpp:230
#7 0xffff8001011ec64c in frame::init (cb=0x0, pc=0xffff800101a68394 <os::current_frame()> "\235\343\277 /", sp=0xffff8001026373b1, this=0xffff800102637b80) at /srv/openjdk/hs/src/hotspot/cpu/sparc/frame_sparc.cpp:331
#8 frame::frame (this=0xffff800102637b80, sp=0xffff8001026373b1, pc=0xffff800101a68394 <os::current_frame()> "\235\343\277 /", cb=0x0) at /srv/openjdk/hs/src/hotspot/cpu/sparc/frame_sparc.cpp:345
#9 0xffff800101a683dc in os::current_frame () at /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp:139
#10 0xffff800101e72e0c in VMError::report (st=st at entry=0xffff800102347248 <VMError::log>, _verbose=_verbose at entry=true) at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:704
#11 0xffff800101e73f38 in VMError::report_and_die (id=id at entry=-536870912, message=message at entry=0xffff800101fd2528 "assert((((intptr_t)sp & (wordSize-1)) == 0)) failed", detail_fmt=detail_fmt at entry=0xffff800101fd2500 "frame constructor passed an invalid sp",
detail_args=detail_args at entry=0xffff800102638040, thread=thread at entry=0x0, pc=pc at entry=0x0, siginfo=0x0, context=0x0, filename=0xffff800101fd2298 "/srv/openjdk/hs/src/hotspot/cpu/sparc/frame_sparc.cpp", lineno=331, size=0)
at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1405
#12 0xffff800101e74cc0 in VMError::report_and_die (thread=0x0, context=context at entry=0x0, filename=filename at entry=0xffff800101fd2298 "/srv/openjdk/hs/src/hotspot/cpu/sparc/frame_sparc.cpp", lineno=lineno at entry=331,
message=message at entry=0xffff800101fd2528 "assert((((intptr_t)sp & (wordSize-1)) == 0)) failed", detail_fmt=detail_fmt at entry=0xffff800101fd2500 "frame constructor passed an invalid sp", detail_args=<optimized out>)
at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1244
#13 0xffff8001010e5d74 in report_vm_error (file=0xffff800101fd2298 "/srv/openjdk/hs/src/hotspot/cpu/sparc/frame_sparc.cpp", line=line at entry=331, error_msg=0xffff800101fd2528 "assert((((intptr_t)sp & (wordSize-1)) == 0)) failed",
detail_fmt=0xffff800101fd2500 "frame constructor passed an invalid sp") at /srv/openjdk/hs/src/hotspot/share/utilities/debug.cpp:230
#14 0xffff8001011ec64c in frame::init (cb=0x0, pc=0xffff800101a68394 <os::current_frame()> "\235\343\277 /", sp=0xffff800102637941, this=0xffff800102638110) at /srv/openjdk/hs/src/hotspot/cpu/sparc/frame_sparc.cpp:331
#15 frame::frame (this=0xffff800102638110, sp=0xffff800102637941, pc=0xffff800101a68394 <os::current_frame()> "\235\343\277 /", cb=0x0) at /srv/openjdk/hs/src/hotspot/cpu/sparc/frame_sparc.cpp:345
#16 0xffff800101a683dc in os::current_frame () at /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp:139
#17 0xffff800101e72e8c in VMError::report (st=st at entry=0xffff800102347248 <VMError::log>, _verbose=_verbose at entry=true) at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:685
#18 0xffff800101e73f38 in VMError::report_and_die (id=id at entry=-536870912, message=message at entry=0xffff800101f3fd30 "assert(current != __null) failed", detail_fmt=detail_fmt at entry=0xffff800101f3fd00 "Thread::current() called on detached thread",
detail_args=detail_args at entry=0xffff8001026385d0, thread=thread at entry=0x0, pc=pc at entry=0x0, siginfo=0x0, context=0x0, filename=0xffff800101f3fd58 "/srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp", lineno=720, size=0)
at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1405
#19 0xffff800101e74cc0 in VMError::report_and_die (thread=0x0, context=context at entry=0x0, filename=filename at entry=0xffff800101f3fd58 "/srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp", lineno=lineno at entry=720,
message=message at entry=0xffff800101f3fd30 "assert(current != __null) failed", detail_fmt=detail_fmt at entry=0xffff800101f3fd00 "Thread::current() called on detached thread", detail_args=<optimized out>) at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1244
#20 0xffff8001010e5d74 in report_vm_error (file=0xffff800101f3fd58 "/srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp", line=line at entry=720, error_msg=0xffff800101f3fd30 "assert(current != __null) failed",
detail_fmt=0xffff800101f3fd00 "Thread::current() called on detached thread") at /srv/openjdk/hs/src/hotspot/share/utilities/debug.cpp:230
#21 0xffff800101a48fc0 in Thread::current () at /srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp:720
#22 ResourceMark::ResourceMark (this=0xffff800102638600) at /srv/openjdk/hs/src/hotspot/share/memory/resourceArea.hpp:109
#23 verify_memory (ptr=ptr at entry=0xffff80010400fda0) at /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:632
#24 0xffff800101a4ea74 in os::free (memblock=0xffff80010400fda0) at /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:783
#25 0xffff800101ee9df0 in CPUinfo::~CPUinfo (this=0xffff800102638888, __in_chrg=<optimized out>) at /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:59
#26 VM_Version::platform_features () at /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:184
#27 0xffff800101eea080 in VM_Version::determine_features () at /srv/openjdk/hs/src/hotspot/cpu/sparc/vm_version_sparc.cpp:505
#28 0xffff800101da1ed0 in Threads::create_vm (args=args at entry=0xffff800102638d78, canTryAgain=canTryAgain at entry=0xffff800102638c57) at /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:3637
#29 0xffff800101570a78 in JNI_CreateJavaVM_inner (args=0xffff800102638d78, penv=0xffff800102638d70, vm=0xffff800102638d68) at /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:3929
#30 JNI_CreateJavaVM (vm=0xffff800102638d68, penv=0xffff800102638d70, args=0xffff800102638d78) at /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:4024
#31 0xffff8001003bfa74 in InitializeJVM (ifn=<synthetic pointer>, penv=0xffff800102638d70, pvm=0xffff800102638d68) at /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:1478
#32 JavaMain (_args=<optimized out>) at /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:411
#33 0xffff8001002a3874 in start_thread (arg=0xffff800102639910) at pthread_create.c:463
#34 0xffff8001006bf140 in __thread_start () at ../sysdeps/unix/sysv/linux/sparc/sparc64/clone.S:78
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
Output during build is:
Optimizing the exploded image
/srv/openjdk/hs/build/linux-sparcv9-normal-server-fastdebug/jdk/bin/java -Xms64M -Xmx1600M -XX:ThreadStackSize=1536 -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 -cp /srv/openjdk/hs/build/linux-sparcv9-normal-server-fastdebug/buildtools/tools_jigsaw_classes -
-add-exports java.base/jdk.internal.module=ALL-UNNAMED build.tools.jigsaw.AddPackagesAttribute /srv/openjdk/hs/build/linux-sparcv9-normal-server-fastdebug/jdk
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=/thread.hpp:720
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp:720), pid=14848, tid=14849
# assert(current != __null) failed: Thread::current() called on detached thread
#
# JRE version: (11.0) (fastdebug build )
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 11-internal+0-adhoc.glaubitz.hs, mixed mode, sharing, tiered, serial gc, linux-sparc)
# Core dump will be written. Default location: /srv/openjdk/hs/make/core
#
# An error report file with more information is saved as:
# /srv/openjdk/hs/make/hs_err_pid14848.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
Current thread is 14849
Dumping core ...
make[3]: *** [ExplodedImageOptimize.gmk:41: /srv/openjdk/hs/build/linux-sparcv9-normal-server-fastdebug/jdk/_packages_attribute.done] Aborted (core dumped)
make[3]: Leaving directory '/srv/openjdk/hs/make'
make[2]: *** [make/Main.gmk:360: exploded-image-optimize] Error 2
make[2]: Leaving directory '/srv/openjdk/hs'
ERROR: Build failed for target 'images' in configuration 'linux-sparcv9-normal-server-fastdebug' (exit code 2)
make[2]: Entering directory '/srv/openjdk/hs'
[ -f /srv/openjdk/hs/build/linux-sparcv9-normal-server-fastdebug/make-support/javacservers/server.port ] && /bin/echo Stopping sjavac server && /usr/bin/touch /srv/openjdk/hs/build/linux-sparcv9-normal-server-fastdebug/make-support/javacservers/server.port.stop; true
/bin/date '+%Y %m %d %H %M %S' | /usr/bin/nawk '{ print $1,$2,$3,$4,$5,$6,($4*3600+$5*60+$6) }' > /srv/openjdk/hs/build/linux-sparcv9-normal-server-fastdebug/make-support/build-times/build_time_end_TOTAL
/bin/date '+%Y-%m-%d %H:%M:%S' > /srv/openjdk/hs/build/linux-sparcv9-normal-server-fastdebug/make-support/build-times/build_time_end_TOTAL_human_readable
/bin/echo `/bin/cat /srv/openjdk/hs/build/linux-sparcv9-normal-server-fastdebug/make-support/build-times/build_time_start_TOTAL` `/bin/cat /srv/openjdk/hs/build/linux-sparcv9-normal-server-fastdebug/make-support/build-times/build_time_end_TOTAL` TOTAL | /usr/bin/nawk '{ F=$7; T=$14; if (F > T) { T+=3600*24 }; D=T-F; H=int(D/3600); M=int((D-H*3600)/60); S=D-H*3600-M*60; printf("%02d:%02d:%02d %s\n",H,M,S,$15); }' > /srv/openjdk/hs/build/linux-sparcv9-normal-server-fastdebug/make-support/build-times/build_time_diff_TOTAL
/usr/bin/printf -- "----- Build times -------\nStart %s\nEnd %s\n%s\n%s\n-------------------------\n" "`/bin/cat /srv/openjdk/hs/build/linux-sparcv9-normal-server-fastdebug/make-support/build-times/build_time_start_TOTAL_human_readable`" "`/bin/cat /srv/openjdk/hs/build/linux-sparcv9-normal-server-fastdebug/make-support/build-times/build_time_end_TOTAL_human_readable`" "`/bin/ls /srv/openjdk/hs/build/linux-sparcv9-normal-server-fastdebug/make-support/build-times/build_time_diff_* | /bin/grep -v _TOTAL | /usr/bin/xargs /bin/cat | /usr/bin/sort -k 2`" "`/bin/cat /srv/openjdk/hs/build/linux-sparcv9-normal-server-fastdebug/make-support/build-times/build_time_diff_TOTAL`" > >(/usr/bin/tee -a /srv/openjdk/hs/build/linux-sparcv9-normal-server-fastdebug/build.log) 2> >(/usr/bin/tee -a /srv/openjdk/hs/build/linux-sparcv9-normal-server-fastdebug/build.log >&2) && wait
----- Build times -------
Start 2018-04-05 15:58:54
End 2018-04-05 17:49:19
01:50:26 TOTAL
-------------------------
if /bin/grep -q "recipe for target .* failed" /srv/openjdk/hs/build/linux-sparcv9-normal-server-fastdebug/build.log 2> /dev/null; then /usr/bin/printf "\n=== Make failed targets repeated here ===\n" ; /bin/grep "recipe for target .* failed" /srv/openjdk/hs/build/linux-sparcv9-normal-server-fastdebug/build.log ; /usr/bin/printf "=== End of repeated output ===\n" ; /usr/bin/printf "\nHint: Try searching the build log for the name of the first failed target.\n" ; else /usr/bin/printf "\nNo indication of failed target found.\n" ; /usr/bin/printf "Hint: Try searching the build log for '] Error'.\n" ; fi
No indication of failed target found.
Hint: Try searching the build log for '] Error'.
/usr/bin/printf "Hint: See doc/building.html#troubleshooting for assistance.\n\n"
Hint: See doc/building.html#troubleshooting for assistance.
make[2]: Leaving directory '/srv/openjdk/hs'
make[1]: *** [/srv/openjdk/hs/make/Init.gmk:296: main] Error 2
make[1]: Leaving directory '/srv/openjdk/hs'
make: *** [/srv/openjdk/hs/make/Init.gmk:186: images] Error 2
Also attaching the log file.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From shade at redhat.com Fri Apr 6 13:12:46 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 6 Apr 2018 15:12:46 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
Message-ID: <5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
I would say dig here:
On 04/06/2018 03:02 PM, John Paul Adrian Glaubitz wrote:
> #20 0xffff8001010e5d74 in report_vm_error (file=0xffff800101f3fd58? detail_fmt=0xffff800101f3fd00 "Thread::current() called on detached thread") at
> #21 0xffff800101a48fc0 in Thread::current () at /srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp:720
> #22 ResourceMark::ResourceMark (this=0xffff800102638600) at /srv/openjdk/hs/src/hotspot/share/memory/resourceArea.hpp:109
> #23 verify_memory (ptr=ptr at entry=0xffff80010400fda0) at /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:632
> #24 0xffff800101a4ea74 in os::free (memblock=0xffff80010400fda0) at /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:783
> #25 0xffff800101ee9df0 in CPUinfo::~CPUinfo (this=0xffff800102638888, __in_chrg=<optimized out>) at /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:59
> #26 VM_Version::platform_features () at /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:184
> #27 0xffff800101eea080 in VM_Version::determine_features () at
> #28 0xffff800101da1ed0 in Threads::create_vm (args=args at entry=0xffff800102638d78, canTryAgain=canTryAgain at entry=0xffff800102638c57) at /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:3637
> #29 0xffff800101570a78 in JNI_CreateJavaVM_inner (args=0xffff800102638d78, penv=0xffff800102638d70, vm=0xffff800102638d68) at /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:3929
> #30 JNI_CreateJavaVM (vm=0xffff800102638d68, penv=0xffff800102638d70, args=0xffff800102638d78) at /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:4024
> #31 0xffff8001003bfa74 in InitializeJVM (ifn=<synthetic pointer>, penv=0xffff800102638d70, pvm=0xffff800102638d68) at /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:1478
> #32 JavaMain (_args=<optimized out>) at /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:411
> #33 0xffff8001002a3874 in start_thread (arg=0xffff800102639910) at pthread_create.c:463
> #34 0xffff8001006bf140 in __thread_start () at ../sysdeps/unix/sysv/linux/sparc/sparc64/clone.S:78
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
I think this means we are trying to use Resource area before the thread is fully initialized. IIRC
that is forbidden. Looking at os::verify_memory:
static void verify_memory(void* ptr) { // <--- frame #23
GuardedMemory guarded(ptr);
if (!guarded.verify_guards()) {
LogTarget(Warning, malloc, free) lt;
ResourceMark rm; // <--- frame #22
LogStream ls(lt);
ls.print_cr("## nof_mallocs = " UINT64_FORMAT ", nof_frees = " UINT64_FORMAT...
ls.print_cr("## memory stomp:");
guarded.print_on(&ls);
fatal("memory stomping error");
}
}
It seems we have *failed* the guarded memory check, entered the branch, and then failed reporting
the failure. This must mean buffer overrun somewhere?
Thanks,
-Aleksey
From zgu at redhat.com Fri Apr 6 13:16:52 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Fri, 6 Apr 2018 09:16:52 -0400
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
Message-ID: <2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
I think it is symptom, the real cause is:
In CPUinfo constructor:
_string = strdup(vstr);
should be:
_string = os::strdup(vstr, mtInternal);
-Zhengyu
On 04/06/2018 09:12 AM, Aleksey Shipilev wrote:
> I would say dig here:
>
> On 04/06/2018 03:02 PM, John Paul Adrian Glaubitz wrote:
>> #20 0xffff8001010e5d74 in report_vm_error (file=0xffff800101f3fd58? detail_fmt=0xffff800101f3fd00 "Thread::current() called on detached thread") at
>> #21 0xffff800101a48fc0 in Thread::current () at /srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp:720
>> #22 ResourceMark::ResourceMark (this=0xffff800102638600) at /srv/openjdk/hs/src/hotspot/share/memory/resourceArea.hpp:109
>> #23 verify_memory (ptr=ptr at entry=0xffff80010400fda0) at /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:632
>> #24 0xffff800101a4ea74 in os::free (memblock=0xffff80010400fda0) at /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:783
>> #25 0xffff800101ee9df0 in CPUinfo::~CPUinfo (this=0xffff800102638888, __in_chrg=<optimized out>) at /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:59
>> #26 VM_Version::platform_features () at /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:184
>> #27 0xffff800101eea080 in VM_Version::determine_features () at
>> #28 0xffff800101da1ed0 in Threads::create_vm (args=args at entry=0xffff800102638d78, canTryAgain=canTryAgain at entry=0xffff800102638c57) at /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:3637
>> #29 0xffff800101570a78 in JNI_CreateJavaVM_inner (args=0xffff800102638d78, penv=0xffff800102638d70, vm=0xffff800102638d68) at /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:3929
>> #30 JNI_CreateJavaVM (vm=0xffff800102638d68, penv=0xffff800102638d70, args=0xffff800102638d78) at /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:4024
>> #31 0xffff8001003bfa74 in InitializeJVM (ifn=<synthetic pointer>, penv=0xffff800102638d70, pvm=0xffff800102638d68) at /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:1478
>> #32 JavaMain (_args=<optimized out>) at /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:411
>> #33 0xffff8001002a3874 in start_thread (arg=0xffff800102639910) at pthread_create.c:463
>> #34 0xffff8001006bf140 in __thread_start () at ../sysdeps/unix/sysv/linux/sparc/sparc64/clone.S:78
>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> I think this means we are trying to use Resource area before the thread is fully initialized. IIRC
> that is forbidden. Looking at os::verify_memory:
>
> static void verify_memory(void* ptr) { // <--- frame #23
> GuardedMemory guarded(ptr);
> if (!guarded.verify_guards()) {
> LogTarget(Warning, malloc, free) lt;
> ResourceMark rm; // <--- frame #22
> LogStream ls(lt);
> ls.print_cr("## nof_mallocs = " UINT64_FORMAT ", nof_frees = " UINT64_FORMAT...
> ls.print_cr("## memory stomp:");
> guarded.print_on(&ls);
> fatal("memory stomping error");
> }
> }
>
> It seems we have *failed* the guarded memory check, entered the branch, and then failed reporting
> the failure. This must mean buffer overrun somewhere?
>
> Thanks,
> -Aleksey
>
From glaubitz at physik.fu-berlin.de Fri Apr 6 13:23:27 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Fri, 6 Apr 2018 15:23:27 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
Message-ID: <bed78e55-5bc2-eea5-b0bd-cdf3160cf3e0@physik.fu-berlin.de>
On 04/06/2018 03:16 PM, Zhengyu Gu wrote:
> I think it is symptom, the real cause is:
>
> In CPUinfo constructor:
>
> _string = strdup(vstr);
>
> should be:
>
> _string = os::strdup(vstr, mtInternal);
I changed that and now it seems I'm getting a different failure which
is an assertion failure:
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=/assembler_sparc.cpp:52
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.cpp:52), pid=18170, tid=18201
# assert(!(is_cti(prev) && is_cti(insn))) failed: CTI-CTI not allowed.
#
# JRE version: OpenJDK Runtime Environment (11.0) (fastdebug build 11-internal+0-adhoc.glaubitz.hs)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 11-internal+0-adhoc.glaubitz.hs, mixed mode, tiered, compressed oops, serial gc, linux-sparc)
# Core dump will be written. Default location: /srv/openjdk/hs/make/core
#
# An error report file with more information is saved as:
# /srv/openjdk/hs/make/hs_err_pid18170.log
#
# Compiler replay data is saved as:
# /srv/openjdk/hs/make/replay_pid18170.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
Current thread is 18201
Dumping core ...
make[3]: *** [ExplodedImageOptimize.gmk:41: /srv/openjdk/hs/build/linux-sparcv9-normal-server-fastdebug/jdk/_packages_attribute.done] Aborted (core dumped)
make[3]: Leaving directory '/srv/openjdk/hs/make'
make[2]: *** [make/Main.gmk:360: exploded-image-optimize] Error 2
make[2]: Leaving directory '/srv/openjdk/hs'
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From stefan.karlsson at oracle.com Fri Apr 6 13:23:35 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 6 Apr 2018 15:23:35 +0200
Subject: RR: 8201244: Clean out unnecessary includes of heap headers
Message-ID: <b47dd0b0-93e0-3e40-3318-d988d3f87481@oracle.com>
Hi all,
Please review this patch to remove some unnecessary includes of the
different GC heap headers.
http://cr.openjdk.java.net/~stefank/8201244/webrev.01
https://bugs.openjdk.java.net/browse/JDK-8201244
thanks,
StefanK
From shade at redhat.com Fri Apr 6 13:29:20 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 6 Apr 2018 15:29:20 +0200
Subject: RR: 8201244: Clean out unnecessary includes of heap headers
In-Reply-To: <b47dd0b0-93e0-3e40-3318-d988d3f87481@oracle.com>
References: <b47dd0b0-93e0-3e40-3318-d988d3f87481@oracle.com>
Message-ID: <6f962c39-108b-32ca-fa43-830ae39e00f4@redhat.com>
On 04/06/2018 03:23 PM, Stefan Karlsson wrote:
> http://cr.openjdk.java.net/~stefank/8201244/webrev.01
Looks fine. Have you checked it builds with --disable-precompiled-headers?
Thanks,
-Aleksey
From coleen.phillimore at oracle.com Fri Apr 6 13:31:00 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 6 Apr 2018 09:31:00 -0400
Subject: RR: 8201244: Clean out unnecessary includes of heap headers
In-Reply-To: <6f962c39-108b-32ca-fa43-830ae39e00f4@redhat.com>
References: <b47dd0b0-93e0-3e40-3318-d988d3f87481@oracle.com>
<6f962c39-108b-32ca-fa43-830ae39e00f4@redhat.com>
Message-ID: <aafeb1e1-1540-54ca-1d05-1f5e8baa5510@oracle.com>
On 4/6/18 9:29 AM, Aleksey Shipilev wrote:
> On 04/06/2018 03:23 PM, Stefan Karlsson wrote:
>> http://cr.openjdk.java.net/~stefank/8201244/webrev.01
> Looks fine. Have you checked it builds with --disable-precompiled-headers?
Agree, and open-only ?
thanks,
Coleen
>
> Thanks,
> -Aleksey
>
>
From shade at redhat.com Fri Apr 6 13:30:57 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 6 Apr 2018 15:30:57 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <bed78e55-5bc2-eea5-b0bd-cdf3160cf3e0@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<bed78e55-5bc2-eea5-b0bd-cdf3160cf3e0@physik.fu-berlin.de>
Message-ID: <2693c050-610b-53f7-f90e-e93bdda3dc27@redhat.com>
On 04/06/2018 03:23 PM, John Paul Adrian Glaubitz wrote:
> On 04/06/2018 03:16 PM, Zhengyu Gu wrote:
>> I think it is symptom, the real cause is:
>>
>> In CPUinfo constructor:
>>
>> _string = strdup(vstr);
>>
>> should be:
>>
>> _string = os::strdup(vstr, mtInternal);
>
> I changed that and now it seems I'm getting a different failure which
> is an assertion failure:
>
> # To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc:? SuppressErrorAt=/assembler_sparc.cpp:52
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #? Internal Error (/srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.cpp:52), pid=18170, tid=18201
> #? assert(!(is_cti(prev) && is_cti(insn))) failed: CTI-CTI not allowed.
Now, this looks like pipeline verification failure (enabled with ASSERT/VERIFY_PIPELINE). We need to
talk with SPARC compiler folks about this. I wonder if release build "works" now, without this
verification.
-Aleksey
From stefan.karlsson at oracle.com Fri Apr 6 13:41:08 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Fri, 6 Apr 2018 15:41:08 +0200
Subject: RR: 8201244: Clean out unnecessary includes of heap headers
In-Reply-To: <aafeb1e1-1540-54ca-1d05-1f5e8baa5510@oracle.com>
References: <b47dd0b0-93e0-3e40-3318-d988d3f87481@oracle.com>
<6f962c39-108b-32ca-fa43-830ae39e00f4@redhat.com>
<aafeb1e1-1540-54ca-1d05-1f5e8baa5510@oracle.com>
Message-ID: <d0ed3fea-78e4-aadb-f503-25bc357aa286@oracle.com>
On 2018-04-06 15:31, coleen.phillimore at oracle.com wrote:
>
>
> On 4/6/18 9:29 AM, Aleksey Shipilev wrote:
>> On 04/06/2018 03:23 PM, Stefan Karlsson wrote:
>>> http://cr.openjdk.java.net/~stefank/8201244/webrev.01
>> Looks fine. Have you checked it builds with
>> --disable-precompiled-headers?
>
> Agree, and open-only ?
Yes, to both of those questions. But I have a few changes in flux, so
I'll rerun when the time comes to push this.
Thanks,
StefanK
> thanks,
> Coleen
>>
>> Thanks,
>> -Aleksey
>>
>>
>
From christoph.langer at sap.com Fri Apr 6 15:01:41 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 6 Apr 2018 15:01:41 +0000
Subject: RFR (M): 8201247: Various cleanups in the attach framework
Message-ID: <14dff9b0cf5a4b888aef1d6452801b57@sap.com>
Hi,
can I please get reviews for a set of clean up changes that I came across when doing some integration work.
Bug: https://bugs.openjdk.java.net/browse/JDK-8201247
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/
Detailed comments about the changes can be found in the bug.
Thanks & best regards
Christoph
From erik.joelsson at oracle.com Fri Apr 6 15:23:36 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 6 Apr 2018 08:23:36 -0700
Subject: RFR: JDK-8201236 Straighten out dtrace build logic
In-Reply-To: <760d77ab-77c8-451a-2f02-fceaaeef38b8@oracle.com>
References: <760d77ab-77c8-451a-2f02-fceaaeef38b8@oracle.com>
Message-ID: <5de3a167-0df7-6bae-050e-333f3abccde6@oracle.com>
Looks good in general.
In JvmDtraceObjects.gmk, comment on line 38 needs to be updated.
/Erik
On 2018-04-06 03:57, Magnus Ihse Bursie wrote:
> The dtrace build logic was copied straight out of the old Hotspot
> build system, and is quite convoluted.
>
> It should be split into the separate parts it actually contains of:
> 1) A gensrc step which runs with other gensrc ahead of compilation
> 2) Two independent libraries that can be build at any time
> 3) Two special dtrace-generated .o files that must be linked with the JVM
>
> I have also cleaned up includes in generateJvmOffsets.cpp.
>
> I have verified with COMPARE_BUILD that no changes has happened in any
> native library.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201236
> WebRev:
> http://cr.openjdk.java.net/~ihse/JDK-8201236-straighten-out-dtrace/webrev.01
>
> /Magnus
From chris.plummer at oracle.com Fri Apr 6 16:37:09 2018
From: chris.plummer at oracle.com (Chris Plummer)
Date: Fri, 6 Apr 2018 09:37:09 -0700
Subject: RFR (M): 8201247: Various cleanups in the attach framework
In-Reply-To: <14dff9b0cf5a4b888aef1d6452801b57@sap.com>
References: <14dff9b0cf5a4b888aef1d6452801b57@sap.com>
Message-ID: <91d75e2d-47a4-e9ee-5d19-8f3e6dc13428@oracle.com>
Hi Christoph,
Can you explain a bit more about "fix handling of null values in
ArgumentIterator::next". When does this turn up? Is there a test case?
Everything else looks good.
thanks,
Chris
On 4/6/18 8:01 AM, Langer, Christoph wrote:
>
> Hi,
>
> can I please get reviews for a set of clean up changes that I came
> across when doing some integration work.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201247
> <https://bugs.openjdk.java.net/browse/JDK-8201247>
>
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/
> <http://cr.openjdk.java.net/%7Eclanger/webrevs/8201247.0/>
>
> Detailed comments about the changes can be found in the bug.
>
> Thanks & best regards
>
> Christoph
>
From coleen.phillimore at oracle.com Fri Apr 6 20:51:58 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 6 Apr 2018 16:51:58 -0400
Subject: RFR (XL) 8081519 Split globals.hpp to factor out the Flag class
In-Reply-To: <6656E162-56BE-4E75-8343-7567715F30C7@oracle.com>
References: <D6E4A4E8-8356-4694-BD9C-03AB5FA5BC65@oracle.com>
<6656E162-56BE-4E75-8343-7567715F30C7@oracle.com>
Message-ID: <eacc2551-1304-8819-907e-cdf3790e3783@oracle.com>
Gerard,
It looks like these files get the include jvmFlag.hpp transitively from
globals_ext.hpp, but can you add an explicit #include
"runtime/flags/jvmFlag.hpp" to the files that you've changed that don't
explicitly include jvmFlagsConstraintList.hpp and others?? The include
guards will prevent them from being included twice and it would be good
if we ever change these to not include globals_ext.hpp.? eg:
http://cr.openjdk.java.net/~gziemski/8081519_rev2/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp.udiff.html
For the others, it's more obvious that jvmFlags.hpp will be included
through jvmFlagConstraintList.hpp and the other jvmFlag* headers.
I still really like this cleanup!?? Besides this minor comment (changes
to several files you've already changed), it looks good!
Thanks,
Coleen
On 4/5/18 1:46 PM, Gerard Ziemski wrote:
> Hi all,
>
> Here is webrev 2 with the following additions:
>
> #1 Factor FlagSetting class out of "runtime/flags/jvmFlag.hpp" and into its own "runtime/flags/flagSetting.hpp", so that FlagSetting class can extend from ?public StackObj? (thanks Coleen)
>
> #2 change the hierarchy from ?runtime/jvmFlag/? to "runtime/flags/? (thanks David)
>
> #3 Fix the header files, so that both closed and open repository build with and without precompiled headers
>
> #4 Add ?runtime/flags/*.hpp? headers to ?precompiled.hpp?
>
> The number of touched files got even longer - sorry about that and big thank you for taking your time to review!
>
> Running final Mach5 hs_tier1-5 tests? (it passed earlier iterations). Passes local builds (on Mac OS X) with and without precompiled headers for both closed and open repos and both debug and product versions (should I try any other build varations?)
>
> http://cr.openjdk.java.net/~gziemski/8081519_rev2
>
>
> cheers
>
>> On Mar 29, 2018, at 2:01 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
>>
>> Hi all,
>>
>> Please review this large and tedious (sorry), but simple fix that accomplishes the following:
>>
>> #1 factor out the command option flag related APIs out of globals.hpp/.cpp into its own dedicated files, i.e. jvmFlag.hpp/.cpp
>> #2 merge Flag (too generic name) and CommandLineFlag classes and rename them as JVMFlag
>> #3 cleanup globals.hpp includes originally added by the JEP-245
>>
>> Note: the renamed file retain their history, but one needs to add ?follow? flag, ex. ?hg log -f file?
>>
>> https://bugs.openjdk.java.net/browse/JDK-8081519
>> http://cr.openjdk.java.net/~gziemski/8081519_rev1
>>
>> Passes Mach5 hs_tier1-tier5, jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges tests.
>>
>>
>> cheers
From vladimir.kozlov at oracle.com Fri Apr 6 22:48:50 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 6 Apr 2018 15:48:50 -0700
Subject: RFC: C2 Object Initialization - Using XMM/YMM registers
In-Reply-To: <CAPVMLfVxaDT2qvGaSzyC4pPxD1FNQ3zaGPhL+CNbRYS9PM1CsQ@mail.gmail.com>
References: <CAPVMLfVcpTXpaTeMwo0Gg=NgDpkz+Z2cD+FP7mw6iHJH5R-+nw@mail.gmail.com>
<f21029be-c4a7-8104-6d4b-e6bbd13525b9@oracle.com>
<CAPVMLfVxaDT2qvGaSzyC4pPxD1FNQ3zaGPhL+CNbRYS9PM1CsQ@mail.gmail.com>
Message-ID: <a89c5280-cd64-65d8-68fc-aa31e389f56a@oracle.com>
The OpenJDK rule said that you need to contribute at least 2 significant
cahgnes and sign OCA (Oracle Contribution agreement) before applying
for Author status. Fortunately AMD had signed up as company already
which cover all its employees.
http://openjdk.java.net/projects/#project-author
You contributed only one 8187219 so far as I know. Need one more.
But you should be able to see contents of RFE. Right?
I added text and data from your e-mail.
Thanks,
Vladimir
On 4/5/18 10:04 PM, Rohit Arul Raj wrote:
> On Thu, Apr 5, 2018 at 11:38 PM, Vladimir Kozlov
> <vladimir.kozlov at oracle.com> wrote:
>> Good suggestion, Rohit
>>
>> I created new RFE. Please add you suggestion and performance data there:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8201193
>>
>
> Thanks Vladimir.
> I don't have an account/access to JDK bug data base yet. Is there any
> other way around it?
> Can I send in a request for Author role?
>
> Regards,
> Rohit
>
>>
>> On 4/5/18 12:19 AM, Rohit Arul Raj wrote:
>>>
>>> Hi All,
>>>
>>> I was going through the C2 object initialization (zeroing) code based
>>> on the below bug entry:
>>> https://bugs.openjdk.java.net/browse/JDK-8146801
>>>
>>> Right now, for longer lengths we use "rep stos" instructions on x86. I
>>> was experimenting with using XMM/YMM registers (on AMD EPYC processor)
>>> and found that they do improve performance for certain lengths:
>>>
>>> For lengths > 64 bytes - 512 bytes : improvement is in the range of 8% to
>>> 44%
>>> For lengths > 512bytes : some lengths show slight
>>> improvement in the range of 2% to 7%, others almost same as "rep stos"
>>> numbers.
>>>
>>> I have attached the complete performance data (data.txt) for reference .
>>> Can we add this as an user option similar to UseXMMForArrayCopy?
>>>
>>> I have used the same test case as in
>>> (http://cr.openjdk.java.net/~shade/8146801/benchmarks.jar) with
>>> additional sizes.
>>>
>>> Initial Patch:
>>> I haven't added the check for 32-bit mode as I need some help with the
>>> code (description given below the patch).
>>> The code is similar to the one used in array copy stubs
>>> (copy_bytes_forward).
>>>
>>> diff --git a/src/hotspot/cpu/x86/globals_x86.hpp
>>> b/src/hotspot/cpu/x86/globals_x86.hpp
>>> --- a/src/hotspot/cpu/x86/globals_x86.hpp
>>> +++ b/src/hotspot/cpu/x86/globals_x86.hpp
>>> @@ -150,6 +150,9 @@
>>> product(bool, UseUnalignedLoadStores, false,
>>> \
>>> "Use SSE2 MOVDQU instruction for Arraycopy")
>>> \
>>>
>>> \
>>> + product(bool, UseXMMForObjInit, false,
>>> \
>>> + "Use XMM/YMM MOVDQU instruction for Object Initialization")
>>> \
>>> +
>>> \
>>> product(bool, UseFastStosb, false,
>>> \
>>> "Use fast-string operation for zeroing: rep stosb")
>>> \
>>>
>>> \
>>> diff --git a/src/hotspot/cpu/x86/macroAssembler_x86.cpp
>>> b/src/hotspot/cpu/x86/macroAssembler_x86.cpp
>>> --- a/src/hotspot/cpu/x86/macroAssembler_x86.cpp
>>> +++ b/src/hotspot/cpu/x86/macroAssembler_x86.cpp
>>> @@ -7106,6 +7106,56 @@
>>> if (UseFastStosb) {
>>> shlptr(cnt, 3); // convert to number of bytes
>>> rep_stosb();
>>> + } else if (UseXMMForObjInit && UseUnalignedLoadStores) {
>>> + Label L_loop, L_sloop, L_check, L_tail, L_end;
>>> + push(base);
>>> + if (UseAVX >= 2)
>>> + vpxor(xmm10, xmm10, xmm10, AVX_256bit);
>>> + else
>>> + vpxor(xmm10, xmm10, xmm10, AVX_128bit);
>>> +
>>> + jmp(L_check);
>>> +
>>> + BIND(L_loop);
>>> + if (UseAVX >= 2) {
>>> + vmovdqu(Address(base, 0), xmm10);
>>> + vmovdqu(Address(base, 32), xmm10);
>>> + } else {
>>> + movdqu(Address(base, 0), xmm10);
>>> + movdqu(Address(base, 16), xmm10);
>>> + movdqu(Address(base, 32), xmm10);
>>> + movdqu(Address(base, 48), xmm10);
>>> + }
>>> + addptr(base, 64);
>>> +
>>> + BIND(L_check);
>>> + subptr(cnt, 8);
>>> + jccb(Assembler::greaterEqual, L_loop);
>>> + addptr(cnt, 4);
>>> + jccb(Assembler::less, L_tail);
>>> + // Copy trailing 32 bytes
>>> + if (UseAVX >= 2) {
>>> + vmovdqu(Address(base, 0), xmm10);
>>> + } else {
>>> + movdqu(Address(base, 0), xmm10);
>>> + movdqu(Address(base, 16), xmm10);
>>> + }
>>> + addptr(base, 32);
>>> + subptr(cnt, 4);
>>> +
>>> + BIND(L_tail);
>>> + addptr(cnt, 4);
>>> + jccb(Assembler::lessEqual, L_end);
>>> + decrement(cnt);
>>> +
>>> + BIND(L_sloop);
>>> + movptr(Address(base, 0), tmp);
>>> + addptr(base, 8);
>>> + decrement(cnt);
>>> + jccb(Assembler::greaterEqual, L_sloop);
>>> +
>>> + BIND(L_end);
>>> + pop(base);
>>> } else {
>>> NOT_LP64(shlptr(cnt, 1);) // convert to number of 32-bit words
>>> for 32-bit VM
>>> rep_stos();
>>>
>>>
>>> When I use XMM0 as a temporary register, the micro-benchmark crashes.
>>> Saving and Restoring the XMM0 register before and after use works
>>> fine.
>>>
>>> Looking at the "hotspot/src/cpu/x86/vm/x86.ad" file, XMM0 as with
>>> other XMM registers has been mentioned as Save-On-Call registers and
>>> on Linux ABI, no register is preserved across function calls though
>>> XMM0-XMM7 might hold parameters. So I assumed using XMM0 without
>>> saving/restoring should be fine.
>>>
>>> Is it incorrect use XMM* registers without saving/restoring them?
>>> Using XMM10 register as temporary register works fine without having
>>> to save and restore it.
>>>
>>> Please let me know your comments.
>>>
>>> Regards,
>>> Rohit
>>>
>>
From rohitarulraj at gmail.com Fri Apr 6 23:40:59 2018
From: rohitarulraj at gmail.com (Rohit Arul Raj)
Date: Sat, 7 Apr 2018 05:10:59 +0530
Subject: RFC: C2 Object Initialization - Using XMM/YMM registers
In-Reply-To: <a89c5280-cd64-65d8-68fc-aa31e389f56a@oracle.com>
References: <CAPVMLfVcpTXpaTeMwo0Gg=NgDpkz+Z2cD+FP7mw6iHJH5R-+nw@mail.gmail.com>
<f21029be-c4a7-8104-6d4b-e6bbd13525b9@oracle.com>
<CAPVMLfVxaDT2qvGaSzyC4pPxD1FNQ3zaGPhL+CNbRYS9PM1CsQ@mail.gmail.com>
<a89c5280-cd64-65d8-68fc-aa31e389f56a@oracle.com>
Message-ID: <CAPVMLfUyTGL149RrSo+645Fapfy0G_9THvygGv3hb1VNd4Mr1Q@mail.gmail.com>
On Sat, Apr 7, 2018 at 4:18 AM, Vladimir Kozlov
<vladimir.kozlov at oracle.com> wrote:
> The OpenJDK rule said that you need to contribute at least 2 significant
> cahgnes and sign OCA (Oracle Contribution agreement) before applying for
> Author status. Fortunately AMD had signed up as company already which cover
> all its employees.
>
> http://openjdk.java.net/projects/#project-author
>
> You contributed only one 8187219 so far as I know. Need one more.
>
> But you should be able to see contents of RFE. Right?
Thanks Vladimir, I can see the contents of RFE.
Regards,
Rohit
> On 4/5/18 10:04 PM, Rohit Arul Raj wrote:
>>
>> On Thu, Apr 5, 2018 at 11:38 PM, Vladimir Kozlov
>> <vladimir.kozlov at oracle.com> wrote:
>>>
>>> Good suggestion, Rohit
>>>
>>> I created new RFE. Please add you suggestion and performance data there:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8201193
>>>
>>
>> Thanks Vladimir.
>> I don't have an account/access to JDK bug data base yet. Is there any
>> other way around it?
>> Can I send in a request for Author role?
>>
>> Regards,
>> Rohit
>>
>>>
>>> On 4/5/18 12:19 AM, Rohit Arul Raj wrote:
>>>>
>>>>
>>>> Hi All,
>>>>
>>>> I was going through the C2 object initialization (zeroing) code based
>>>> on the below bug entry:
>>>> https://bugs.openjdk.java.net/browse/JDK-8146801
>>>>
>>>> Right now, for longer lengths we use "rep stos" instructions on x86. I
>>>> was experimenting with using XMM/YMM registers (on AMD EPYC processor)
>>>> and found that they do improve performance for certain lengths:
>>>>
>>>> For lengths > 64 bytes - 512 bytes : improvement is in the range of 8%
>>>> to
>>>> 44%
>>>> For lengths > 512bytes : some lengths show slight
>>>> improvement in the range of 2% to 7%, others almost same as "rep stos"
>>>> numbers.
>>>>
>>>> I have attached the complete performance data (data.txt) for reference .
>>>> Can we add this as an user option similar to UseXMMForArrayCopy?
>>>>
>>>> I have used the same test case as in
>>>> (http://cr.openjdk.java.net/~shade/8146801/benchmarks.jar) with
>>>> additional sizes.
>>>>
>>>> Initial Patch:
>>>> I haven't added the check for 32-bit mode as I need some help with the
>>>> code (description given below the patch).
>>>> The code is similar to the one used in array copy stubs
>>>> (copy_bytes_forward).
>>>>
>>>> diff --git a/src/hotspot/cpu/x86/globals_x86.hpp
>>>> b/src/hotspot/cpu/x86/globals_x86.hpp
>>>> --- a/src/hotspot/cpu/x86/globals_x86.hpp
>>>> +++ b/src/hotspot/cpu/x86/globals_x86.hpp
>>>> @@ -150,6 +150,9 @@
>>>> product(bool, UseUnalignedLoadStores, false,
>>>> \
>>>> "Use SSE2 MOVDQU instruction for Arraycopy")
>>>> \
>>>>
>>>> \
>>>> + product(bool, UseXMMForObjInit, false,
>>>> \
>>>> + "Use XMM/YMM MOVDQU instruction for Object Initialization")
>>>> \
>>>> +
>>>> \
>>>> product(bool, UseFastStosb, false,
>>>> \
>>>> "Use fast-string operation for zeroing: rep stosb")
>>>> \
>>>>
>>>> \
>>>> diff --git a/src/hotspot/cpu/x86/macroAssembler_x86.cpp
>>>> b/src/hotspot/cpu/x86/macroAssembler_x86.cpp
>>>> --- a/src/hotspot/cpu/x86/macroAssembler_x86.cpp
>>>> +++ b/src/hotspot/cpu/x86/macroAssembler_x86.cpp
>>>> @@ -7106,6 +7106,56 @@
>>>> if (UseFastStosb) {
>>>> shlptr(cnt, 3); // convert to number of bytes
>>>> rep_stosb();
>>>> + } else if (UseXMMForObjInit && UseUnalignedLoadStores) {
>>>> + Label L_loop, L_sloop, L_check, L_tail, L_end;
>>>> + push(base);
>>>> + if (UseAVX >= 2)
>>>> + vpxor(xmm10, xmm10, xmm10, AVX_256bit);
>>>> + else
>>>> + vpxor(xmm10, xmm10, xmm10, AVX_128bit);
>>>> +
>>>> + jmp(L_check);
>>>> +
>>>> + BIND(L_loop);
>>>> + if (UseAVX >= 2) {
>>>> + vmovdqu(Address(base, 0), xmm10);
>>>> + vmovdqu(Address(base, 32), xmm10);
>>>> + } else {
>>>> + movdqu(Address(base, 0), xmm10);
>>>> + movdqu(Address(base, 16), xmm10);
>>>> + movdqu(Address(base, 32), xmm10);
>>>> + movdqu(Address(base, 48), xmm10);
>>>> + }
>>>> + addptr(base, 64);
>>>> +
>>>> + BIND(L_check);
>>>> + subptr(cnt, 8);
>>>> + jccb(Assembler::greaterEqual, L_loop);
>>>> + addptr(cnt, 4);
>>>> + jccb(Assembler::less, L_tail);
>>>> + // Copy trailing 32 bytes
>>>> + if (UseAVX >= 2) {
>>>> + vmovdqu(Address(base, 0), xmm10);
>>>> + } else {
>>>> + movdqu(Address(base, 0), xmm10);
>>>> + movdqu(Address(base, 16), xmm10);
>>>> + }
>>>> + addptr(base, 32);
>>>> + subptr(cnt, 4);
>>>> +
>>>> + BIND(L_tail);
>>>> + addptr(cnt, 4);
>>>> + jccb(Assembler::lessEqual, L_end);
>>>> + decrement(cnt);
>>>> +
>>>> + BIND(L_sloop);
>>>> + movptr(Address(base, 0), tmp);
>>>> + addptr(base, 8);
>>>> + decrement(cnt);
>>>> + jccb(Assembler::greaterEqual, L_sloop);
>>>> +
>>>> + BIND(L_end);
>>>> + pop(base);
>>>> } else {
>>>> NOT_LP64(shlptr(cnt, 1);) // convert to number of 32-bit words
>>>> for 32-bit VM
>>>> rep_stos();
>>>>
>>>>
>>>> When I use XMM0 as a temporary register, the micro-benchmark crashes.
>>>> Saving and Restoring the XMM0 register before and after use works
>>>> fine.
>>>>
>>>> Looking at the "hotspot/src/cpu/x86/vm/x86.ad" file, XMM0 as with
>>>> other XMM registers has been mentioned as Save-On-Call registers and
>>>> on Linux ABI, no register is preserved across function calls though
>>>> XMM0-XMM7 might hold parameters. So I assumed using XMM0 without
>>>> saving/restoring should be fine.
>>>>
>>>> Is it incorrect use XMM* registers without saving/restoring them?
>>>> Using XMM10 register as temporary register works fine without having
>>>> to save and restore it.
>>>>
>>>> Please let me know your comments.
>>>>
>>>> Regards,
>>>> Rohit
>>>>
>>>
>
From kim.barrett at oracle.com Fri Apr 6 23:55:08 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 6 Apr 2018 19:55:08 -0400
Subject: RFR: 8200550: Xcode 9.3 produce warning on heapRegionSet.hpp
Message-ID: <0734D26B-5E3D-45A1-8321-23896819851A@oracle.com>
Please review this fix of a couple of macro definitions that have
"defined" expressions in the expansion. Such code has undefined
behavior: C++03 16.1/3. Xcode 9.3 warns about such code.
The fix for HEAP_REGION_SET_FORCE_VERIFY is a straight-forward change
to use #ifdef ASSERT to define it appropriately.
The fix for TAIL_CALL is more interesting. The code previously
involved "defined(WINDOWS)". It turns out we don't define WINDOWS!
The correct macro to test is _WINDOWS.
Because WINDOWS is not defined when building for Windows, one might
think the conditional would go the wrong way. But with the old
definition of TAIL_CALL, Visual Studio was deciding that "#if
!TAIL_CALL" should be selected anyway; it seems to be interpreting the
expression in some unexpected way that accidentally produced the
result we wanted. (Since it's undefined behavior, it can do
anything.)
I also fixed vmError.cpp's incorrect "#ifdef WINDOWS" to use _WINDOWS.
CR:
https://bugs.openjdk.java.net/browse/JDK-8200550
Webrev:
http://cr.openjdk.java.net/~kbarrett/8200550/open.00/
Testing:
{jdk,hs}-tier{1,2,3} on all Oracle supported platforms.
Note that hs-tier2 contains NMT/CheckForProperDetailStackTrace, which
specifically tests the nativeCallStack code being modified here.
From zgu at redhat.com Sat Apr 7 02:35:49 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Fri, 6 Apr 2018 22:35:49 -0400
Subject: RFR 8199868: Support JNI critical functions in object pinning API
In-Reply-To: <bca06cab-610e-c46c-a51d-175a18138cfc@redhat.com>
References: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com>
<bca06cab-610e-c46c-a51d-175a18138cfc@redhat.com>
Message-ID: <19c791e7-1bf8-69ef-7090-b7da800f2021@redhat.com>
Offline discussion with Aleksey, he suggested that
pin/unpin_critical_native_array methods can be made more generic as
pin/unpin_object.
Updated webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.01/
Test:
Reran all tests, submit-hs tests still clean.
Thanks,
-Zhengyu
On 04/06/2018 08:55 AM, Aleksey Shipilev wrote:
> On 04/04/2018 07:47 PM, Zhengyu Gu wrote:
>> Please review this patch that adds JNI critical native support to object pinning.
>>
>> Shenandoah does not block GC while JNI critical session is in progress. This patch allows it to pin
>> all incoming array objects before critical native call, and unpin them after call completes.
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199868
>> Webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.00/
>
> Looks good to me, but somebody more savvy with runtime stub generation should take a closer look.
>
> *) Should probably be "Why we are here?"
>
> 2867 assert(Universe::heap()->supports_object_pinning(), "Why we here?");
>
> 2876 assert(Universe::heap()->supports_object_pinning(), "Why we here?");
>
>
> Thanks,
> -Aleksey
>
From markus.gronlund at oracle.com Sat Apr 7 10:28:53 2018
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Sat, 7 Apr 2018 03:28:53 -0700 (PDT)
Subject: JEP 328 : Flight Recorder open source preview
Message-ID: <687dbe1f-80dc-46ff-9f9f-da03687322e6@default>
Greetings,
This is a preview of a large part of the source code for JEP 328 : Flight Recorder[1].
Webrev: http://cr.openjdk.java.net/~mgronlun/JEP328_FlightRecorder/Preview/webrev/index.html
It has been tested on the following platforms:
* Linux-x64
* Windows-x64
* MacOSX-x64
We are planning to send out the code for full review in a couple of weeks.
At this point, we are preparing changes to move to a single backend, as suggested in the JEP.
These will encompass the following:
1. Rename macro INCLUDE_TRACE to INCLUDE_JFR.
2. Remove flag -XX:[+|-]EnableTracing.
3. Cleanup unused elements and attributes by restructuring the trace xml files.
4. Move code under hotspot/share/trace to hotspot/share/jfr/metadata.
Thank you
Markus and Erik
[1] http://openjdk.java.net/jeps/328
PS the patch was generated from the hs repository [2] using change [3] as parent.
[2] http://hg.openjdk.java.net/jdk/hs
[3] changeset: 49618:947560700a09
user: stefank
date: Fri Apr 06 13:55:25 2018 +0200
summary: 8201136: Move GC flags from globals.hpp to GC specific files
From thomas.schatzl at oracle.com Sat Apr 7 11:03:03 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Sat, 07 Apr 2018 13:03:03 +0200
Subject: RFR: 8200550: Xcode 9.3 produce warning on heapRegionSet.hpp
In-Reply-To: <0734D26B-5E3D-45A1-8321-23896819851A@oracle.com>
References: <0734D26B-5E3D-45A1-8321-23896819851A@oracle.com>
Message-ID: <1523098983.2294.7.camel@oracle.com>
Hi Kim,
On Fri, 2018-04-06 at 19:55 -0400, Kim Barrett wrote:
> Please review this fix of a couple of macro definitions that have
> "defined" expressions in the expansion. Such code has undefined
> behavior: C++03 16.1/3. Xcode 9.3 warns about such code.
>
> The fix for HEAP_REGION_SET_FORCE_VERIFY is a straight-forward change
> to use #ifdef ASSERT to define it appropriately.
It would imho be much nicer to remove the define and use the available
NOT_DEBUG_RETURN/#ifndef ASSERT macros to accomplish the same thing. (I would also be fine with using NOT_PRODUCT_RETURN/#ifndef PRODUCT).
> The fix for TAIL_CALL is more interesting. The code previously
> involved "defined(WINDOWS)". It turns out we don't define WINDOWS!
> The correct macro to test is _WINDOWS.
Please update the CR subject because this is not about
heapRegionSet.hpp alone any more before pushing.
> Because WINDOWS is not defined when building for Windows, one might
> think the conditional would go the wrong way. But with the old
> definition of TAIL_CALL, Visual Studio was deciding that "#if
> !TAIL_CALL" should be selected anyway; it seems to be interpreting
> the expression in some unexpected way that accidentally produced the
> result we wanted. (Since it's undefined behavior, it can do
> anything.)
>
> I also fixed vmError.cpp's incorrect "#ifdef WINDOWS" to use
> _WINDOWS.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8200550
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8200550/open.00/
looks good otherwise.
Thanks,
Thomas
From kim.barrett at oracle.com Sat Apr 7 19:48:45 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Sat, 7 Apr 2018 15:48:45 -0400
Subject: RFR: 8200550: Xcode 9.3 produce warning on heapRegionSet.hpp
In-Reply-To: <1523098983.2294.7.camel@oracle.com>
References: <0734D26B-5E3D-45A1-8321-23896819851A@oracle.com>
<1523098983.2294.7.camel@oracle.com>
Message-ID: <F5144B4C-CC79-44DE-8FA4-9D96B69C86B2@oracle.com>
> On Apr 7, 2018, at 7:03 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
>
> Hi Kim,
>
> On Fri, 2018-04-06 at 19:55 -0400, Kim Barrett wrote:
>> Please review this fix of a couple of macro definitions that have
>> "defined" expressions in the expansion. Such code has undefined
>> behavior: C++03 16.1/3. Xcode 9.3 warns about such code.
>>
>> The fix for HEAP_REGION_SET_FORCE_VERIFY is a straight-forward change
>> to use #ifdef ASSERT to define it appropriately.
>
> It would imho be much nicer to remove the define and use the available
> NOT_DEBUG_RETURN/#ifndef ASSERT macros to accomplish the same thing. (I would also be fine with using NOT_PRODUCT_RETURN/#ifndef PRODUCT).
That doesn?t accomplish the same thing. The present code allows one to explicitly
define the macro on the (make) command line to override the default behavior
(based on ASSERT). Are you suggesting removing that capability?
NOT_PRODUCT/#ifndef PRODUCT is the wrong choice, being contrary to to the
intent of an optimize build to be similar in performance characteristics to a product
build.
>> The fix for TAIL_CALL is more interesting. The code previously
>> involved "defined(WINDOWS)". It turns out we don't define WINDOWS!
>> The correct macro to test is _WINDOWS.
>
> Please update the CR subject because this is not about
> heapRegionSet.hpp alone any more before pushing.
Done.
From kim.barrett at oracle.com Sat Apr 7 19:54:41 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Sat, 7 Apr 2018 15:54:41 -0400
Subject: RFR: 8200697: Add utility for spin wait with fallback to
yield/sleep
In-Reply-To: <c0758ba9-a647-f6e4-2b21-b47f3fc15a42@oracle.com>
References: <E1CA91CD-9CF6-44D5-A7B7-0747AA648D65@oracle.com>
<c0758ba9-a647-f6e4-2b21-b47f3fc15a42@oracle.com>
Message-ID: <DF998C96-90E3-48C0-908F-E667B2F4A6BC@oracle.com>
> On Apr 4, 2018, at 7:42 PM, David Holmes <david.holmes at oracle.com> wrote:
>
> Hi Kim,
>
> If this works you for then by all means use it.
Thanks.
> Whether it is useful as a general utility is something I am doubtful of. Degrading spin-loops are put in for performance reasons and generally have to interact with surrounding code that captures exactly what is being waited upon. There is also the issue of thread-state transitions that need to be carefully managed.
Agreed that this is of limited use. But since Robbin and I came up
with similar approaches, and both were based on examples already in
HotSpot, we decided to package it up.
From thomas.schatzl at oracle.com Sat Apr 7 21:24:23 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Sat, 07 Apr 2018 23:24:23 +0200
Subject: RFR: 8200550: Xcode 9.3 produce warning on heapRegionSet.hpp
In-Reply-To: <F5144B4C-CC79-44DE-8FA4-9D96B69C86B2@oracle.com>
References: <0734D26B-5E3D-45A1-8321-23896819851A@oracle.com>
<1523098983.2294.7.camel@oracle.com>
<F5144B4C-CC79-44DE-8FA4-9D96B69C86B2@oracle.com>
Message-ID: <1523136263.2260.39.camel@oracle.com>
Hi,
On Sat, 2018-04-07 at 15:48 -0400, Kim Barrett wrote:
> > On Apr 7, 2018, at 7:03 AM, Thomas Schatzl <thomas.schatzl at oracle.c
> > om> wrote:
> >
> > Hi Kim,
> >
> > On Fri, 2018-04-06 at 19:55 -0400, Kim Barrett wrote:
> > > Please review this fix of a couple of macro definitions that have
> > > "defined" expressions in the expansion. Such code has undefined
> > > behavior: C++03 16.1/3. Xcode 9.3 warns about such code.
> > >
> > > The fix for HEAP_REGION_SET_FORCE_VERIFY is a straight-forward
> > > change to use #ifdef ASSERT to define it appropriately.
> >
> > It would imho be much nicer to remove the define and use the
> > available NOT_DEBUG_RETURN/#ifndef ASSERT macros to accomplish the
> > same thing. (I would also be fine with using
> > NOT_PRODUCT_RETURN/#ifndef
> > PRODUCT).
>
> That doesn?t accomplish the same thing. The present code allows one
> to explicitly define the macro on the (make) command line to override
> the default behavior (based on ASSERT). Are you suggesting removing
> that capability?
I have never anyone seen anyone using extra defines on the command line
and I am very certain I have never used them myselves, but maybe it
is common to do for others.
I can imagine people using them for initial development, and then
leaving them in "just in case", forgetting them rather quickly. This
and others are certainly not documented anywhere.
It is also really easy to forget to remember to always specify the
correct defines, i.e. be sure that the build actually contains this
code too.
That particular define has been introduced in 2011 and like many other
defines/paranoia checks/* in G1 code we removed over time this one
seems to duplicate the suggested (PRODUCT_RETURN / NOT_DEBUG_RETURN)
functionality.
(Actually tbh, I have heard of HEAP_REGION_SET_FORCE_VERIFY for the
very first time. The heapRegionSet* files are very old parts of G1).
Maybe Tony can comment.
> NOT_PRODUCT/#ifndef PRODUCT is the wrong choice, being contrary to to
> the intent of an optimize build to be similar in performance
> characteristics to a product build.
In my understanding there is an additional clause in that sentence:
"[...] to a product build, including some extra verification".
There is lots of similar verification that uses PRODUCT_RETURN/#ifndef
PRODUCT that also already changes performance characteristics for an
optimized build.
See the other PRODUCT_RETURN uses (I can find 107 in just the gc
directory) in this and other files.
So yes, I recommend removing this capability in this instance. This
verification does not seem to be any different than any other.
Not sure if this capability is too expensive or not (this is typically
a bit fuzzy), but in the worst case one can use NOT_DEBUG_RETURN.
> > > The fix for TAIL_CALL is more interesting. The code previously
> > > involved "defined(WINDOWS)". It turns out we don't define
> > > WINDOWS!
> > > The correct macro to test is _WINDOWS.
> >
> > Please update the CR subject because this is not about
> > heapRegionSet.hpp alone any more before pushing.
>
> Done.
>
Thanks,
Thomas
From simon at cjnash.com Sun Apr 8 14:30:04 2018
From: simon at cjnash.com (Simon Nash)
Date: Sun, 08 Apr 2018 15:30:04 +0100
Subject: Supported platforms (was: Re: Execution problems with Atomic
Operations on OpenJDK10 for ARM5 Soft Float)
In-Reply-To: <5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
<15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
<5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
Message-ID: <5ACA276C.7030505@cjnash.com>
On 05/04/2018 02:26, bren at juanantonio.info wrote:
>
> Many thanks with the link about the Platforms supported:
> http://www.oracle.com/technetwork/java/javase/documentation/jdk10certconfig-4417031.html
>
This appears to be a list of the platforms that are supported (certified) by
Oracle. Where can I find the list of platforms that are supported by
OpenJDK? For example, what about the following platforms that don't appear
on the Oracle list:
Windows x86
Linux x86
aarch32 (ARMv7 32-bit)
aarch64 (ARMv8 64-bit)
Are all these supported for OpenJDK 9, 10 and 11?
Simon
From david.holmes at oracle.com Sun Apr 8 21:39:30 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Apr 2018 07:39:30 +1000
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
Message-ID: <f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
On 6/04/2018 11:16 PM, Zhengyu Gu wrote:
> I think it is symptom, the real cause is:
>
> In CPUinfo constructor:
>
> _string = strdup(vstr);
>
> should be:
>
> _string = os::strdup(vstr, mtInternal);
There's definitely a mismatch there. But I think there is also a real
problem that we may end up in code that requires an attached thread and
we don't have one yet. I'd be more inclined to change the os::free to a
::free
David
> -Zhengyu
>
>
> On 04/06/2018 09:12 AM, Aleksey Shipilev wrote:
>> I would say dig here:
>>
>> On 04/06/2018 03:02 PM, John Paul Adrian Glaubitz wrote:
>>> #20 0xffff8001010e5d74 in report_vm_error (file=0xffff800101f3fd58
>>> detail_fmt=0xffff800101f3fd00 "Thread::current() called on detached
>>> thread") at
>>> #21 0xffff800101a48fc0 in Thread::current () at
>>> /srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp:720
>>> #22 ResourceMark::ResourceMark (this=0xffff800102638600) at
>>> /srv/openjdk/hs/src/hotspot/share/memory/resourceArea.hpp:109
>>> #23 verify_memory (ptr=ptr at entry=0xffff80010400fda0) at
>>> /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:632
>>> #24 0xffff800101a4ea74 in os::free (memblock=0xffff80010400fda0) at
>>> /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:783
>>> #25 0xffff800101ee9df0 in CPUinfo::~CPUinfo (this=0xffff800102638888,
>>> __in_chrg=<optimized out>) at
>>> /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:59
>>>
>>> #26 VM_Version::platform_features () at
>>> /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:184
>>>
>>> #27 0xffff800101eea080 in VM_Version::determine_features () at
>>> #28 0xffff800101da1ed0 in Threads::create_vm
>>> (args=args at entry=0xffff800102638d78,
>>> canTryAgain=canTryAgain at entry=0xffff800102638c57) at
>>> /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:3637
>>> #29 0xffff800101570a78 in JNI_CreateJavaVM_inner
>>> (args=0xffff800102638d78, penv=0xffff800102638d70,
>>> vm=0xffff800102638d68) at
>>> /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:3929
>>> #30 JNI_CreateJavaVM (vm=0xffff800102638d68, penv=0xffff800102638d70,
>>> args=0xffff800102638d78) at
>>> /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:4024
>>> #31 0xffff8001003bfa74 in InitializeJVM (ifn=<synthetic pointer>,
>>> penv=0xffff800102638d70, pvm=0xffff800102638d68) at
>>> /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:1478
>>> #32 JavaMain (_args=<optimized out>) at
>>> /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:411
>>> #33 0xffff8001002a3874 in start_thread (arg=0xffff800102639910) at
>>> pthread_create.c:463
>>> #34 0xffff8001006bf140 in __thread_start () at
>>> ../sysdeps/unix/sysv/linux/sparc/sparc64/clone.S:78
>>> Backtrace stopped: previous frame identical to this frame (corrupt
>>> stack?)
>>
>> I think this means we are trying to use Resource area before the
>> thread is fully initialized. IIRC
>> that is forbidden. Looking at os::verify_memory:
>>
>> static void verify_memory(void* ptr) { // <--- frame #23
>> ?? GuardedMemory guarded(ptr);
>> ?? if (!guarded.verify_guards()) {
>> ???? LogTarget(Warning, malloc, free) lt;
>> ???? ResourceMark rm; // <--- frame #22
>> ???? LogStream ls(lt);
>> ???? ls.print_cr("## nof_mallocs = " UINT64_FORMAT ", nof_frees = "
>> UINT64_FORMAT...
>> ???? ls.print_cr("## memory stomp:");
>> ???? guarded.print_on(&ls);
>> ???? fatal("memory stomping error");
>> ?? }
>> }
>>
>> It seems we have *failed* the guarded memory check, entered the
>> branch, and then failed reporting
>> the failure. This must mean buffer overrun somewhere?
>>
>> Thanks,
>> -Aleksey
>>
From glaubitz at physik.fu-berlin.de Sun Apr 8 22:02:01 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 9 Apr 2018 00:02:01 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
Message-ID: <038e8652-ec32-e2ae-9b10-b683ac81fd54@physik.fu-berlin.de>
On 04/08/2018 11:39 PM, David Holmes wrote:> I'd be more inclined to change the os::free to a ::free
This leads to an abort() because a pointer is freed that's not allocated.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From david.holmes at oracle.com Sun Apr 8 22:05:08 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Apr 2018 08:05:08 +1000
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <038e8652-ec32-e2ae-9b10-b683ac81fd54@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<038e8652-ec32-e2ae-9b10-b683ac81fd54@physik.fu-berlin.de>
Message-ID: <57e8037f-5b4d-e0bc-d8c3-7fc8b9f93c4c@oracle.com>
On 9/04/2018 8:02 AM, John Paul Adrian Glaubitz wrote:
> On 04/08/2018 11:39 PM, David Holmes wrote:> I'd be more inclined to change the os::free to a ::free
> This leads to an abort() because a pointer is freed that's not allocated.
??
_string = strdup(vstr);
David
> Adrian
>
From glaubitz at physik.fu-berlin.de Sun Apr 8 22:11:45 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 9 Apr 2018 00:11:45 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <57e8037f-5b4d-e0bc-d8c3-7fc8b9f93c4c@oracle.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<038e8652-ec32-e2ae-9b10-b683ac81fd54@physik.fu-berlin.de>
<57e8037f-5b4d-e0bc-d8c3-7fc8b9f93c4c@oracle.com>
Message-ID: <2c38917e-41ca-cf7a-68bd-7f996bea8c76@physik.fu-berlin.de>
On 04/09/2018 12:05 AM, David Holmes wrote:
> On 9/04/2018 8:02 AM, John Paul Adrian Glaubitz wrote:
>> On 04/08/2018 11:39 PM, David Holmes wrote:> I'd be more inclined to change the os::free to a ::free
>> This leads to an abort() because a pointer is freed that's not allocated.
>
> ??
>
> ?_string = strdup(vstr);
I'm a bit confused as well. I just did a "hg pull && hg update --clean" and
applied just Zhengyu's change. Now rebuilding.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From kim.barrett at oracle.com Mon Apr 9 05:19:59 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 9 Apr 2018 01:19:59 -0400
Subject: RFR: 8200697: Add utility for spin wait with fallback to
yield/sleep
In-Reply-To: <6ed25248-9d20-970f-2bf9-de56fe9b5a14@oracle.com>
References: <E1CA91CD-9CF6-44D5-A7B7-0747AA648D65@oracle.com>
<6ed25248-9d20-970f-2bf9-de56fe9b5a14@oracle.com>
Message-ID: <CEF91D81-E616-46EE-91A1-EBBA3537A878@oracle.com>
> On Apr 4, 2018, at 3:33 PM, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>
> On 4/4/18 2:53 PM, Kim Barrett wrote:
>> Please review this addition of SpinYield utility class.
>>
>> It initially supplies a very simple policy: spin a configured number
>> of times, then switch to yielding or (eventually) sleeping. Other
>> policies may replace this one or be provided as alternatives in the
>> future.
>>
>> This is joint work with Robbin Ehn.
>>
>> Robbin and I have immediate uses for this utility in changes we are
>> developing. In addition, there are some existing places that might be
>> converted to use this utility (or perhaps some extended version of
>> it), including SafepointSynchronize::begin, ReadStableMark,
>> Thread::SpinAcquire, and ParallelTaskTerminator::offer_termination.
>> Those existing potential uses are not being changed here; for now,
>> we're just adding the utility in support of our in-development
>> changes. We plan to file followup RFEs to consider converting those
>> potential uses.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8200697
>>
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8200697/open.00/
>
> src/hotspot/share/utilities/spinYield.cpp
> L35: _spin_limit(os::is_MP() ? spin_limit : 0),
> Do you want to mention in the .hpp file that spin_limit
> only has meaning when os::is_MP() == true?
Done.
> L45: os::naked_short_sleep(1);
> Hmmm... I have a vague memory of a 10ms lower limit for
> sleeps on at least some versions of Win*. I realize that
> naked_short_sleep() doesn't complain, but does that break
> anything in your assumptions?
I don't think so. The way this sort of thing gets used, a call to
sleep is assumed to delay for "a long time" compared to the typical
delay, which ought to fall well within the spin period. Sleeping
generally means whatever event we're waiting for has missed our
latency goal.
> src/hotspot/share/utilities/spinYield.hpp
> No comments other than whether you want to talk about limitations
> in the .hpp file?
>
> test/hotspot/gtest/utilities/test_spinYield.cpp
> No comments.
>
> Thumbs up.
Thanks.
> Dan
> P.S.
> I think we've still got some spin/yield stuff in Java monitors
> and/or Mutexes so this could probably be used there also...
>
>
>>
>> Testing:
>> Added unit test of basic functionality.
>> Build and hs-tier1 (for gtest) on all Oracle platforms.
From kim.barrett at oracle.com Mon Apr 9 06:55:49 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 9 Apr 2018 02:55:49 -0400
Subject: RFR: 8200550: Xcode 9.3 produce warning on heapRegionSet.hpp
In-Reply-To: <1523136263.2260.39.camel@oracle.com>
References: <0734D26B-5E3D-45A1-8321-23896819851A@oracle.com>
<1523098983.2294.7.camel@oracle.com>
<F5144B4C-CC79-44DE-8FA4-9D96B69C86B2@oracle.com>
<1523136263.2260.39.camel@oracle.com>
Message-ID: <1D3A3B61-7BC0-4A6E-B084-F2AAF464CEBE@oracle.com>
> On Apr 7, 2018, at 5:24 PM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
>
> Hi,
>
> On Sat, 2018-04-07 at 15:48 -0400, Kim Barrett wrote:
>>> On Apr 7, 2018, at 7:03 AM, Thomas Schatzl <thomas.schatzl at oracle.c
>>> om> wrote:
>>>
>>> Hi Kim,
>>>
>>> On Fri, 2018-04-06 at 19:55 -0400, Kim Barrett wrote:
>>>> Please review this fix of a couple of macro definitions that have
>>>> "defined" expressions in the expansion. Such code has undefined
>>>> behavior: C++03 16.1/3. Xcode 9.3 warns about such code.
>>>>
>>>> The fix for HEAP_REGION_SET_FORCE_VERIFY is a straight-forward
>>>> change to use #ifdef ASSERT to define it appropriately.
>>>
>>> It would imho be much nicer to remove the define and use the
>>> available NOT_DEBUG_RETURN/#ifndef ASSERT macros to accomplish the
>>> same thing. (I would also be fine with using
>>> NOT_PRODUCT_RETURN/#ifndef
>>> PRODUCT).
>>
>> That doesn?t accomplish the same thing. The present code allows one
>> to explicitly define the macro on the (make) command line to override
>> the default behavior (based on ASSERT). Are you suggesting removing
>> that capability?
>
> I have never anyone seen anyone using extra defines on the command line
> and I am very certain I have never used them myselves, but maybe it
> is common to do for others.
> I can imagine people using them for initial development, and then
> leaving them in "just in case", forgetting them rather quickly. This
> and others are certainly not documented anywhere.
>
> It is also really easy to forget to remember to always specify the
> correct defines, i.e. be sure that the build actually contains this
> code too.
>
> That particular define has been introduced in 2011 and like many other
> defines/paranoia checks/* in G1 code we removed over time this one
> seems to duplicate the suggested (PRODUCT_RETURN / NOT_DEBUG_RETURN)
> functionality.
>
> (Actually tbh, I have heard of HEAP_REGION_SET_FORCE_VERIFY for the
> very first time. The heapRegionSet* files are very old parts of G1).
>
> Maybe Tony can comment.
I'm not going to defend it. I don't much like this kind of littering
of the code base either. I was trying to fix a build problem on some
(not (yet) supported by Oracle) platforms, without making a judgement
about the feature. But I'm happy to remove HEAP_REGION_SET_FORCE_VERIFY
instead.
>> NOT_PRODUCT/#ifndef PRODUCT is the wrong choice, being contrary to to
>> the intent of an optimize build to be similar in performance
>> characteristics to a product build.
>
> In my understanding there is an additional clause in that sentence:
> "[...] to a product build, including some extra verification".
>
> There is lots of similar verification that uses PRODUCT_RETURN/#ifndef
> PRODUCT that also already changes performance characteristics for an
> optimized build.
> See the other PRODUCT_RETURN uses (I can find 107 in just the gc
> directory) in this and other files.
That's not my understanding from discussions with John Masamitsu (who
was the only person I knew of to regularly use and care about
"optimized" builds). But it is certainly true there is a lot of code
that violates that rule. I occasionally wonder whether anyone would
care or notice if we killed off "optimized" builds; we don't test that
mode, with the result that it is often broken.
> So yes, I recommend removing this capability in this instance. This
> verification does not seem to be any different than any other.
>
> Not sure if this capability is too expensive or not (this is typically
> a bit fuzzy), but in the worst case one can use NOT_DEBUG_RETURN.
Since it was previously only under ASSERT, I'm leaving it that way.
New webrevs:
full: http://cr.openjdk.java.net/~kbarrett/8200550/open.01/
incr: http://cr.openjdk.java.net/~kbarrett/8200550/open.01.inc/
From david.holmes at oracle.com Mon Apr 9 07:01:49 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Apr 2018 17:01:49 +1000
Subject: RFR: 8200550: Xcode 9.3 produce warning on heapRegionSet.hpp
In-Reply-To: <1D3A3B61-7BC0-4A6E-B084-F2AAF464CEBE@oracle.com>
References: <0734D26B-5E3D-45A1-8321-23896819851A@oracle.com>
<1523098983.2294.7.camel@oracle.com>
<F5144B4C-CC79-44DE-8FA4-9D96B69C86B2@oracle.com>
<1523136263.2260.39.camel@oracle.com>
<1D3A3B61-7BC0-4A6E-B084-F2AAF464CEBE@oracle.com>
Message-ID: <915e05b8-c6c0-f5f0-f46a-eac6eb6e3678@oracle.com>
Hi Kim,
The now GC changes look fine (as did the original GC change). I'll leave
the revised GC change to the GC folk.
Thanks,
David
On 9/04/2018 4:55 PM, Kim Barrett wrote:
>> On Apr 7, 2018, at 5:24 PM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
>>
>> Hi,
>>
>> On Sat, 2018-04-07 at 15:48 -0400, Kim Barrett wrote:
>>>> On Apr 7, 2018, at 7:03 AM, Thomas Schatzl <thomas.schatzl at oracle.c
>>>> om> wrote:
>>>>
>>>> Hi Kim,
>>>>
>>>> On Fri, 2018-04-06 at 19:55 -0400, Kim Barrett wrote:
>>>>> Please review this fix of a couple of macro definitions that have
>>>>> "defined" expressions in the expansion. Such code has undefined
>>>>> behavior: C++03 16.1/3. Xcode 9.3 warns about such code.
>>>>>
>>>>> The fix for HEAP_REGION_SET_FORCE_VERIFY is a straight-forward
>>>>> change to use #ifdef ASSERT to define it appropriately.
>>>>
>>>> It would imho be much nicer to remove the define and use the
>>>> available NOT_DEBUG_RETURN/#ifndef ASSERT macros to accomplish the
>>>> same thing. (I would also be fine with using
>>>> NOT_PRODUCT_RETURN/#ifndef
>>>> PRODUCT).
>>>
>>> That doesn?t accomplish the same thing. The present code allows one
>>> to explicitly define the macro on the (make) command line to override
>>> the default behavior (based on ASSERT). Are you suggesting removing
>>> that capability?
>>
>> I have never anyone seen anyone using extra defines on the command line
>> and I am very certain I have never used them myselves, but maybe it
>> is common to do for others.
>> I can imagine people using them for initial development, and then
>> leaving them in "just in case", forgetting them rather quickly. This
>> and others are certainly not documented anywhere.
>>
>> It is also really easy to forget to remember to always specify the
>> correct defines, i.e. be sure that the build actually contains this
>> code too.
>>
>> That particular define has been introduced in 2011 and like many other
>> defines/paranoia checks/* in G1 code we removed over time this one
>> seems to duplicate the suggested (PRODUCT_RETURN / NOT_DEBUG_RETURN)
>> functionality.
>>
>> (Actually tbh, I have heard of HEAP_REGION_SET_FORCE_VERIFY for the
>> very first time. The heapRegionSet* files are very old parts of G1).
>>
>> Maybe Tony can comment.
>
> I'm not going to defend it. I don't much like this kind of littering
> of the code base either. I was trying to fix a build problem on some
> (not (yet) supported by Oracle) platforms, without making a judgement
> about the feature. But I'm happy to remove HEAP_REGION_SET_FORCE_VERIFY
> instead.
>
>>> NOT_PRODUCT/#ifndef PRODUCT is the wrong choice, being contrary to to
>>> the intent of an optimize build to be similar in performance
>>> characteristics to a product build.
>>
>> In my understanding there is an additional clause in that sentence:
>> "[...] to a product build, including some extra verification".
>>
>> There is lots of similar verification that uses PRODUCT_RETURN/#ifndef
>> PRODUCT that also already changes performance characteristics for an
>> optimized build.
>> See the other PRODUCT_RETURN uses (I can find 107 in just the gc
>> directory) in this and other files.
>
> That's not my understanding from discussions with John Masamitsu (who
> was the only person I knew of to regularly use and care about
> "optimized" builds). But it is certainly true there is a lot of code
> that violates that rule. I occasionally wonder whether anyone would
> care or notice if we killed off "optimized" builds; we don't test that
> mode, with the result that it is often broken.
>
>> So yes, I recommend removing this capability in this instance. This
>> verification does not seem to be any different than any other.
>>
>> Not sure if this capability is too expensive or not (this is typically
>> a bit fuzzy), but in the worst case one can use NOT_DEBUG_RETURN.
>
> Since it was previously only under ASSERT, I'm leaving it that way.
>
> New webrevs:
> full: http://cr.openjdk.java.net/~kbarrett/8200550/open.01/
> incr: http://cr.openjdk.java.net/~kbarrett/8200550/open.01.inc/
>
>
From thomas.schatzl at oracle.com Mon Apr 9 07:05:36 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 09 Apr 2018 09:05:36 +0200
Subject: RFR: 8200550: Xcode 9.3 produce warning on heapRegionSet.hpp
In-Reply-To: <1D3A3B61-7BC0-4A6E-B084-F2AAF464CEBE@oracle.com>
References: <0734D26B-5E3D-45A1-8321-23896819851A@oracle.com>
<1523098983.2294.7.camel@oracle.com>
<F5144B4C-CC79-44DE-8FA4-9D96B69C86B2@oracle.com>
<1523136263.2260.39.camel@oracle.com>
<1D3A3B61-7BC0-4A6E-B084-F2AAF464CEBE@oracle.com>
Message-ID: <1523257536.4326.2.camel@oracle.com>
Hi,
On Mon, 2018-04-09 at 02:55 -0400, Kim Barrett wrote:
> > > NOT_PRODUCT/#ifndef PRODUCT is the wrong choice, being contrary
> > > to to the intent of an optimize build to be similar in
> > > performance characteristics to a product build.
> >
> > In my understanding there is an additional clause in that sentence:
> > "[...] to a product build, including some extra verification".
> >
> > There is lots of similar verification that uses
> > PRODUCT_RETURN/#ifndef PRODUCT that also already changes
> > performance characteristics for an optimized build.
> > See the other PRODUCT_RETURN uses (I can find 107 in just the gc
> > directory) in this and other files.
>
> That's not my understanding from discussions with Jon Masamitsu (who
> was the only person I knew of to regularly use and care about
> "optimized" builds). But it is certainly true there is a lot of code
> that violates that rule. I occasionally wonder whether anyone would
> care or notice if we killed off "optimized" builds; we don't test
> that mode, with the result that it is often broken.
I agree that we may probably just remove optimized builds for the above
stated reasons, but that is another discussion :)
> > So yes, I recommend removing this capability in this instance. This
> > verification does not seem to be any different than any other.
> >
> > Not sure if this capability is too expensive or not (this is
> > typically a bit fuzzy), but in the worst case one can use
> > NOT_DEBUG_RETURN.
>
> Since it was previously only under ASSERT, I'm leaving it that way.
>
> New webrevs:
> full: http://cr.openjdk.java.net/~kbarrett/8200550/open.01/
> incr: http://cr.openjdk.java.net/~kbarrett/8200550/open.01.inc/
looks good.
Thanks,
Thomas
From christoph.langer at sap.com Mon Apr 9 07:08:46 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 9 Apr 2018 07:08:46 +0000
Subject: RFR (M): 8201247: Various cleanups in the attach framework
In-Reply-To: <91d75e2d-47a4-e9ee-5d19-8f3e6dc13428@oracle.com>
References: <14dff9b0cf5a4b888aef1d6452801b57@sap.com>
<91d75e2d-47a4-e9ee-5d19-8f3e6dc13428@oracle.com>
Message-ID: <a3248ff5584e4186acc8a3baec06ab4b@sap.com>
Hi Chris,
thanks for looking into this.
As for ArgumentIterator::next, I must admit, I found this patch in our code base when taking over the code. I believe that an issue would be seen if an attach operation has 2 or 3 arguments and the first one is NULL/empty. I guess such a situation can't happen with the attach operations currently existing in OpenJDK as none of these ops would allow such type of arguments. However, in our implementation, we have for instance enhanced the "dump_heap" operation to work with null as first argument where one usually would specify the desired output file name. We implemented a mechanism to compute a default filename when the param is left blank. So we need the fix for that case, I guess.
I'll run the patch through the submission forest now and do some jtreg testing.
Best regards
Christoph
> -----Original Message-----
> From: Chris Plummer [mailto:chris.plummer at oracle.com]
> Sent: Freitag, 6. April 2018 18:37
> To: Langer, Christoph <christoph.langer at sap.com>; serviceability-
> dev at openjdk.java.net
> Cc: hotspot-dev at openjdk.java.net
> Subject: Re: RFR (M): 8201247: Various cleanups in the attach framework
>
> Hi Christoph,
>
> Can you explain a bit more about "fix handling of null values in
> ArgumentIterator::next". When does this turn up? Is there a test case?
>
> Everything else looks good.
>
> thanks,
>
> Chris
>
> On 4/6/18 8:01 AM, Langer, Christoph wrote:
> >
> > Hi,
> >
> > can I please get reviews for a set of clean up changes that I came
> > across when doing some integration work.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8201247
> > <https://bugs.openjdk.java.net/browse/JDK-8201247>
> >
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/
> > <http://cr.openjdk.java.net/%7Eclanger/webrevs/8201247.0/>
> >
> > Detailed comments about the changes can be found in the bug.
> >
> > Thanks & best regards
> >
> > Christoph
> >
From magnus.ihse.bursie at oracle.com Mon Apr 9 07:55:09 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 9 Apr 2018 09:55:09 +0200
Subject: Supported platforms
In-Reply-To: <5ACA276C.7030505@cjnash.com>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
<15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
<5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
<5ACA276C.7030505@cjnash.com>
Message-ID: <4b1f262d-b9d2-6844-e453-dd53b42b2d74@oracle.com>
Simon,
On 2018-04-08 16:30, Simon Nash wrote:
> On 05/04/2018 02:26, bren at juanantonio.info wrote:
>>
>> Many thanks with the link about the Platforms supported:
>> http://www.oracle.com/technetwork/java/javase/documentation/jdk10certconfig-4417031.html
>>
> This appears to be a list of the platforms that are supported
> (certified) by
> Oracle.? Where can I find the list of platforms that are supported by
> OpenJDK?? For example, what about the following platforms that don't
> appear
> on the Oracle list:
>
> Windows x86
> Linux x86
> aarch32 (ARMv7 32-bit)
> aarch64 (ARMv8 64-bit)
>
> Are all these supported for OpenJDK 9, 10 and 11?
There is actually no such thing as a "supported OpenJDK platform". While
I hope things may change in the future, OpenJDK as an organization does
not publicize any list of "supported" platforms. Oracle publishes a list
of platforms they support, and I presume that Red Hat and SAP and others
do the same, but the OpenJDK project itself does not.
With that said, platforms which were previously supported by Oracle
(like the one's you mentioned) tend to still work more-or-less well, but
they receive no or little testing, and is prone to bit rot.
/Magnus
>
> Simon
From glaubitz at physik.fu-berlin.de Mon Apr 9 08:42:29 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 9 Apr 2018 10:42:29 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <2c38917e-41ca-cf7a-68bd-7f996bea8c76@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<038e8652-ec32-e2ae-9b10-b683ac81fd54@physik.fu-berlin.de>
<57e8037f-5b4d-e0bc-d8c3-7fc8b9f93c4c@oracle.com>
<2c38917e-41ca-cf7a-68bd-7f996bea8c76@physik.fu-berlin.de>
Message-ID: <c85f1279-d220-417b-699e-01bf09a8bbf2@physik.fu-berlin.de>
On 04/09/2018 12:11 AM, John Paul Adrian Glaubitz wrote:
>>> This leads to an abort() because a pointer is freed that's not allocated.
>>
>> ??
>>
>> ?_string = strdup(vstr);
>
> I'm a bit confused as well. I just did a "hg pull && hg update --clean" and
> applied just Zhengyu's change. Now rebuilding.
Here's the output of the java command with the change os::free > ::free:
glaubitz at stadler:/srv/openjdk/hs$ ./build/linux-sparcv9-normal-server-fastdebug/jdk/bin/java
free(): invalid pointer
Aborted
glaubitz at stadler:/srv/openjdk/hs$
And here the backtrace:
(gdb) bt
#0 0xffff8001005b3b9c in __libc_signal_restore_set (set=0xffff8001025d4208) at ../sysdeps/unix/sysv/linux/nptl-signals.h:80
#1 __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#2 0xffff8001005b5144 in __GI_abort () at abort.c:79
#3 0xffff8001005f30d4 in __libc_message (action=action at entry=do_abort, fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:181
#4 0xffff8001005f9e38 in malloc_printerr (str=0xffff8001006cc0b8 "free(): invalid pointer") at malloc.c:5350
#5 0xffff8001005fb900 in _int_free (av=0xffff8001007e1640 <main_arena>, p=0xffff80010400f730, have_lock=<optimized out>) at malloc.c:4157
#6 0xffff800101e873c8 in CPUinfo::~CPUinfo (this=0xffff8001025d4888, __in_chrg=<optimized out>) at /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:59
#7 VM_Version::platform_features () at /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:184
#8 0xffff800101e87658 in VM_Version::determine_features () at /srv/openjdk/hs/src/hotspot/cpu/sparc/vm_version_sparc.cpp:505
#9 0xffff800101d3f4a8 in Threads::create_vm (args=args at entry=0xffff8001025d4d78, canTryAgain=canTryAgain at entry=0xffff8001025d4c57) at /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:3637
#10 0xffff800101503a98 in JNI_CreateJavaVM_inner (args=0xffff8001025d4d78, penv=0xffff8001025d4d70, vm=0xffff8001025d4d68) at /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:3929
#11 JNI_CreateJavaVM (vm=0xffff8001025d4d68, penv=0xffff8001025d4d70, args=0xffff8001025d4d78) at /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:4024
#12 0xffff800100367f10 in InitializeJVM (ifn=<synthetic pointer>, penv=0xffff8001025d4d70, pvm=0xffff8001025d4d68) at /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:1479
#13 JavaMain (_args=<optimized out>) at /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:412
#14 0xffff80010024b874 in start_thread (arg=0xffff8001025d5910) at pthread_create.c:463
#15 0xffff800100667140 in __thread_start () at ../sysdeps/unix/sysv/linux/sparc/sparc64/clone.S:78
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From glaubitz at physik.fu-berlin.de Mon Apr 9 08:47:56 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 9 Apr 2018 10:47:56 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <c85f1279-d220-417b-699e-01bf09a8bbf2@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<038e8652-ec32-e2ae-9b10-b683ac81fd54@physik.fu-berlin.de>
<57e8037f-5b4d-e0bc-d8c3-7fc8b9f93c4c@oracle.com>
<2c38917e-41ca-cf7a-68bd-7f996bea8c76@physik.fu-berlin.de>
<c85f1279-d220-417b-699e-01bf09a8bbf2@physik.fu-berlin.de>
Message-ID: <a4c759f1-b3ad-384c-dab6-a04140e2315e@physik.fu-berlin.de>
On 04/09/2018 10:42 AM, John Paul Adrian Glaubitz wrote:
> Here's the output of the java command with the change os::free > ::free:
>
> glaubitz at stadler:/srv/openjdk/hs$ ./build/linux-sparcv9-normal-server-fastdebug/jdk/bin/java
> free(): invalid pointer
> Aborted
> glaubitz at stadler:/srv/openjdk/hs$
And changing it back to os::free leads again to the assertion failure:
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=/assembler_sparc.cpp:52
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.cpp:52), pid=24269, tid=24320
# assert(!(is_cti(prev) && is_cti(insn))) failed: CTI-CTI not allowed.
#
# JRE version: OpenJDK Runtime Environment (11.0) (fastdebug build 11-internal+0-adhoc.glaubitz.hs)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 11-internal+0-adhoc.glaubitz.hs, mixed mode, tiered, compressed oops, serial gc, linux-sparc)
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /srv/openjdk/hs/make/hs_err_pid24269.log
#
# Compiler replay data is saved as:
# /srv/openjdk/hs/make/replay_pid24269.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From stefan.johansson at oracle.com Mon Apr 9 09:34:41 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Mon, 9 Apr 2018 11:34:41 +0200
Subject: RFR: 8200759: Move GC entries in vmStructs.cpp to GC specific
files
In-Reply-To: <25075b38-dd87-5d07-dbc8-137798d49931@oracle.com>
References: <8f9ef0fb-14b6-fca8-04ac-1ce49a3a11f0@oracle.com>
<25075b38-dd87-5d07-dbc8-137798d49931@oracle.com>
Message-ID: <e31ff400-628c-e185-8e0a-9a8b7481f334@oracle.com>
On 2018-04-06 10:00, Stefan Karlsson wrote:
> Hi all,
>
> Since I have a few follow-up changes that depend on the ALL_GCS_ONLY
> macro introduced in this patch, I'm going to extract that part into a
> separate RFE, so that if any of the following patches need to be backed
> out (for some reason) I won't have to back out this change.
>
> This is the piece I'm going to push separately:
> http://cr.openjdk.java.net/~stefank/8200759/webrev.01/src/hotspot/share/utilities/macros.hpp.udiff.html
>
Sound like a plan to push that separately.
The rest of patch also looks good.
Thanks,
StefanJ
>
> Thanks,
> StefanK
>
> On 2018-04-04 21:37, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to move GC specific entries in vmStructs.cpp
>> out to GC specific files.
>>
>> http://cr.openjdk.java.net/~stefank/8200759/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8200759
>>
>> This patch is done in preparation for:
>> ??https://bugs.openjdk.java.net/browse/JDK-8200729 - Conditional
>> compilation of GCs
>>
>> This patch also has the nice feature that it removes multiple usages
>> of the GC specific defines in vmStructs.cpp. When new GCs are added
>> only three defines need to be added to vmStructs_gc.hpp.
>>
>> Tested locally with test/hotspot/jtreg/serviceability/sa, but will run
>> this through mach5 to find potantial missing includes / forward
>> declarations.
>>
>> Thanks,
>> StefanK
From stefan.johansson at oracle.com Mon Apr 9 10:10:50 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Mon, 9 Apr 2018 12:10:50 +0200
Subject: RFR: 8201168: Move GC command line constraint functions to GC
specific files
In-Reply-To: <99b6d120-44bf-b243-7fa1-5a5cb9c44b8b@oracle.com>
References: <99b6d120-44bf-b243-7fa1-5a5cb9c44b8b@oracle.com>
Message-ID: <765632f1-7e07-5bc7-10dc-45fe737c194f@oracle.com>
On 2018-04-05 12:03, Stefan Karlsson wrote:
> Hi all,
>
> Please review this patch to move the GC flag constraint functions into
> GC specific files.
>
> ?http://cr.openjdk.java.net/~stefank/8201168/webrev.01
> ?https://bugs.openjdk.java.net/browse/JDK-8201168
>
Seems good =)
StefanJ
> This is one step towards:
>
> ?https://bugs.openjdk.java.net/browse/JDK-8200729 - Conditional
> compilation of GCs
>
> I know that this conflicts with Gerards rename of the flags to JVMFlags,
> but I don't want to wait for that to get pushed before publishing this
> review request.
>
> Thanks,
> StefanK
From david.holmes at oracle.com Mon Apr 9 11:10:19 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Apr 2018 21:10:19 +1000
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <c85f1279-d220-417b-699e-01bf09a8bbf2@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<038e8652-ec32-e2ae-9b10-b683ac81fd54@physik.fu-berlin.de>
<57e8037f-5b4d-e0bc-d8c3-7fc8b9f93c4c@oracle.com>
<2c38917e-41ca-cf7a-68bd-7f996bea8c76@physik.fu-berlin.de>
<c85f1279-d220-417b-699e-01bf09a8bbf2@physik.fu-berlin.de>
Message-ID: <980e2b4d-7984-b788-0c7b-6d60b71e665e@oracle.com>
On 9/04/2018 6:42 PM, John Paul Adrian Glaubitz wrote:
> On 04/09/2018 12:11 AM, John Paul Adrian Glaubitz wrote:
>>>> This leads to an abort() because a pointer is freed that's not
>>>> allocated.
>>>
>>> ??
>>>
>>> ??_string = strdup(vstr);
>>
>> I'm a bit confused as well. I just did a "hg pull && hg update
>> --clean" and
>> applied just Zhengyu's change. Now rebuilding.
>
> Here's the output of the java command with the change os::free > ::free:
You didn't apply Zhengyu's patch as well did you?
David
-----
> glaubitz at stadler:/srv/openjdk/hs$
> ./build/linux-sparcv9-normal-server-fastdebug/jdk/bin/java
> free(): invalid pointer
> Aborted
> glaubitz at stadler:/srv/openjdk/hs$
>
> And here the backtrace:
>
> (gdb) bt
> #0? 0xffff8001005b3b9c in __libc_signal_restore_set
> (set=0xffff8001025d4208) at ../sysdeps/unix/sysv/linux/nptl-signals.h:80
> #1? __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:48
> #2? 0xffff8001005b5144 in __GI_abort () at abort.c:79
> #3? 0xffff8001005f30d4 in __libc_message (action=action at entry=do_abort,
> fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:181
> #4? 0xffff8001005f9e38 in malloc_printerr (str=0xffff8001006cc0b8
> "free(): invalid pointer") at malloc.c:5350
> #5? 0xffff8001005fb900 in _int_free (av=0xffff8001007e1640 <main_arena>,
> p=0xffff80010400f730, have_lock=<optimized out>) at malloc.c:4157
> #6? 0xffff800101e873c8 in CPUinfo::~CPUinfo (this=0xffff8001025d4888,
> __in_chrg=<optimized out>) at
> /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:59
>
> #7? VM_Version::platform_features () at
> /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:184
>
> #8? 0xffff800101e87658 in VM_Version::determine_features () at
> /srv/openjdk/hs/src/hotspot/cpu/sparc/vm_version_sparc.cpp:505
> #9? 0xffff800101d3f4a8 in Threads::create_vm
> (args=args at entry=0xffff8001025d4d78,
> canTryAgain=canTryAgain at entry=0xffff8001025d4c57) at
> /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:3637
> #10 0xffff800101503a98 in JNI_CreateJavaVM_inner
> (args=0xffff8001025d4d78, penv=0xffff8001025d4d70,
> vm=0xffff8001025d4d68) at
> /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:3929
> #11 JNI_CreateJavaVM (vm=0xffff8001025d4d68, penv=0xffff8001025d4d70,
> args=0xffff8001025d4d78) at
> /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:4024
> #12 0xffff800100367f10 in InitializeJVM (ifn=<synthetic pointer>,
> penv=0xffff8001025d4d70, pvm=0xffff8001025d4d68) at
> /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:1479
> #13 JavaMain (_args=<optimized out>) at
> /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:412
> #14 0xffff80010024b874 in start_thread (arg=0xffff8001025d5910) at
> pthread_create.c:463
> #15 0xffff800100667140 in __thread_start () at
> ../sysdeps/unix/sysv/linux/sparc/sparc64/clone.S:78
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)
>
> Adrian
>
From glaubitz at physik.fu-berlin.de Mon Apr 9 11:23:54 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 9 Apr 2018 13:23:54 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <980e2b4d-7984-b788-0c7b-6d60b71e665e@oracle.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<038e8652-ec32-e2ae-9b10-b683ac81fd54@physik.fu-berlin.de>
<57e8037f-5b4d-e0bc-d8c3-7fc8b9f93c4c@oracle.com>
<2c38917e-41ca-cf7a-68bd-7f996bea8c76@physik.fu-berlin.de>
<c85f1279-d220-417b-699e-01bf09a8bbf2@physik.fu-berlin.de>
<980e2b4d-7984-b788-0c7b-6d60b71e665e@oracle.com>
Message-ID: <e95dbdae-52d4-a79d-90eb-9a7d08b15080@physik.fu-berlin.de>
On 04/09/2018 01:10 PM, David Holmes wrote:
>> Here's the output of the java command with the change os::free > ::free:
>
> You didn't apply Zhengyu's patch as well did you?
I did apply his patch as well. So, the total changes are:
diff -r cd4da74e310b src/hotspot/cpu/sparc/assembler_sparc.cpp
--- a/src/hotspot/cpu/sparc/assembler_sparc.cpp Fri Apr 06 19:16:33 2018 +0200
+++ b/src/hotspot/cpu/sparc/assembler_sparc.cpp Mon Apr 09 11:23:38 2018 +0000
@@ -49,7 +49,7 @@
uint32_t insn = *reinterpret_cast<uint32_t*>(pc);
// 1. General case: No CTI immediately after other CTI
- assert(!(is_cti(prev) && is_cti(insn)), "CTI-CTI not allowed.");
+ // assert(!(is_cti(prev) && is_cti(insn)), "CTI-CTI not allowed.");
// 2. Special case: No CTI immediately after/before RDPC
assert(!(is_cti(prev) && is_rdpc(insn)), "CTI-RDPC not allowed.");
diff -r cd4da74e310b src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp
--- a/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp Fri Apr 06 19:16:33 2018 +0200
+++ b/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp Mon Apr 09 11:23:38 2018 +0000
@@ -48,7 +48,7 @@
if (vstr != NULL) {
// We have a matching line and a valid starting point to the value of
// the field, copy the string for keeps.
- _string = strdup(vstr);
+ _string = os::strdup(vstr, mtInternal);
break;
}
}
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From glaubitz at physik.fu-berlin.de Mon Apr 9 11:38:24 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 9 Apr 2018 13:38:24 +0200
Subject: Zero fails to build on SPARC again, similar to JDK-8186578
Message-ID: <09c3fb5b-ab74-f478-c72d-538c7f8faaa8@physik.fu-berlin.de>
Hi!
Since building native JVM variant on linux-sparc is currently broken for
both OpenJDK-10 and OpenJDK-11, I tried building Zero instead. However,
Zero is broken as well:
=== Output from failing command(s) repeated here ===
/usr/bin/printf "* For target hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:\n"
* For target hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:
(/bin/grep -v -e "^Note: including file:" < /srv/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.log || true) | /usr/bin/head -n 12
/srv/openjdk/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/gtest/objs/test_memset_with_concurrent_readers.o: In function `gc_memset_with_concurrent_readers_test_Test::TestBody()':
/srv/openjdk/hs/test/hotspot/gtest/gc/shared/test_memset_with_concurrent_readers.cpp:66: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/openjdk/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o: In function `BlockOffsetArray::single_block(HeapWord*, HeapWord*)':
/srv/openjdk/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/openjdk/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/openjdk/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o: In function `BlockOffsetArrayNonContigSpace::alloc_block(HeapWord*, HeapWord*)':
/srv/openjdk/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/openjdk/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/openjdk/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o:/srv/openjdk/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: more undefined references to `memset_with_concurrent_readers(void*, int, unsigned long)' follow
collect2: error: ld returned 1 exit status
if test `/usr/bin/wc -l < /srv/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi
/usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link:\n"
* For target hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link:
(/bin/grep -v -e "^Note: including file:" < /srv/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link.log || true) | /usr/bin/head -n 12
/srv/openjdk/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o: In function `BlockOffsetArray::single_block(HeapWord*, HeapWord*)':
/srv/openjdk/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/openjdk/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/openjdk/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o: In function `BlockOffsetArrayNonContigSpace::alloc_block(HeapWord*, HeapWord*)':
/srv/openjdk/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/openjdk/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/openjdk/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o: In function `BlockOffsetArray::BlockOffsetArray(BlockOffsetSharedArray*, MemRegion, bool)':
/srv/openjdk/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/openjdk/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o:/srv/openjdk/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: more undefined references to `memset_with_concurrent_readers(void*, int, unsigned long)' follow
collect2: error: ld returned 1 exit status
if test `/usr/bin/wc -l < /srv/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi
/usr/bin/printf "\n* All command lines available in /srv/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs.\n"
* All command lines available in /srv/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs.
/usr/bin/printf "=== End of repeated output ===\n"
=== End of repeated output ===
This is reminiscent of JDK-8186578 and I would have expected the change made there
to be still working [2]. The relative path to memset_with_concurrent_readers_sparc.cpp
is still correct though.
Any suggestions?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From zgu at redhat.com Mon Apr 9 12:03:15 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 9 Apr 2018 08:03:15 -0400
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
Message-ID: <c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
Hi David,
On 04/08/2018 05:39 PM, David Holmes wrote:
> On 6/04/2018 11:16 PM, Zhengyu Gu wrote:
>> I think it is symptom, the real cause is:
>>
>> In CPUinfo constructor:
>>
>> _string = strdup(vstr);
>>
>> should be:
>>
>> _string = os::strdup(vstr, mtInternal);
>
> There's definitely a mismatch there. But I think there is also a real
> problem that we may end up in code that requires an attached thread and
> we don't have one yet. I'd be more inclined to change the os::free to a
> ::freeHi
Why we need an attached thread here?
Thanks,
-Zhengyu
>
> David
>
>> -Zhengyu
>>
>>
>> On 04/06/2018 09:12 AM, Aleksey Shipilev wrote:
>>> I would say dig here:
>>>
>>> On 04/06/2018 03:02 PM, John Paul Adrian Glaubitz wrote:
>>>> #20 0xffff8001010e5d74 in report_vm_error (file=0xffff800101f3fd58
>>>> detail_fmt=0xffff800101f3fd00 "Thread::current() called on detached
>>>> thread") at
>>>> #21 0xffff800101a48fc0 in Thread::current () at
>>>> /srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp:720
>>>> #22 ResourceMark::ResourceMark (this=0xffff800102638600) at
>>>> /srv/openjdk/hs/src/hotspot/share/memory/resourceArea.hpp:109
>>>> #23 verify_memory (ptr=ptr at entry=0xffff80010400fda0) at
>>>> /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:632
>>>> #24 0xffff800101a4ea74 in os::free (memblock=0xffff80010400fda0) at
>>>> /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:783
>>>> #25 0xffff800101ee9df0 in CPUinfo::~CPUinfo
>>>> (this=0xffff800102638888, __in_chrg=<optimized out>) at
>>>> /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:59
>>>>
>>>> #26 VM_Version::platform_features () at
>>>> /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:184
>>>>
>>>> #27 0xffff800101eea080 in VM_Version::determine_features () at
>>>> #28 0xffff800101da1ed0 in Threads::create_vm
>>>> (args=args at entry=0xffff800102638d78,
>>>> canTryAgain=canTryAgain at entry=0xffff800102638c57) at
>>>> /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:3637
>>>> #29 0xffff800101570a78 in JNI_CreateJavaVM_inner
>>>> (args=0xffff800102638d78, penv=0xffff800102638d70,
>>>> vm=0xffff800102638d68) at
>>>> /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:3929
>>>> #30 JNI_CreateJavaVM (vm=0xffff800102638d68,
>>>> penv=0xffff800102638d70, args=0xffff800102638d78) at
>>>> /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:4024
>>>> #31 0xffff8001003bfa74 in InitializeJVM (ifn=<synthetic pointer>,
>>>> penv=0xffff800102638d70, pvm=0xffff800102638d68) at
>>>> /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:1478
>>>> #32 JavaMain (_args=<optimized out>) at
>>>> /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:411
>>>> #33 0xffff8001002a3874 in start_thread (arg=0xffff800102639910) at
>>>> pthread_create.c:463
>>>> #34 0xffff8001006bf140 in __thread_start () at
>>>> ../sysdeps/unix/sysv/linux/sparc/sparc64/clone.S:78
>>>> Backtrace stopped: previous frame identical to this frame (corrupt
>>>> stack?)
>>>
>>> I think this means we are trying to use Resource area before the
>>> thread is fully initialized. IIRC
>>> that is forbidden. Looking at os::verify_memory:
>>>
>>> static void verify_memory(void* ptr) { // <--- frame #23
>>> ?? GuardedMemory guarded(ptr);
>>> ?? if (!guarded.verify_guards()) {
>>> ???? LogTarget(Warning, malloc, free) lt;
>>> ???? ResourceMark rm; // <--- frame #22
>>> ???? LogStream ls(lt);
>>> ???? ls.print_cr("## nof_mallocs = " UINT64_FORMAT ", nof_frees = "
>>> UINT64_FORMAT...
>>> ???? ls.print_cr("## memory stomp:");
>>> ???? guarded.print_on(&ls);
>>> ???? fatal("memory stomping error");
>>> ?? }
>>> }
>>>
>>> It seems we have *failed* the guarded memory check, entered the
>>> branch, and then failed reporting
>>> the failure. This must mean buffer overrun somewhere?
>>>
>>> Thanks,
>>> -Aleksey
>>>
From stefan.karlsson at oracle.com Mon Apr 9 12:18:58 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 9 Apr 2018 14:18:58 +0200
Subject: RFR: 8200759: Move GC entries in vmStructs.cpp to GC specific
files
In-Reply-To: <e31ff400-628c-e185-8e0a-9a8b7481f334@oracle.com>
References: <8f9ef0fb-14b6-fca8-04ac-1ce49a3a11f0@oracle.com>
<25075b38-dd87-5d07-dbc8-137798d49931@oracle.com>
<e31ff400-628c-e185-8e0a-9a8b7481f334@oracle.com>
Message-ID: <5bb58bd5-51e4-5371-d7b8-539a831efca6@oracle.com>
Thanks, StefanJ.
StefanK
On 2018-04-09 11:34, Stefan Johansson wrote:
>
>
> On 2018-04-06 10:00, Stefan Karlsson wrote:
>> Hi all,
>>
>> Since I have a few follow-up changes that depend on the ALL_GCS_ONLY
>> macro introduced in this patch, I'm going to extract that part into a
>> separate RFE, so that if any of the following patches need to be
>> backed out (for some reason) I won't have to back out this change.
>>
>> This is the piece I'm going to push separately:
>> http://cr.openjdk.java.net/~stefank/8200759/webrev.01/src/hotspot/share/utilities/macros.hpp.udiff.html
>>
> Sound like a plan to push that separately.
>
> The rest of patch also looks good.
>
> Thanks,
> StefanJ
>>
>> Thanks,
>> StefanK
>>
>> On 2018-04-04 21:37, Stefan Karlsson wrote:
>>> Hi all,
>>>
>>> Please review this patch to move GC specific entries in vmStructs.cpp
>>> out to GC specific files.
>>>
>>> http://cr.openjdk.java.net/~stefank/8200759/webrev.01/
>>> https://bugs.openjdk.java.net/browse/JDK-8200759
>>>
>>> This patch is done in preparation for:
>>> ??https://bugs.openjdk.java.net/browse/JDK-8200729 - Conditional
>>> compilation of GCs
>>>
>>> This patch also has the nice feature that it removes multiple usages
>>> of the GC specific defines in vmStructs.cpp. When new GCs are added
>>> only three defines need to be added to vmStructs_gc.hpp.
>>>
>>> Tested locally with test/hotspot/jtreg/serviceability/sa, but will
>>> run this through mach5 to find potantial missing includes / forward
>>> declarations.
>>>
>>> Thanks,
>>> StefanK
From stefan.karlsson at oracle.com Mon Apr 9 12:20:43 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 9 Apr 2018 14:20:43 +0200
Subject: RFR: 8201168: Move GC command line constraint functions to GC
specific files
In-Reply-To: <765632f1-7e07-5bc7-10dc-45fe737c194f@oracle.com>
References: <99b6d120-44bf-b243-7fa1-5a5cb9c44b8b@oracle.com>
<765632f1-7e07-5bc7-10dc-45fe737c194f@oracle.com>
Message-ID: <61284c45-9974-c174-8c9a-69e3c9f59834@oracle.com>
Thanks, StefanJ.
StefanK
On 2018-04-09 12:10, Stefan Johansson wrote:
>
>
> On 2018-04-05 12:03, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to move the GC flag constraint functions into
>> GC specific files.
>>
>> ??http://cr.openjdk.java.net/~stefank/8201168/webrev.01
>> ??https://bugs.openjdk.java.net/browse/JDK-8201168
>>
> Seems good =)
> StefanJ
>
>> This is one step towards:
>>
>> ??https://bugs.openjdk.java.net/browse/JDK-8200729 - Conditional
>> compilation of GCs
>>
>> I know that this conflicts with Gerards rename of the flags to
>> JVMFlags, but I don't want to wait for that to get pushed before
>> publishing this review request.
>>
>> Thanks,
>> StefanK
From david.holmes at oracle.com Mon Apr 9 12:30:41 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Apr 2018 22:30:41 +1000
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <e95dbdae-52d4-a79d-90eb-9a7d08b15080@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<038e8652-ec32-e2ae-9b10-b683ac81fd54@physik.fu-berlin.de>
<57e8037f-5b4d-e0bc-d8c3-7fc8b9f93c4c@oracle.com>
<2c38917e-41ca-cf7a-68bd-7f996bea8c76@physik.fu-berlin.de>
<c85f1279-d220-417b-699e-01bf09a8bbf2@physik.fu-berlin.de>
<980e2b4d-7984-b788-0c7b-6d60b71e665e@oracle.com>
<e95dbdae-52d4-a79d-90eb-9a7d08b15080@physik.fu-berlin.de>
Message-ID: <061bedd7-b69a-c9c7-362d-a92c4c956489@oracle.com>
On 9/04/2018 9:23 PM, John Paul Adrian Glaubitz wrote:
> On 04/09/2018 01:10 PM, David Holmes wrote:
>>> Here's the output of the java command with the change os::free > ::free:
>>
>> You didn't apply Zhengyu's patch as well did you?
> I did apply his patch as well. So, the total changes are:
My suggesting was to change os::free to ::free to match the ::strdup
_instead_ of Zhengyu's suggestion to change the ::strdup to os::strdup.
David
-----
> diff -r cd4da74e310b src/hotspot/cpu/sparc/assembler_sparc.cpp
> --- a/src/hotspot/cpu/sparc/assembler_sparc.cpp Fri Apr 06 19:16:33 2018
> +0200
> +++ b/src/hotspot/cpu/sparc/assembler_sparc.cpp Mon Apr 09 11:23:38 2018
> +0000
> @@ -49,7 +49,7 @@
> ???? uint32_t insn = *reinterpret_cast<uint32_t*>(pc);
>
> ???? // 1. General case: No CTI immediately after other CTI
> -??? assert(!(is_cti(prev) && is_cti(insn)), "CTI-CTI not allowed.");
> +??? // assert(!(is_cti(prev) && is_cti(insn)), "CTI-CTI not allowed.");
>
> ???? // 2. Special case: No CTI immediately after/before RDPC
> ???? assert(!(is_cti(prev) && is_rdpc(insn)), "CTI-RDPC not allowed.");
> diff -r cd4da74e310b
> src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp
> --- a/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp Fri Apr
> 06 19:16:33 2018 +0200
> +++ b/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp Mon Apr
> 09 11:23:38 2018 +0000
> @@ -48,7 +48,7 @@
> ???????? if (vstr != NULL) {
> ?????????? // We have a matching line and a valid starting point to the
> value of
> ?????????? // the field, copy the string for keeps.
> -????????? _string = strdup(vstr);
> +????????? _string = os::strdup(vstr, mtInternal);
> ?????????? break;
> ???????? }
> ?????? }
>
From david.holmes at oracle.com Mon Apr 9 12:33:01 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Apr 2018 22:33:01 +1000
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
Message-ID: <5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
On 9/04/2018 10:03 PM, Zhengyu Gu wrote:
> Hi David,
>
> On 04/08/2018 05:39 PM, David Holmes wrote:
>> On 6/04/2018 11:16 PM, Zhengyu Gu wrote:
>>> I think it is symptom, the real cause is:
>>>
>>> In CPUinfo constructor:
>>>
>>> _string = strdup(vstr);
>>>
>>> should be:
>>>
>>> _string = os::strdup(vstr, mtInternal);
>>
>> There's definitely a mismatch there. But I think there is also a real
>> problem that we may end up in code that requires an attached thread
>> and we don't have one yet. I'd be more inclined to change the os::free
>> to a ::freeHi
>
> Why we need an attached thread here?
From the crash report:
#19 0xffff800101e74cc0 in VMError::report_and_die (thread=0x0,
context=context at entry=0x0, filename=filename at entry=0xffff800101f3fd58
"/srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp",
lineno=lineno at entry=720,
message=message at entry=0xffff800101f3fd30 "assert(current != __null)
failed", detail_fmt=detail_fmt at entry=0xffff800101f3fd00
"Thread::current() called on detached thread", detail_args=<optimized
out>) at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1244
#20 0xffff8001010e5d74 in report_vm_error (file=0xffff800101f3fd58
"/srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp",
line=line at entry=720, error_msg=0xffff800101f3fd30 "assert(current !=
__null) failed",
detail_fmt=0xffff800101f3fd00 "Thread::current() called on detached
thread") at /srv/openjdk/hs/src/hotspot/share/utilities/debug.cpp:230
#21 0xffff800101a48fc0 in Thread::current () at
/srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp:720
#22 ResourceMark::ResourceMark (this=0xffff800102638600) at
/srv/openjdk/hs/src/hotspot/share/memory/resourceArea.hpp:109
#23 verify_memory (ptr=ptr at entry=0xffff80010400fda0) at
/srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:632
#24 0xffff800101a4ea74 in os::free (memblock=0xffff80010400fda0) at
/srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:783
#25 0xffff800101ee9df0 in CPUinfo::~CPUinfo (this=0xffff800102638888,
__in_chrg=<optimized out>) at
/srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:59
The use of the os* functions can lead us into code that uses
ResourceMark and requires an attached thread.
David
-----
>
> Thanks,
>
> -Zhengyu
>
>>
>> David
>>
>>> -Zhengyu
>>>
>>>
>>> On 04/06/2018 09:12 AM, Aleksey Shipilev wrote:
>>>> I would say dig here:
>>>>
>>>> On 04/06/2018 03:02 PM, John Paul Adrian Glaubitz wrote:
>>>>> #20 0xffff8001010e5d74 in report_vm_error (file=0xffff800101f3fd58
>>>>> detail_fmt=0xffff800101f3fd00 "Thread::current() called on detached
>>>>> thread") at
>>>>> #21 0xffff800101a48fc0 in Thread::current () at
>>>>> /srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp:720
>>>>> #22 ResourceMark::ResourceMark (this=0xffff800102638600) at
>>>>> /srv/openjdk/hs/src/hotspot/share/memory/resourceArea.hpp:109
>>>>> #23 verify_memory (ptr=ptr at entry=0xffff80010400fda0) at
>>>>> /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:632
>>>>> #24 0xffff800101a4ea74 in os::free (memblock=0xffff80010400fda0) at
>>>>> /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:783
>>>>> #25 0xffff800101ee9df0 in CPUinfo::~CPUinfo
>>>>> (this=0xffff800102638888, __in_chrg=<optimized out>) at
>>>>> /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:59
>>>>>
>>>>> #26 VM_Version::platform_features () at
>>>>> /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:184
>>>>>
>>>>> #27 0xffff800101eea080 in VM_Version::determine_features () at
>>>>> #28 0xffff800101da1ed0 in Threads::create_vm
>>>>> (args=args at entry=0xffff800102638d78,
>>>>> canTryAgain=canTryAgain at entry=0xffff800102638c57) at
>>>>> /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:3637
>>>>> #29 0xffff800101570a78 in JNI_CreateJavaVM_inner
>>>>> (args=0xffff800102638d78, penv=0xffff800102638d70,
>>>>> vm=0xffff800102638d68) at
>>>>> /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:3929
>>>>> #30 JNI_CreateJavaVM (vm=0xffff800102638d68,
>>>>> penv=0xffff800102638d70, args=0xffff800102638d78) at
>>>>> /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:4024
>>>>> #31 0xffff8001003bfa74 in InitializeJVM (ifn=<synthetic pointer>,
>>>>> penv=0xffff800102638d70, pvm=0xffff800102638d68) at
>>>>> /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:1478
>>>>> #32 JavaMain (_args=<optimized out>) at
>>>>> /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:411
>>>>> #33 0xffff8001002a3874 in start_thread (arg=0xffff800102639910) at
>>>>> pthread_create.c:463
>>>>> #34 0xffff8001006bf140 in __thread_start () at
>>>>> ../sysdeps/unix/sysv/linux/sparc/sparc64/clone.S:78
>>>>> Backtrace stopped: previous frame identical to this frame (corrupt
>>>>> stack?)
>>>>
>>>> I think this means we are trying to use Resource area before the
>>>> thread is fully initialized. IIRC
>>>> that is forbidden. Looking at os::verify_memory:
>>>>
>>>> static void verify_memory(void* ptr) { // <--- frame #23
>>>> ?? GuardedMemory guarded(ptr);
>>>> ?? if (!guarded.verify_guards()) {
>>>> ???? LogTarget(Warning, malloc, free) lt;
>>>> ???? ResourceMark rm; // <--- frame #22
>>>> ???? LogStream ls(lt);
>>>> ???? ls.print_cr("## nof_mallocs = " UINT64_FORMAT ", nof_frees = "
>>>> UINT64_FORMAT...
>>>> ???? ls.print_cr("## memory stomp:");
>>>> ???? guarded.print_on(&ls);
>>>> ???? fatal("memory stomping error");
>>>> ?? }
>>>> }
>>>>
>>>> It seems we have *failed* the guarded memory check, entered the
>>>> branch, and then failed reporting
>>>> the failure. This must mean buffer overrun somewhere?
>>>>
>>>> Thanks,
>>>> -Aleksey
>>>>
From zgu at redhat.com Mon Apr 9 12:37:54 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 9 Apr 2018 08:37:54 -0400
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
Message-ID: <d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
> From the crash report:
>
> #19 0xffff800101e74cc0 in VMError::report_and_die (thread=0x0,
> context=context at entry=0x0, filename=filename at entry=0xffff800101f3fd58
> "/srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp",
> lineno=lineno at entry=720,
> ??? message=message at entry=0xffff800101f3fd30 "assert(current != __null)
> failed", detail_fmt=detail_fmt at entry=0xffff800101f3fd00
> "Thread::current() called on detached thread", detail_args=<optimized
> out>) at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1244
> #20 0xffff8001010e5d74 in report_vm_error (file=0xffff800101f3fd58
> "/srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp",
> line=line at entry=720, error_msg=0xffff800101f3fd30 "assert(current !=
> __null) failed",
> ??? detail_fmt=0xffff800101f3fd00 "Thread::current() called on detached
> thread") at /srv/openjdk/hs/src/hotspot/share/utilities/debug.cpp:230
> #21 0xffff800101a48fc0 in Thread::current () at
> /srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp:720
> #22 ResourceMark::ResourceMark (this=0xffff800102638600) at
> /srv/openjdk/hs/src/hotspot/share/memory/resourceArea.hpp:109
> #23 verify_memory (ptr=ptr at entry=0xffff80010400fda0) at
> /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:632
> #24 0xffff800101a4ea74 in os::free (memblock=0xffff80010400fda0) at
> /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:783
> #25 0xffff800101ee9df0 in CPUinfo::~CPUinfo (this=0xffff800102638888,
> __in_chrg=<optimized out>) at
> /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:59
>
>
> The use of the os* functions can lead us into code that uses
> ResourceMark and requires an attached thread.
Ah, I would argue that we should not get to this crash to begin with :-)
Thanks,
-Zhengyu
>
> David
> -----
>
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>>
>>> David
>>>
>>>> -Zhengyu
>>>>
>>>>
>>>> On 04/06/2018 09:12 AM, Aleksey Shipilev wrote:
>>>>> I would say dig here:
>>>>>
>>>>> On 04/06/2018 03:02 PM, John Paul Adrian Glaubitz wrote:
>>>>>> #20 0xffff8001010e5d74 in report_vm_error (file=0xffff800101f3fd58
>>>>>> detail_fmt=0xffff800101f3fd00 "Thread::current() called on
>>>>>> detached thread") at
>>>>>> #21 0xffff800101a48fc0 in Thread::current () at
>>>>>> /srv/openjdk/hs/src/hotspot/share/runtime/thread.hpp:720
>>>>>> #22 ResourceMark::ResourceMark (this=0xffff800102638600) at
>>>>>> /srv/openjdk/hs/src/hotspot/share/memory/resourceArea.hpp:109
>>>>>> #23 verify_memory (ptr=ptr at entry=0xffff80010400fda0) at
>>>>>> /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:632
>>>>>> #24 0xffff800101a4ea74 in os::free (memblock=0xffff80010400fda0)
>>>>>> at /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:783
>>>>>> #25 0xffff800101ee9df0 in CPUinfo::~CPUinfo
>>>>>> (this=0xffff800102638888, __in_chrg=<optimized out>) at
>>>>>> /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:59
>>>>>>
>>>>>> #26 VM_Version::platform_features () at
>>>>>> /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp:184
>>>>>>
>>>>>> #27 0xffff800101eea080 in VM_Version::determine_features () at
>>>>>> #28 0xffff800101da1ed0 in Threads::create_vm
>>>>>> (args=args at entry=0xffff800102638d78,
>>>>>> canTryAgain=canTryAgain at entry=0xffff800102638c57) at
>>>>>> /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:3637
>>>>>> #29 0xffff800101570a78 in JNI_CreateJavaVM_inner
>>>>>> (args=0xffff800102638d78, penv=0xffff800102638d70,
>>>>>> vm=0xffff800102638d68) at
>>>>>> /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:3929
>>>>>> #30 JNI_CreateJavaVM (vm=0xffff800102638d68,
>>>>>> penv=0xffff800102638d70, args=0xffff800102638d78) at
>>>>>> /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:4024
>>>>>> #31 0xffff8001003bfa74 in InitializeJVM (ifn=<synthetic pointer>,
>>>>>> penv=0xffff800102638d70, pvm=0xffff800102638d68) at
>>>>>> /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:1478
>>>>>> #32 JavaMain (_args=<optimized out>) at
>>>>>> /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:411
>>>>>> #33 0xffff8001002a3874 in start_thread (arg=0xffff800102639910) at
>>>>>> pthread_create.c:463
>>>>>> #34 0xffff8001006bf140 in __thread_start () at
>>>>>> ../sysdeps/unix/sysv/linux/sparc/sparc64/clone.S:78
>>>>>> Backtrace stopped: previous frame identical to this frame (corrupt
>>>>>> stack?)
>>>>>
>>>>> I think this means we are trying to use Resource area before the
>>>>> thread is fully initialized. IIRC
>>>>> that is forbidden. Looking at os::verify_memory:
>>>>>
>>>>> static void verify_memory(void* ptr) { // <--- frame #23
>>>>> ?? GuardedMemory guarded(ptr);
>>>>> ?? if (!guarded.verify_guards()) {
>>>>> ???? LogTarget(Warning, malloc, free) lt;
>>>>> ???? ResourceMark rm; // <--- frame #22
>>>>> ???? LogStream ls(lt);
>>>>> ???? ls.print_cr("## nof_mallocs = " UINT64_FORMAT ", nof_frees = "
>>>>> UINT64_FORMAT...
>>>>> ???? ls.print_cr("## memory stomp:");
>>>>> ???? guarded.print_on(&ls);
>>>>> ???? fatal("memory stomping error");
>>>>> ?? }
>>>>> }
>>>>>
>>>>> It seems we have *failed* the guarded memory check, entered the
>>>>> branch, and then failed reporting
>>>>> the failure. This must mean buffer overrun somewhere?
>>>>>
>>>>> Thanks,
>>>>> -Aleksey
>>>>>
From glaubitz at physik.fu-berlin.de Mon Apr 9 12:57:49 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 9 Apr 2018 14:57:49 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
Message-ID: <248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
On 04/09/2018 02:37 PM, Zhengyu Gu wrote:
>> The use of the os* functions can lead us into code that uses ResourceMark and requires an attached thread.
>
> Ah, I would argue that we should not get to this crash to begin with :-)
But I'm still not getting further :(.
Can anyone tell me what the state on Solaris/SPARC is? The assertion failure
should occur on Solaris as well I guess as the crash doesn't seem Linux-specific.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From coleen.phillimore at oracle.com Mon Apr 9 13:10:17 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 9 Apr 2018 09:10:17 -0400
Subject: RFR (M) 8198313: Wrap holder object for ClassLoaderData in a
WeakHandle
In-Reply-To: <8372a910-f110-05df-85d0-e7c1859e4de4@oracle.com>
References: <3fe8b4c5-3e1d-d192-07ce-0828e3982e75@oracle.com>
<9C48FEF4-59DD-4415-AF18-B95ADBDFACB4@oracle.com>
<c62305c3-4567-d5c1-7aca-c5d47f885978@oracle.com>
<304110c1-f4e0-63c8-d94b-bc779b737411@oracle.com>
<4C4FB5D1-A0BA-4CC8-ADB7-8BED6BC2B88C@oracle.com>
<8372a910-f110-05df-85d0-e7c1859e4de4@oracle.com>
Message-ID: <5223d028-8eed-1835-d857-e2a277530f61@oracle.com>
I had an extensive conversation offline with Stefan, Robbin and Kim and
have reworked this change to walk the CLDG weak roots with the
SystemDictionary.? Also, I moved the WeakHandle holder creation into the
ClassLoaderData constructor, and made WeakHandle a template class so
that multiple weak roots are supported.
open webrev at http://cr.openjdk.java.net/~coleenp/8198313.04/webrev
This passes tier1-5 tests on linux-x64 and windows-x64.? I've also done
another performance test aka. dev-submit with no significant difference.
The additional change to make _class_loader oop into an OopHandle or
otherwise remove from ClassLoaderData will be done as a separate change
because it breaks JFR.
Thanks,
Coleen
On 4/2/18 3:22 PM, coleen.phillimore at oracle.com wrote:
>
>
> On 3/31/18 2:40 PM, Kim Barrett wrote:
>>> On Mar 30, 2018, at 1:53 PM, coleen.phillimore at oracle.com wrote:
>>>
>>>
>>> I have an incremental and full .02 version with the changes
>>> discussed here.
>>>
>>> open webrev at
>>> http://cr.openjdk.java.net/~coleenp/8198313.02.incr/webrev
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8198313.02/webrev
>>>
>>> These have been retested on x86, all hotspot jtreg tests.
>>> thanks,
>>> Coleen
>> Looks good.
>>
>> In InstanceKlass::klass_holder_phantom, the klass_ prefix seems
>> unnecessary. I don't need a new webrev if you decide to change the
>> name.
>
> Since it's pre-existing, I don't think I'll address it with this change.
> Thank you for the review.
> Coleen
>
From robin.westberg at oracle.com Mon Apr 9 13:14:50 2018
From: robin.westberg at oracle.com (Robin Westberg)
Date: Mon, 9 Apr 2018 15:14:50 +0200
Subject: RFR: 8199736: Define WIN32_LEAN_AND_MEAN before including
windows.h
In-Reply-To: <8b8eff72-be6e-9b67-58b3-799de6ba10b4@oracle.com>
References: <7F114FA8-59F0-42F1-A0B8-33D8C22DE81A@oracle.com>
<D12695CA-4408-41EC-86B6-26A0C4738BD3@oracle.com>
<C651EF47-0E7D-4819-85EE-3DB164318011@oracle.com>
<d030055c-ce4b-e191-a6da-cc5e37b9ad0e@oracle.com>
<8b8eff72-be6e-9b67-58b3-799de6ba10b4@oracle.com>
Message-ID: <05FC20C9-C263-4F93-9B24-B53054B080E2@oracle.com>
Hi all,
For the record, here?s the final changeset after rebasing and fixing the conflict with 8199619.
Webrev: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.03/ <http://cr.openjdk.java.net/~rwestberg/8199736/webrev.03/>
Best regards,
Robin
> On 3 Apr 2018, at 12:18, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
>
> On 2018-03-26 01:03, David Holmes wrote:
>> Hi Robin,
>>
>> On 23/03/2018 10:37 PM, Robin Westberg wrote:
>>> Hi Kim & Erik,
>>>
>>> Certainly makes sense to define it from the build system, I?ve updated the patch accordingly:
>>>
>>> Full: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.01/ <http://cr.openjdk.java.net/~rwestberg/8199736/webrev.01/>
>>> Incremental: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00-01/ <http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00-01/>
>>
>> I'm a little unclear on the hotspot changes. If we define WIN32_LEAN_AND_MEAN then certain APIs like sockets are excluded from windows.h so we then have to include the specific header files like winsock2.h - is that right?
>
> Using WIN32_LEAN_AND_MEAN is good industry practice. We already do so for the JDK libraries. This trims down the number of files included by windows.h to a more manageble number. Several years ago, Microsoft did the (in my opinion) bad decision to let windows.h include a huge number of interfaces, unless this macro was defined. Using WIN32_LEAN_AND_MEAN and then explicitly including other API headers makes compilation faster, and the intention of the code clearer.
>
> On top of this, due to naming conflicts, it is not possible at all to use winsock2.h unless you define WIN32_LEAN_AND_MEAN, windows.h will then pull in the old v1 of winsock.
>
> /Magnus
>
>>
>> src/hotspot/share/interpreter/bytecodes.cpp
>>
>> I'm curious about this change. u_short comes from types.h on non-Windows, is it simply missing on Windows (at least once we have WIN32_LEAN_AND_MEAN defined) ?
>>
>> src/hotspot/share/utilities/ostream.cpp
>>
>> 1029 #endif
>> 1030 #if defined(_WINDOWS)
>>
>> Using elif could be marginally faster given the two sets of conditions are mutually exclusive.
>>
>> Thanks,
>> David
>>
>>> (Not quite sure if the definition belongs where I put it or a bit later where most other windows-specific JVM flags are defined, but seemed reasonable to put it close to where it is defined for the JDK libraries).
>>>
>>> Best regards,
>>> Robin
>>>
>>>> On 22 Mar 2018, at 16:52, Kim Barrett <kim.barrett at oracle.com> wrote:
>>>>
>>>>> On Mar 22, 2018, at 10:34 AM, Robin Westberg <robin.westberg at oracle.com> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Please review the following change that defines WIN32_LEAN_AND_MEAN [1] before including windows.h. This marginally improves build times, and makes it possible to include winsock2.h.
>>>>>
>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8199736 <https://bugs.openjdk.java.net/browse/JDK-8199736>
>>>>> Webrev: http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00/ <http://cr.openjdk.java.net/~rwestberg/8199736/webrev.00/>
>>>>> Testing: hs-tier1
>>>>>
>>>>> Best regards,
>>>>> Robin
>>>>>
>>>>> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa383745%28v=vs.85%29.aspx#faster_builds_with_smaller_header_files <https://msdn.microsoft.com/en-us/library/windows/desktop/aa383745(v=vs.85).aspx#faster_builds_with_smaller_header_files>
>>>>
>>>> I think the addition of the WIN32_LEAN_AND_MEAN definition should be done through the build
>>>> system, so that it applies everywhere.
>>>>
>>>
>
From gerard.ziemski at oracle.com Mon Apr 9 14:58:54 2018
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Mon, 9 Apr 2018 09:58:54 -0500
Subject: RFR (XL) 8081519 Split globals.hpp to factor out the Flag class
In-Reply-To: <eacc2551-1304-8819-907e-cdf3790e3783@oracle.com>
References: <D6E4A4E8-8356-4694-BD9C-03AB5FA5BC65@oracle.com>
<6656E162-56BE-4E75-8343-7567715F30C7@oracle.com>
<eacc2551-1304-8819-907e-cdf3790e3783@oracle.com>
Message-ID: <5BF7D0BC-971F-492C-8BE3-785393CE52C8@oracle.com>
Thank you Coleen for review.
> On Apr 6, 2018, at 3:51 PM, coleen.phillimore at oracle.com wrote:
>
>
> Gerard,
>
> It looks like these files get the include jvmFlag.hpp transitively from globals_ext.hpp, but can you add an explicit #include "runtime/flags/jvmFlag.hpp" to the files that you've changed that don't explicitly include jvmFlagsConstraintList.hpp and others? The include guards will prevent them from being included twice and it would be good if we ever change these to not include globals_ext.hpp. eg:
>
> http://cr.openjdk.java.net/~gziemski/8081519_rev2/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp.udiff.html
Will do.
cheers
From thomas.stuefe at gmail.com Mon Apr 9 15:03:40 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 9 Apr 2018 17:03:40 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
Message-ID: <CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
VM_Version::determine_features() needs a code blob, and hence
ResourceMark, on sparc and ppc and s390 I think.
But I think the reason that only sparc fails is that
VM_Version::determine_features() is called too early on Sparc (as part of
os::init_before_ergo()). The other platforms call that function later in
initialization (VM_Version_init() -> init_globals()). Could that be the
error, and if yes, could VM_Version::determine_features() be delayed?
(Apart from that - the strdup/os::free mismatch Zhengyu found is quite real
and should be fixed).
..Thomas
On Mon, Apr 9, 2018 at 2:57 PM, John Paul Adrian Glaubitz <
glaubitz at physik.fu-berlin.de> wrote:
> On 04/09/2018 02:37 PM, Zhengyu Gu wrote:
>
>> The use of the os* functions can lead us into code that uses ResourceMark
>>> and requires an attached thread.
>>>
>>
>> Ah, I would argue that we should not get to this crash to begin with :-)
>>
>
> But I'm still not getting further :(.
>
> Can anyone tell me what the state on Solaris/SPARC is? The assertion
> failure
> should occur on Solaris as well I guess as the crash doesn't seem
> Linux-specific.
>
>
> Adrian
>
> --
> .''`. John Paul Adrian Glaubitz
> : :' : Debian Developer - glaubitz at debian.org
> `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>
From robbin.ehn at oracle.com Mon Apr 9 15:05:21 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Mon, 9 Apr 2018 17:05:21 +0200
Subject: RFR (M) 8198313: Wrap holder object for ClassLoaderData in a
WeakHandle
In-Reply-To: <5223d028-8eed-1835-d857-e2a277530f61@oracle.com>
References: <3fe8b4c5-3e1d-d192-07ce-0828e3982e75@oracle.com>
<9C48FEF4-59DD-4415-AF18-B95ADBDFACB4@oracle.com>
<c62305c3-4567-d5c1-7aca-c5d47f885978@oracle.com>
<304110c1-f4e0-63c8-d94b-bc779b737411@oracle.com>
<4C4FB5D1-A0BA-4CC8-ADB7-8BED6BC2B88C@oracle.com>
<8372a910-f110-05df-85d0-e7c1859e4de4@oracle.com>
<5223d028-8eed-1835-d857-e2a277530f61@oracle.com>
Message-ID: <6a590ea6-723e-a10d-ab54-b7c5528e3bd8@oracle.com>
On 2018-04-09 15:10, coleen.phillimore at oracle.com wrote:
>
> I had an extensive conversation offline with Stefan, Robbin and Kim and have
> reworked this change to walk the CLDG weak roots with the SystemDictionary.
> Also, I moved the WeakHandle holder creation into the ClassLoaderData
> constructor, and made WeakHandle a template class so that multiple weak roots
> are supported.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8198313.04/webrev
Thanks, looks good.
/Robbin
>
> This passes tier1-5 tests on linux-x64 and windows-x64.? I've also done another
> performance test aka. dev-submit with no significant difference.
>
> The additional change to make _class_loader oop into an OopHandle or otherwise
> remove from ClassLoaderData will be done as a separate change because it breaks
> JFR.
>
> Thanks,
> Coleen
>
> On 4/2/18 3:22 PM, coleen.phillimore at oracle.com wrote:
>>
>>
>> On 3/31/18 2:40 PM, Kim Barrett wrote:
>>>> On Mar 30, 2018, at 1:53 PM, coleen.phillimore at oracle.com wrote:
>>>>
>>>>
>>>> I have an incremental and full .02 version with the changes discussed here.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8198313.02.incr/webrev
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8198313.02/webrev
>>>>
>>>> These have been retested on x86, all hotspot jtreg tests.
>>>> thanks,
>>>> Coleen
>>> Looks good.
>>>
>>> In InstanceKlass::klass_holder_phantom, the klass_ prefix seems
>>> unnecessary. I don't need a new webrev if you decide to change the
>>> name.
>>
>> Since it's pre-existing, I don't think I'll address it with this change.
>> Thank you for the review.
>> Coleen
>>
>
From coleen.phillimore at oracle.com Mon Apr 9 16:01:28 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 9 Apr 2018 12:01:28 -0400
Subject: RFR: 8200550: Xcode 9.3 produce warning on heapRegionSet.hpp
In-Reply-To: <1D3A3B61-7BC0-4A6E-B084-F2AAF464CEBE@oracle.com>
References: <0734D26B-5E3D-45A1-8321-23896819851A@oracle.com>
<1523098983.2294.7.camel@oracle.com>
<F5144B4C-CC79-44DE-8FA4-9D96B69C86B2@oracle.com>
<1523136263.2260.39.camel@oracle.com>
<1D3A3B61-7BC0-4A6E-B084-F2AAF464CEBE@oracle.com>
Message-ID: <f9bef787-c034-c606-4807-9d7d4f9d87c1@oracle.com>
On 4/9/18 2:55 AM, Kim Barrett wrote:
>> On Apr 7, 2018, at 5:24 PM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
>>
>> Hi,
>>
>> On Sat, 2018-04-07 at 15:48 -0400, Kim Barrett wrote:
>>>> On Apr 7, 2018, at 7:03 AM, Thomas Schatzl <thomas.schatzl at oracle.c
>>>> om> wrote:
>>>>
>>>> Hi Kim,
>>>>
>>>> On Fri, 2018-04-06 at 19:55 -0400, Kim Barrett wrote:
>>>>> Please review this fix of a couple of macro definitions that have
>>>>> "defined" expressions in the expansion. Such code has undefined
>>>>> behavior: C++03 16.1/3. Xcode 9.3 warns about such code.
>>>>>
>>>>> The fix for HEAP_REGION_SET_FORCE_VERIFY is a straight-forward
>>>>> change to use #ifdef ASSERT to define it appropriately.
>>>> It would imho be much nicer to remove the define and use the
>>>> available NOT_DEBUG_RETURN/#ifndef ASSERT macros to accomplish the
>>>> same thing. (I would also be fine with using
>>>> NOT_PRODUCT_RETURN/#ifndef
>>>> PRODUCT).
>>> That doesn?t accomplish the same thing. The present code allows one
>>> to explicitly define the macro on the (make) command line to override
>>> the default behavior (based on ASSERT). Are you suggesting removing
>>> that capability?
>> I have never anyone seen anyone using extra defines on the command line
>> and I am very certain I have never used them myselves, but maybe it
>> is common to do for others.
>> I can imagine people using them for initial development, and then
>> leaving them in "just in case", forgetting them rather quickly. This
>> and others are certainly not documented anywhere.
>>
>> It is also really easy to forget to remember to always specify the
>> correct defines, i.e. be sure that the build actually contains this
>> code too.
>>
>> That particular define has been introduced in 2011 and like many other
>> defines/paranoia checks/* in G1 code we removed over time this one
>> seems to duplicate the suggested (PRODUCT_RETURN / NOT_DEBUG_RETURN)
>> functionality.
>>
>> (Actually tbh, I have heard of HEAP_REGION_SET_FORCE_VERIFY for the
>> very first time. The heapRegionSet* files are very old parts of G1).
>>
>> Maybe Tony can comment.
> I'm not going to defend it. I don't much like this kind of littering
> of the code base either. I was trying to fix a build problem on some
> (not (yet) supported by Oracle) platforms, without making a judgement
> about the feature. But I'm happy to remove HEAP_REGION_SET_FORCE_VERIFY
> instead.
I agree - this sounds good to me.
>
>>> NOT_PRODUCT/#ifndef PRODUCT is the wrong choice, being contrary to to
>>> the intent of an optimize build to be similar in performance
>>> characteristics to a product build.
>> In my understanding there is an additional clause in that sentence:
>> "[...] to a product build, including some extra verification".
>>
>> There is lots of similar verification that uses PRODUCT_RETURN/#ifndef
>> PRODUCT that also already changes performance characteristics for an
>> optimized build.
>> See the other PRODUCT_RETURN uses (I can find 107 in just the gc
>> directory) in this and other files.
> That's not my understanding from discussions with John Masamitsu (who
> was the only person I knew of to regularly use and care about
> "optimized" builds). But it is certainly true there is a lot of code
> that violates that rule. I occasionally wonder whether anyone would
> care or notice if we killed off "optimized" builds; we don't test that
> mode, with the result that it is often broken.
We have an RFE open for removing the optimized builds but it's blocked
on a compiler change.
https://bugs.openjdk.java.net/browse/JDK-8183287
Coleen
>
>> So yes, I recommend removing this capability in this instance. This
>> verification does not seem to be any different than any other.
>>
>> Not sure if this capability is too expensive or not (this is typically
>> a bit fuzzy), but in the worst case one can use NOT_DEBUG_RETURN.
> Since it was previously only under ASSERT, I'm leaving it that way.
>
> New webrevs:
> full: http://cr.openjdk.java.net/~kbarrett/8200550/open.01/
> incr: http://cr.openjdk.java.net/~kbarrett/8200550/open.01.inc/
>
>
From simon at cjnash.com Mon Apr 9 16:12:38 2018
From: simon at cjnash.com (Simon Nash)
Date: Mon, 09 Apr 2018 17:12:38 +0100
Subject: Supported platforms
In-Reply-To: <4b1f262d-b9d2-6844-e453-dd53b42b2d74@oracle.com>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
<15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
<5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
<5ACA276C.7030505@cjnash.com>
<4b1f262d-b9d2-6844-e453-dd53b42b2d74@oracle.com>
Message-ID: <5ACB90F6.50607@cjnash.com>
On 09/04/2018 08:55, Magnus Ihse Bursie wrote:
>
> Simon,
>
> On 2018-04-08 16:30, Simon Nash wrote:
>> On 05/04/2018 02:26, bren at juanantonio.info wrote:
>>>
>>> Many thanks with the link about the Platforms supported:
>>> http://www.oracle.com/technetwork/java/javase/documentation/jdk10certconfig-4417031.html
>>>
>> This appears to be a list of the platforms that are supported
>> (certified) by
>> Oracle. Where can I find the list of platforms that are supported by
>> OpenJDK? For example, what about the following platforms that don't
>> appear
>> on the Oracle list:
>>
>> Windows x86
>> Linux x86
>> aarch32 (ARMv7 32-bit)
>> aarch64 (ARMv8 64-bit)
>>
>> Are all these supported for OpenJDK 9, 10 and 11?
>
> There is actually no such thing as a "supported OpenJDK platform". While
> I hope things may change in the future, OpenJDK as an organization does
> not publicize any list of "supported" platforms. Oracle publishes a list
> of platforms they support, and I presume that Red Hat and SAP and others
> do the same, but the OpenJDK project itself does not.
>
> With that said, platforms which were previously supported by Oracle
> (like the one's you mentioned) tend to still work more-or-less well, but
> they receive no or little testing, and is prone to bit rot.
>
> /Magnus
>
Magnus,
Thanks for this. I think I should clarify what I mean by a supported
platform. This would be a platform for which bugs affecting the ability
to build a working OpenJDK binary for that platform would be considered
valid by the OpenJDK community and a user-submitted patch to fix such a
bug would be considered for integration into the OpenJDK codebase.
Simon
>>
>> Simon
>
From glaubitz at physik.fu-berlin.de Mon Apr 9 16:33:00 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 9 Apr 2018 18:33:00 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
Message-ID: <ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
On 04/09/2018 05:03 PM, Thomas St?fe wrote:
> VM_Version::determine_features()?needs a code blob, and hence ResourceMark, on sparc and ppc and s390 I think.
>
> But I think the reason that only sparc fails is that VM_Version::determine_features() is called too early on Sparc (as part of os::init_before_ergo()). The
> other platforms call that function later in initialization (VM_Version_init() -> init_globals()). Could that be the error, and if yes, could?
> VM_Version::determine_features()??be delayed?
I just did that but it doesn't really change anything for me.
The main problem is still the assertion failure which I don't really understand
is supposed to tell me.
Would be nice if any of the SPARC experts could comment on this:
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=/assembler_sparc.cpp:52
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.cpp:52), pid=18610, tid=18620
# assert(!(is_cti(prev) && is_cti(insn))) failed: CTI-CTI not allowed.
#
# JRE version: OpenJDK Runtime Environment (11.0) (fastdebug build 11-internal+0-adhoc.glaubitz.hs)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 11-internal+0-adhoc.glaubitz.hs, mixed mode, tiered, compressed oops, serial gc, linux-sparc)
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /srv/openjdk/hs/make/hs_err_pid18610.log
#
# Compiler replay data is saved as:
# /srv/openjdk/hs/make/replay_pid18610.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
Current thread is 18620
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From neugens at redhat.com Mon Apr 9 16:40:31 2018
From: neugens at redhat.com (Mario Torre)
Date: Mon, 9 Apr 2018 18:40:31 +0200
Subject: Supported platforms
In-Reply-To: <5ACB90F6.50607@cjnash.com>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
<15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
<5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
<5ACA276C.7030505@cjnash.com>
<4b1f262d-b9d2-6844-e453-dd53b42b2d74@oracle.com>
<5ACB90F6.50607@cjnash.com>
Message-ID: <CAJwKKmbdaARqETcDXB88YnO6d=_Tuba4BAkDYb2uM5n=8a-FOg@mail.gmail.com>
On Mon, Apr 9, 2018 at 6:12 PM, Simon Nash <simon at cjnash.com> wrote:
> Thanks for this. I think I should clarify what I mean by a supported
> platform. This would be a platform for which bugs affecting the ability
> to build a working OpenJDK binary for that platform would be considered
> valid by the OpenJDK community and a user-submitted patch to fix such a
> bug would be considered for integration into the OpenJDK codebase.
Being a Community project, I would say everything that is relevant for
users is relevant for the project.
Now, "everything" doesn't mean "absolutely" everything of course ;)
but within reasonable limits "almost" everything is a good bet. If you
plan in adding support for new architectures you will have better luck
with a Porting sponsored projects, if you want to fix some bugs in
some weird architecture that is already existing, or help building
with some Linux distribution not currently covered for some reason,
I'm sure that will be accepted quickly too, in all cases some
discussion would be good to have before start proposing patches.
But again, this is a case-by-case thing, so probably you can just tell
us what you are interested in contributing and see if there are
objections or other reasons not to have that code in.
Cheers,
Mario
--
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898
From gerard.ziemski at oracle.com Mon Apr 9 16:53:31 2018
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Mon, 9 Apr 2018 11:53:31 -0500
Subject: RFR: 8201168: Move GC command line constraint functions to GC
specific files
In-Reply-To: <99b6d120-44bf-b243-7fa1-5a5cb9c44b8b@oracle.com>
References: <99b6d120-44bf-b243-7fa1-5a5cb9c44b8b@oracle.com>
Message-ID: <1964E10D-BA6B-4B2B-82CC-0F3E51AB5A71@oracle.com>
hi Stefan,
Nice cleanup, looks good.
Shouldn?t the new files have just ?2018," as the copyright year, not "2015, 2018,"?
Also, what tests did you run?
ps. Don?t worry about my changes, I will wait for yours to go in, then I?ll merge.
cheers
> On Apr 5, 2018, at 5:03 AM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
>
> Hi all,
>
> Please review this patch to move the GC flag constraint functions into GC specific files.
>
> http://cr.openjdk.java.net/~stefank/8201168/webrev.01
> https://bugs.openjdk.java.net/browse/JDK-8201168
>
> This is one step towards:
>
> https://bugs.openjdk.java.net/browse/JDK-8200729 - Conditional compilation of GCs
>
> I know that this conflicts with Gerards rename of the flags to JVMFlags, but I don't want to wait for that to get pushed before publishing this review request.
>
> Thanks,
> StefanK
From coleen.phillimore at oracle.com Mon Apr 9 17:05:25 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 9 Apr 2018 13:05:25 -0400
Subject: RFR (M) 8198313: Wrap holder object for ClassLoaderData in a
WeakHandle
In-Reply-To: <6a590ea6-723e-a10d-ab54-b7c5528e3bd8@oracle.com>
References: <3fe8b4c5-3e1d-d192-07ce-0828e3982e75@oracle.com>
<9C48FEF4-59DD-4415-AF18-B95ADBDFACB4@oracle.com>
<c62305c3-4567-d5c1-7aca-c5d47f885978@oracle.com>
<304110c1-f4e0-63c8-d94b-bc779b737411@oracle.com>
<4C4FB5D1-A0BA-4CC8-ADB7-8BED6BC2B88C@oracle.com>
<8372a910-f110-05df-85d0-e7c1859e4de4@oracle.com>
<5223d028-8eed-1835-d857-e2a277530f61@oracle.com>
<6a590ea6-723e-a10d-ab54-b7c5528e3bd8@oracle.com>
Message-ID: <4d5e0548-660b-1cd3-95c2-68bcf1adf3ab@oracle.com>
On 4/9/18 11:05 AM, Robbin Ehn wrote:
> On 2018-04-09 15:10, coleen.phillimore at oracle.com wrote:
>>
>> I had an extensive conversation offline with Stefan, Robbin and Kim
>> and have reworked this change to walk the CLDG weak roots with the
>> SystemDictionary.? Also, I moved the WeakHandle holder creation into
>> the ClassLoaderData constructor, and made WeakHandle a template class
>> so that multiple weak roots are supported.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8198313.04/webrev
>
> Thanks, looks good.
Thank you, Robbin and for the suggested changes for WeakHandle.
Coleen
>
> /Robbin
>
>>
>> This passes tier1-5 tests on linux-x64 and windows-x64.? I've also
>> done another performance test aka. dev-submit with no significant
>> difference.
>>
>> The additional change to make _class_loader oop into an OopHandle or
>> otherwise remove from ClassLoaderData will be done as a separate
>> change because it breaks JFR.
>>
>> Thanks,
>> Coleen
>>
>> On 4/2/18 3:22 PM, coleen.phillimore at oracle.com wrote:
>>>
>>>
>>> On 3/31/18 2:40 PM, Kim Barrett wrote:
>>>>> On Mar 30, 2018, at 1:53 PM, coleen.phillimore at oracle.com wrote:
>>>>>
>>>>>
>>>>> I have an incremental and full .02 version with the changes
>>>>> discussed here.
>>>>>
>>>>> open webrev at
>>>>> http://cr.openjdk.java.net/~coleenp/8198313.02.incr/webrev
>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8198313.02/webrev
>>>>>
>>>>> These have been retested on x86, all hotspot jtreg tests.
>>>>> thanks,
>>>>> Coleen
>>>> Looks good.
>>>>
>>>> In InstanceKlass::klass_holder_phantom, the klass_ prefix seems
>>>> unnecessary. I don't need a new webrev if you decide to change the
>>>> name.
>>>
>>> Since it's pre-existing, I don't think I'll address it with this
>>> change.
>>> Thank you for the review.
>>> Coleen
>>>
>>
From magnus.ihse.bursie at oracle.com Mon Apr 9 17:23:52 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 9 Apr 2018 19:23:52 +0200
Subject: RFR: JDK-8201236 Straighten out dtrace build logic
In-Reply-To: <5de3a167-0df7-6bae-050e-333f3abccde6@oracle.com>
References: <760d77ab-77c8-451a-2f02-fceaaeef38b8@oracle.com>
<5de3a167-0df7-6bae-050e-333f3abccde6@oracle.com>
Message-ID: <04b9cfaa-61d1-3b71-8a04-45755d4c620a@oracle.com>
On 2018-04-06 17:23, Erik Joelsson wrote:
> Looks good in general.
>
> In JvmDtraceObjects.gmk, comment on line 38 needs to be updated.
Nice spotting! It was left-over from before. I deleted it, the paragraph
above said the same thing but correctly.
/Magnus
>
> /Erik
>
>
> On 2018-04-06 03:57, Magnus Ihse Bursie wrote:
>> The dtrace build logic was copied straight out of the old Hotspot
>> build system, and is quite convoluted.
>>
>> It should be split into the separate parts it actually contains of:
>> 1) A gensrc step which runs with other gensrc ahead of compilation
>> 2) Two independent libraries that can be build at any time
>> 3) Two special dtrace-generated .o files that must be linked with the
>> JVM
>>
>> I have also cleaned up includes in generateJvmOffsets.cpp.
>>
>> I have verified with COMPARE_BUILD that no changes has happened in
>> any native library.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201236
>> WebRev:
>> http://cr.openjdk.java.net/~ihse/JDK-8201236-straighten-out-dtrace/webrev.01
>>
>> /Magnus
>
From chris.plummer at oracle.com Mon Apr 9 18:05:28 2018
From: chris.plummer at oracle.com (Chris Plummer)
Date: Mon, 9 Apr 2018 11:05:28 -0700
Subject: RFR (M): 8201247: Various cleanups in the attach framework
In-Reply-To: <a3248ff5584e4186acc8a3baec06ab4b@sap.com>
References: <14dff9b0cf5a4b888aef1d6452801b57@sap.com>
<91d75e2d-47a4-e9ee-5d19-8f3e6dc13428@oracle.com>
<a3248ff5584e4186acc8a3baec06ab4b@sap.com>
Message-ID: <1497c4c6-d95e-7e25-b503-cc7da9d6d077@oracle.com>
Hi Christoph,
We have some closed "attach on demand" tests that should be run also. I
can do this for you when you are ready. Please also let me know which
other jtreg tests you have run.
thanks,
Chris
On 4/9/18 12:08 AM, Langer, Christoph wrote:
> Hi Chris,
>
> thanks for looking into this.
>
> As for ArgumentIterator::next, I must admit, I found this patch in our code base when taking over the code. I believe that an issue would be seen if an attach operation has 2 or 3 arguments and the first one is NULL/empty. I guess such a situation can't happen with the attach operations currently existing in OpenJDK as none of these ops would allow such type of arguments. However, in our implementation, we have for instance enhanced the "dump_heap" operation to work with null as first argument where one usually would specify the desired output file name. We implemented a mechanism to compute a default filename when the param is left blank. So we need the fix for that case, I guess.
>
> I'll run the patch through the submission forest now and do some jtreg testing.
>
> Best regards
> Christoph
>
>> -----Original Message-----
>> From: Chris Plummer [mailto:chris.plummer at oracle.com]
>> Sent: Freitag, 6. April 2018 18:37
>> To: Langer, Christoph <christoph.langer at sap.com>; serviceability-
>> dev at openjdk.java.net
>> Cc: hotspot-dev at openjdk.java.net
>> Subject: Re: RFR (M): 8201247: Various cleanups in the attach framework
>>
>> Hi Christoph,
>>
>> Can you explain a bit more about "fix handling of null values in
>> ArgumentIterator::next". When does this turn up? Is there a test case?
>>
>> Everything else looks good.
>>
>> thanks,
>>
>> Chris
>>
>> On 4/6/18 8:01 AM, Langer, Christoph wrote:
>>> Hi,
>>>
>>> can I please get reviews for a set of clean up changes that I came
>>> across when doing some integration work.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201247
>>> <https://bugs.openjdk.java.net/browse/JDK-8201247>
>>>
>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/
>>> <http://cr.openjdk.java.net/%7Eclanger/webrevs/8201247.0/>
>>>
>>> Detailed comments about the changes can be found in the bug.
>>>
>>> Thanks & best regards
>>>
>>> Christoph
>>>
From gerard.ziemski at oracle.com Mon Apr 9 18:35:21 2018
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Mon, 9 Apr 2018 13:35:21 -0500
Subject: RFR (XL) 8081519 Split globals.hpp to factor out the Flag class
In-Reply-To: <6656E162-56BE-4E75-8343-7567715F30C7@oracle.com>
References: <D6E4A4E8-8356-4694-BD9C-03AB5FA5BC65@oracle.com>
<6656E162-56BE-4E75-8343-7567715F30C7@oracle.com>
Message-ID: <8009E1D8-0493-48FC-97C3-3BBDFE76A13F@oracle.com>
Hi all,
Here is http://cr.openjdk.java.net/~gziemski/8081519_rev3 with the addition requested by Coleen to include jvmFlag.hpp directly anywhere jvmFlag is used.
Tested locally with open/closed, debug/product, precompiled header/no precompiled header build variations.
cheers
> On Apr 5, 2018, at 12:46 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
>
> Hi all,
>
> Here is webrev 2 with the following additions:
>
> #1 Factor FlagSetting class out of "runtime/flags/jvmFlag.hpp" and into its own "runtime/flags/flagSetting.hpp", so that FlagSetting class can extend from ?public StackObj? (thanks Coleen)
>
> #2 change the hierarchy from ?runtime/jvmFlag/? to "runtime/flags/? (thanks David)
>
> #3 Fix the header files, so that both closed and open repository build with and without precompiled headers
>
> #4 Add ?runtime/flags/*.hpp? headers to ?precompiled.hpp?
>
> The number of touched files got even longer - sorry about that and big thank you for taking your time to review!
>
> Running final Mach5 hs_tier1-5 tests? (it passed earlier iterations). Passes local builds (on Mac OS X) with and without precompiled headers for both closed and open repos and both debug and product versions (should I try any other build varations?)
>
> http://cr.openjdk.java.net/~gziemski/8081519_rev2
>
>
> cheers
>
>> On Mar 29, 2018, at 2:01 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
>>
>> Hi all,
>>
>> Please review this large and tedious (sorry), but simple fix that accomplishes the following:
>>
>> #1 factor out the command option flag related APIs out of globals.hpp/.cpp into its own dedicated files, i.e. jvmFlag.hpp/.cpp
>> #2 merge Flag (too generic name) and CommandLineFlag classes and rename them as JVMFlag
>> #3 cleanup globals.hpp includes originally added by the JEP-245
>>
>> Note: the renamed file retain their history, but one needs to add ?follow? flag, ex. ?hg log -f file?
>>
>> https://bugs.openjdk.java.net/browse/JDK-8081519
>> http://cr.openjdk.java.net/~gziemski/8081519_rev1
>>
>> Passes Mach5 hs_tier1-tier5, jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges tests.
>>
>>
>> cheers
>
From kim.barrett at oracle.com Mon Apr 9 19:33:13 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 9 Apr 2018 15:33:13 -0400
Subject: RFR (M) 8198313: Wrap holder object for ClassLoaderData in a
WeakHandle
In-Reply-To: <5223d028-8eed-1835-d857-e2a277530f61@oracle.com>
References: <3fe8b4c5-3e1d-d192-07ce-0828e3982e75@oracle.com>
<9C48FEF4-59DD-4415-AF18-B95ADBDFACB4@oracle.com>
<c62305c3-4567-d5c1-7aca-c5d47f885978@oracle.com>
<304110c1-f4e0-63c8-d94b-bc779b737411@oracle.com>
<4C4FB5D1-A0BA-4CC8-ADB7-8BED6BC2B88C@oracle.com>
<8372a910-f110-05df-85d0-e7c1859e4de4@oracle.com>
<5223d028-8eed-1835-d857-e2a277530f61@oracle.com>
Message-ID: <6A97EFE4-58F5-4916-B59B-7A0AB39F8817@oracle.com>
> On Apr 9, 2018, at 9:10 AM, coleen.phillimore at oracle.com wrote:
>
>
> I had an extensive conversation offline with Stefan, Robbin and Kim and have reworked this change to walk the CLDG weak roots with the SystemDictionary. Also, I moved the WeakHandle holder creation into the ClassLoaderData constructor, and made WeakHandle a template class so that multiple weak roots are supported.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8198313.04/webrev
>
> This passes tier1-5 tests on linux-x64 and windows-x64. I've also done another performance test aka. dev-submit with no significant difference.
>
> The additional change to make _class_loader oop into an OopHandle or otherwise remove from ClassLoaderData will be done as a separate change because it breaks JFR.
------------------------------------------------------------------------------
src/hotspot/share/oops/weakHandle.inline.hpp
Do resolve and peek actually need a check for NULL? Could they assert
non-null instead? I'm guessing that the places that need these
operations should never get there with a not-initialized handle.
Oh, but maybe this is needed for the null class loader? If so, ick!
------------------------------------------------------------------------------
src/hotspot/share/oops/weakHandle.hpp
60 void clear() { _obj = NULL; } // for class loading race loss
Is this really needed? Why not just call release?
Especially since the one caller (CLD::update_holder) looks
suspiciously like a leak of an OopStorage entry.
------------------------------------------------------------------------------
src/hotspot/share/classfile/classLoaderData.cpp
104 ClassLoaderData::ClassLoaderData(Handle h_class_loader, bool is_anonymous) :
Re: Removal of _packages(NULL) from the initializer list, I would have
instead initialized all the members in the initializer list, and then
update them when appropriate. That would eliminate the else-clause
starting at line 137, and (to me) make the state easier to follow.
------------------------------------------------------------------------------
src/hotspot/share/classfile/classLoaderData.cpp
978 // need to clear the holder for this case.
979 cld->update_holder(Handle());
If WeakHandle::release had
RootAccess<ON_PHANTOM_OOP_REF>::oop_store(_obj, (oop)NULL);
before calling OopStorage::release, then I think the above two lines
aren't needed?
------------------------------------------------------------------------------
src/hotspot/share/classfile/classLoaderData.cpp
1250 int loaders_processed = 0;
1251 int loaders_removed = 0;
s/int/uint/
And update the log message to use %u rather than %d.
------------------------------------------------------------------------------
src/hotspot/share/classfile/classLoaderData.hpp
224 oop _class_loader; // oop used to uniquely identify a class loader
225 // class loader or a canonical class path
Lost earlier (some previous webrev in this series, I think) fix to the
comment.
------------------------------------------------------------------------------
src/hotspot/share/classfile/systemDictionary.cpp
1018 // Anonymous classes must update ClassLoaderData holder (was host_klass loader)
1019 // so that they can be unloaded when the mirror is no longer referenced.
1020 k->class_loader_data()->update_holder(Handle(THREAD, k->java_mirror()));
The comment here suggests the holder has been set to something else
and now we need to update it. But the CLD constructor only calls
update_holder for non-anonymous classes. This suggests that if the
call to update_holder mentioned above (to clear it) were eliminated,
then update_holder could be once-only (with an assert) and should be
called initialize_holder.
------------------------------------------------------------------------------
From erik.osterlund at oracle.com Mon Apr 9 20:05:08 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Mon, 9 Apr 2018 22:05:08 +0200
Subject: RFR: 8199417: Modularize interpreter GC barriers
In-Reply-To: <80295FD9-254E-4670-AB47-E2A4B36C4143@oracle.com>
References: <5AB8BDF9.4050106@oracle.com>
<3FFD79AD-84B8-4E9E-98E3-47ACBA01D91F@oracle.com>
<5AC4D555.9040800@oracle.com>
<80295FD9-254E-4670-AB47-E2A4B36C4143@oracle.com>
Message-ID: <b6cdaf49-4715-7193-51ff-c3c19581d497@oracle.com>
Hi Kim,
Thank you for looking at this. Since this was well received, I went
ahead and implemented something similar on SPARC as well. Also added
support for storing roots (rather than asserting that stores are in the
heap only), just in case we need it in the future.
Full webrev:
http://cr.openjdk.java.net/~eosterlund/8199417/webrev.02/
Incremental webrev:
http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01_02/
On 2018-04-06 01:38, Kim Barrett wrote:
>> On Apr 4, 2018, at 9:38 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>>
>> Hi Kim,
>>
>> Thank you for reviewing this.
>>
>> I have made a new webrev with proposed changes to the x86/x64 code reflecting the concerns you and Coleen have.
>> I thought we should settle for something we like in the x86/x64 code before going ahead and changing the other platforms too much (I don't want to bug Martin and Roman too much before).
>>
>> New full webrev:
>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01/
>>
>> Incremental:
>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.00_01/
> This looks better, and you've mostly answered the issues I've raised
> so far. Some further discussion inline below.
I'm glad to hear that.
> Other things have come up and I'm not going to be able to properly get
> back to this soon; don't hold up on my account, just drop me as a
> reviewer.
>
>> On 2018-04-01 05:12, Kim Barrett wrote:
>>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>>> 364 #ifndef _LP64
>>> 365 InterpreterMacroAssembler *imasm = static_cast<InterpreterMacroAssembler*>(masm);
>>> 366 #endif
>>>
>>> In the old code, the function received an InterpreterMacroAssembler*.
>>>
>>> What is there about this context that lets us know the downcast is
>>> safe here? Is oop_store_at only ever called with an IMA*? If so,
>>> then why isn't that the parameter type. If not, then what?
>> Yes, this is indeed only used by the InterpreterMacroAssembler. But I wanted the interface to use MacroAssembler. Why?
>>
>> 1) It's only 32 bit x86 that relies on this property, and I hope it will go away soon, and the save bcp hack with it.
>> 2) previous load_heap_oop is used not only in the InterpreterMacroAssembler, and I wanted the same assembler in load_at and store_at.
>>
>> So for now it is only used in InterpreterMacroAssembler, and I doubt that will change any time soon. I am hoping 32 bit support will be dropped before that, and the hack will go away. For now, I have added a virtual is_interpreter_masm() call that I use in an assert to make sure this is not accidentally used in the wrong context until 32 bit support is gone.
> The comment plus the new assert satisfies my complaint.
Thanks.
>>> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>>> 698 address TemplateInterpreterGenerator::generate_Reference_get_entry(void) {
>>>
>>> Almost all the code here (and much of the commentary) was/is specific
>>> to G1 (or SATB collectors). Shouldn't it all be in the barrier_set's
>>> load_at? As it is now, if (say) we're using Parallel GC then I think
>>> there's a bunch of additional code being generated and executed here
>>> that wasn't present before.
>> It is true that interpreter Reference.get() intrinsics with Parallel/CMS/Serial currently run a few instructions more than they need to pay for the abstraction. There is no doubt in my mind that this abstraction is worth the cost. Reference.get in the interpreter is not a hot path, and does not need to optimize every cycle.
>>
>> I changed the G1 comments to more general comments instead.
> Good point on this not being a hot path.
>
> "Preserve the sender sp in case the pre-barrier
> calls the runtime"
>
> s/the pre-barrier/a load barrier/
Fixed.
>>> src/hotspot/cpu/x86/gc/shared/modRefBarrierSetAssembler_x86.cpp
>>> 86 void ModRefBarrierSetAssembler::store_at(MacroAssembler* masm, DecoratorSet decorators, BasicType type,
>>> 87 Address dst, Register val, Register tmp1, Register tmp2) {
>>> 88 if (type == T_OBJECT || type == T_ARRAY) {
>>> 89 oop_store_at(masm, decorators, type, dst, val, tmp1, tmp2);
>>> 90 } else {
>>> 91 BarrierSetAssembler::store_at(masm, decorators, type, dst, val, tmp1, tmp2);
>>> 92 }
>>> 93 }
>>>
>>> Doesn't the conditional conversion from store_at to oop_store_at
>>> actually indicate a bug in the caller? That is, calling store_at with
>>> a oop (T_OBJECT or T_ARRAY) value seems like a bug, and should be
>>> asserted against, rather than translating.
>>>
>>> And oop_store_at should assert that the value *is* an oop value.
>>>
>>> And should there be any verification that the decorators and the type
>>> are consistent?
>>>
>>> But maybe I'm not understanding the protocol around oop_store_at?
>>> There being no documentation, it seems entirely possible that I've
>>> misunderstood something here. Maybe I'm being confused by
>>> similarities in naming with Access:: that don't hold?
>> The confusion roots in that Access and BarrierSetAssembler are not structured exactly the same.
>>
>> Access provides store_at and oop_store_at. The reason for providing both of these, is that I could not safely infer whether the passed in parameters were oops or not without changing oop and narrowOop to always be value objects, which I did not dare to do as the generated code was worse.
>>
>> In BarrierSetAssembler, there is no such restriction. The type for the access is always passed in to store_at/load_at as BasicType. It is the responsibility of ModRefBarrierSetAssembler to filter away non-oop references, and call oop_store_at for relevant accesses for ModRef. This follows the same pattern that the arraycopy stubs used. This allows, e.g. CardTableModRef to only override oop_store_at. This is similar to how ModRefBarrierSet::AccessBarrier<decorators, BarrierSetT>::oop_store_in_heap calls the concrete barriersets for help generating that access. I hope this helps understanding the structuring.
>>
>> This is also the reason why G1BarrierSetAssembler::load_at checks whether it is an oop that is loaded or not, because loads are not riding on the ModRef layer, which only knows about oop stores.
> I see. The naming congurence, along with my having glazed over the
> fact that oop_store_at is protected rather than public, led me astray.
> I don't have any better suggestions for naming. I would have found
> some comments describing the protocols helpful.
I added some comments describing the idea behind ModRef.
> Shouldn't ModRef::oop_store_at be pure virtual? That would have
> helped my understanding too.
Sure. Fixed.
Thanks,
/Erik
From kim.barrett at oracle.com Mon Apr 9 20:07:46 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 9 Apr 2018 16:07:46 -0400
Subject: RFR: 8200550: Xcode 9.3 produce warning on heapRegionSet.hpp
In-Reply-To: <f9bef787-c034-c606-4807-9d7d4f9d87c1@oracle.com>
References: <0734D26B-5E3D-45A1-8321-23896819851A@oracle.com>
<1523098983.2294.7.camel@oracle.com>
<F5144B4C-CC79-44DE-8FA4-9D96B69C86B2@oracle.com>
<1523136263.2260.39.camel@oracle.com>
<1D3A3B61-7BC0-4A6E-B084-F2AAF464CEBE@oracle.com>
<f9bef787-c034-c606-4807-9d7d4f9d87c1@oracle.com>
Message-ID: <B77AB943-4BE3-4602-BB51-9A9EC85C79EC@oracle.com>
> On Apr 9, 2018, at 12:01 PM, coleen.phillimore at oracle.com wrote:
>
>
>
> On 4/9/18 2:55 AM, Kim Barrett wrote:
>>> On Apr 7, 2018, at 5:24 PM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> On Sat, 2018-04-07 at 15:48 -0400, Kim Barrett wrote:
>>>>> On Apr 7, 2018, at 7:03 AM, Thomas Schatzl <thomas.schatzl at oracle.c
>>>>> om> wrote:
>>>>>
>>>>> Hi Kim,
>>>>>
>>>>> On Fri, 2018-04-06 at 19:55 -0400, Kim Barrett wrote:
>>>>>> Please review this fix of a couple of macro definitions that have
>>>>>> "defined" expressions in the expansion. Such code has undefined
>>>>>> behavior: C++03 16.1/3. Xcode 9.3 warns about such code.
>>>>>>
>>>>>> The fix for HEAP_REGION_SET_FORCE_VERIFY is a straight-forward
>>>>>> change to use #ifdef ASSERT to define it appropriately.
>>>>> It would imho be much nicer to remove the define and use the
>>>>> available NOT_DEBUG_RETURN/#ifndef ASSERT macros to accomplish the
>>>>> same thing. (I would also be fine with using
>>>>> NOT_PRODUCT_RETURN/#ifndef
>>>>> PRODUCT).
>>>> That doesn?t accomplish the same thing. The present code allows one
>>>> to explicitly define the macro on the (make) command line to override
>>>> the default behavior (based on ASSERT). Are you suggesting removing
>>>> that capability?
>>> I have never anyone seen anyone using extra defines on the command line
>>> and I am very certain I have never used them myselves, but maybe it
>>> is common to do for others.
>>> I can imagine people using them for initial development, and then
>>> leaving them in "just in case", forgetting them rather quickly. This
>>> and others are certainly not documented anywhere.
>>>
>>> It is also really easy to forget to remember to always specify the
>>> correct defines, i.e. be sure that the build actually contains this
>>> code too.
>>>
>>> That particular define has been introduced in 2011 and like many other
>>> defines/paranoia checks/* in G1 code we removed over time this one
>>> seems to duplicate the suggested (PRODUCT_RETURN / NOT_DEBUG_RETURN)
>>> functionality.
>>>
>>> (Actually tbh, I have heard of HEAP_REGION_SET_FORCE_VERIFY for the
>>> very first time. The heapRegionSet* files are very old parts of G1).
>>>
>>> Maybe Tony can comment.
>> I'm not going to defend it. I don't much like this kind of littering
>> of the code base either. I was trying to fix a build problem on some
>> (not (yet) supported by Oracle) platforms, without making a judgement
>> about the feature. But I'm happy to remove HEAP_REGION_SET_FORCE_VERIFY
>> instead.
>
> I agree - this sounds good to me.
Thanks.
>>>> NOT_PRODUCT/#ifndef PRODUCT is the wrong choice, being contrary to to
>>>> the intent of an optimize build to be similar in performance
>>>> characteristics to a product build.
>>> In my understanding there is an additional clause in that sentence:
>>> "[...] to a product build, including some extra verification".
>>>
>>> There is lots of similar verification that uses PRODUCT_RETURN/#ifndef
>>> PRODUCT that also already changes performance characteristics for an
>>> optimized build.
>>> See the other PRODUCT_RETURN uses (I can find 107 in just the gc
>>> directory) in this and other files.
>> That's not my understanding from discussions with John Masamitsu (who
>> was the only person I knew of to regularly use and care about
>> "optimized" builds). But it is certainly true there is a lot of code
>> that violates that rule. I occasionally wonder whether anyone would
>> care or notice if we killed off "optimized" builds; we don't test that
>> mode, with the result that it is often broken.
>
> We have an RFE open for removing the optimized builds but it's blocked on a compiler change.
> https://bugs.openjdk.java.net/browse/JDK-8183287
It makes sense for the compiler folks to want to use optimized builds.
> Coleen
>>
>>> So yes, I recommend removing this capability in this instance. This
>>> verification does not seem to be any different than any other.
>>>
>>> Not sure if this capability is too expensive or not (this is typically
>>> a bit fuzzy), but in the worst case one can use NOT_DEBUG_RETURN.
>> Since it was previously only under ASSERT, I'm leaving it that way.
>>
>> New webrevs:
>> full: http://cr.openjdk.java.net/~kbarrett/8200550/open.01/
>> incr: http://cr.openjdk.java.net/~kbarrett/8200550/open.01.inc/
From kim.barrett at oracle.com Mon Apr 9 20:45:22 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 9 Apr 2018 16:45:22 -0400
Subject: RFR: 8199417: Modularize interpreter GC barriers
In-Reply-To: <b6cdaf49-4715-7193-51ff-c3c19581d497@oracle.com>
References: <5AB8BDF9.4050106@oracle.com>
<3FFD79AD-84B8-4E9E-98E3-47ACBA01D91F@oracle.com>
<5AC4D555.9040800@oracle.com>
<80295FD9-254E-4670-AB47-E2A4B36C4143@oracle.com>
<b6cdaf49-4715-7193-51ff-c3c19581d497@oracle.com>
Message-ID: <617E7BB9-2E9E-4AE3-A199-E7DA39873279@oracle.com>
> On Apr 9, 2018, at 4:05 PM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
> On 2018-04-06 01:38, Kim Barrett wrote:
>>>
>> I see. The naming congurence, along with my having glazed over the
>> fact that oop_store_at is protected rather than public, led me astray.
>> I don't have any better suggestions for naming. I would have found
>> some comments describing the protocols helpful.
>
> I added some comments describing the idea behind ModRef.
>
>> Shouldn't ModRef::oop_store_at be pure virtual? That would have
>> helped my understanding too.
>
> Sure. Fixed.
That?s what I was looking for. Thanks.
From kim.barrett at oracle.com Mon Apr 9 20:47:42 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 9 Apr 2018 16:47:42 -0400
Subject: RFR: 8200550: Xcode 9.3 produce warning on heapRegionSet.hpp
In-Reply-To: <915e05b8-c6c0-f5f0-f46a-eac6eb6e3678@oracle.com>
References: <0734D26B-5E3D-45A1-8321-23896819851A@oracle.com>
<1523098983.2294.7.camel@oracle.com>
<F5144B4C-CC79-44DE-8FA4-9D96B69C86B2@oracle.com>
<1523136263.2260.39.camel@oracle.com>
<1D3A3B61-7BC0-4A6E-B084-F2AAF464CEBE@oracle.com>
<915e05b8-c6c0-f5f0-f46a-eac6eb6e3678@oracle.com>
Message-ID: <BECE3459-7EA9-433A-8B65-30E94D783D3B@oracle.com>
> On Apr 9, 2018, at 3:01 AM, David Holmes <david.holmes at oracle.com> wrote:
>
> Hi Kim,
>
> The now GC changes look fine (as did the original GC change). I'll leave the revised GC change to the GC folk.
Thanks.
(I assume you meant s/now GC/non-GC/.)
> Thanks,
> David
From kim.barrett at oracle.com Mon Apr 9 20:48:40 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 9 Apr 2018 16:48:40 -0400
Subject: RFR: 8200550: Xcode 9.3 produce warning on heapRegionSet.hpp
In-Reply-To: <1523257536.4326.2.camel@oracle.com>
References: <0734D26B-5E3D-45A1-8321-23896819851A@oracle.com>
<1523098983.2294.7.camel@oracle.com>
<F5144B4C-CC79-44DE-8FA4-9D96B69C86B2@oracle.com>
<1523136263.2260.39.camel@oracle.com>
<1D3A3B61-7BC0-4A6E-B084-F2AAF464CEBE@oracle.com>
<1523257536.4326.2.camel@oracle.com>
Message-ID: <FF7856FE-D38D-40E8-B9BA-2F27C638534E@oracle.com>
> On Apr 9, 2018, at 3:05 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> I agree that we may probably just remove optimized builds for the above
> stated reasons, but that is another discussion :)
Perhaps, and yes, that?s another discussion.
>>> So yes, I recommend removing this capability in this instance. This
>>> verification does not seem to be any different than any other.
>>>
>>> Not sure if this capability is too expensive or not (this is
>>> typically a bit fuzzy), but in the worst case one can use
>>> NOT_DEBUG_RETURN.
>>
>> Since it was previously only under ASSERT, I'm leaving it that way.
>>
>> New webrevs:
>> full: http://cr.openjdk.java.net/~kbarrett/8200550/open.01/
>> incr: http://cr.openjdk.java.net/~kbarrett/8200550/open.01.inc/
>
> looks good.
Thanks.
> Thanks,
> Thomas
From david.holmes at oracle.com Mon Apr 9 21:05:39 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Apr 2018 07:05:39 +1000
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
Message-ID: <2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
On 10/04/2018 2:33 AM, John Paul Adrian Glaubitz wrote:
> On 04/09/2018 05:03 PM, Thomas St?fe wrote:
>> VM_Version::determine_features()?needs a code blob, and hence ResourceMark, on sparc and ppc and s390 I think.
>>
>> But I think the reason that only sparc fails is that VM_Version::determine_features() is called too early on Sparc (as part of os::init_before_ergo()). The
>> other platforms call that function later in initialization (VM_Version_init() -> init_globals()). Could that be the error, and if yes, could
>> VM_Version::determine_features()??be delayed?
>
> I just did that but it doesn't really change anything for me.
>
> The main problem is still the assertion failure which I don't really understand
> is supposed to tell me.
>
> Would be nice if any of the SPARC experts could comment on this:
>
> # To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc: SuppressErrorAt=/assembler_sparc.cpp:52
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (/srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.cpp:52), pid=18610, tid=18620
> # assert(!(is_cti(prev) && is_cti(insn))) failed: CTI-CTI not allowed.
> #
> # JRE version: OpenJDK Runtime Environment (11.0) (fastdebug build 11-internal+0-adhoc.glaubitz.hs)
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 11-internal+0-adhoc.glaubitz.hs, mixed mode, tiered, compressed oops, serial gc, linux-sparc)
> # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /srv/openjdk/hs/make/hs_err_pid18610.log
> #
> # Compiler replay data is saved as:
> # /srv/openjdk/hs/make/replay_pid18610.log
> #
> # If you would like to submit a bug report, please visit:
> # http://bugreport.java.com/bugreport/crash.jsp
> #
> Current thread is 18620
>
Can you provide the stacktrace for the above please.
David
From glaubitz at physik.fu-berlin.de Mon Apr 9 21:10:28 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 9 Apr 2018 23:10:28 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
Message-ID: <1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
On 04/09/2018 11:05 PM, David Holmes wrote:
> Can you provide the stacktrace for the above please.
Here's what I got:
(gdb) bt
#0 0xffff8001080d7f68 in ?? ()
#1 0xffff800101c88a34 in SafeFetch32 (errValue=2748, adr=0xabc0000000000abc) at /srv/openjdk/hs/src/hotspot/share/runtime/stubRoutines.hpp:460
#2 test_safefetch32 () at /srv/openjdk/hs/src/hotspot/share/runtime/stubRoutines.cpp:244
#3 StubRoutines::initialize2 () at /srv/openjdk/hs/src/hotspot/share/runtime/stubRoutines.cpp:365
#4 0xffff800101c89624 in stubRoutines_init2 () at /srv/openjdk/hs/src/hotspot/share/runtime/stubRoutines.cpp:374
#5 0xffff80010141413c in init_globals () at /srv/openjdk/hs/src/hotspot/share/runtime/init.cpp:154
#6 0xffff800101d3f720 in Threads::create_vm (args=args at entry=0xffff8001025d4d78, canTryAgain=canTryAgain at entry=0xffff8001025d4c57)
at /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:3735
#7 0xffff800101503a98 in JNI_CreateJavaVM_inner (args=0xffff8001025d4d78, penv=0xffff8001025d4d70, vm=0xffff8001025d4d68) at
/srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:3929
#8 JNI_CreateJavaVM (vm=0xffff8001025d4d68, penv=0xffff8001025d4d70, args=0xffff8001025d4d78) at /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:4024
#9 0xffff800100367f10 in InitializeJVM (ifn=<synthetic pointer>, penv=0xffff8001025d4d70, pvm=0xffff8001025d4d68) at
/srv/openjdk/hs/src/java.base/share/native/libjli/java.c:1479
#10 JavaMain (_args=<optimized out>) at /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:412
#11 0xffff80010024b874 in start_thread (arg=0xffff8001025d5910) at pthread_create.c:463
#12 0xffff800100667140 in __thread_start () at ../sysdeps/unix/sysv/linux/sparc/sparc64/clone.S:78
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From david.holmes at oracle.com Mon Apr 9 21:11:38 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Apr 2018 07:11:38 +1000
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
Message-ID: <af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
On 10/04/2018 7:10 AM, John Paul Adrian Glaubitz wrote:
> On 04/09/2018 11:05 PM, David Holmes wrote:
>> Can you provide the stacktrace for the above please.
>
> Here's what I got:
>
> (gdb) bt
> #0 0xffff8001080d7f68 in ?? ()
> #1 0xffff800101c88a34 in SafeFetch32 (errValue=2748, adr=0xabc0000000000abc) at /srv/openjdk/hs/src/hotspot/share/runtime/stubRoutines.hpp:460
This isn't the assertion failure stack.
David
> #2 test_safefetch32 () at /srv/openjdk/hs/src/hotspot/share/runtime/stubRoutines.cpp:244
> #3 StubRoutines::initialize2 () at /srv/openjdk/hs/src/hotspot/share/runtime/stubRoutines.cpp:365
> #4 0xffff800101c89624 in stubRoutines_init2 () at /srv/openjdk/hs/src/hotspot/share/runtime/stubRoutines.cpp:374
> #5 0xffff80010141413c in init_globals () at /srv/openjdk/hs/src/hotspot/share/runtime/init.cpp:154
> #6 0xffff800101d3f720 in Threads::create_vm (args=args at entry=0xffff8001025d4d78, canTryAgain=canTryAgain at entry=0xffff8001025d4c57)
> at /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:3735
> #7 0xffff800101503a98 in JNI_CreateJavaVM_inner (args=0xffff8001025d4d78, penv=0xffff8001025d4d70, vm=0xffff8001025d4d68) at
> /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:3929
> #8 JNI_CreateJavaVM (vm=0xffff8001025d4d68, penv=0xffff8001025d4d70, args=0xffff8001025d4d78) at /srv/openjdk/hs/src/hotspot/share/prims/jni.cpp:4024
> #9 0xffff800100367f10 in InitializeJVM (ifn=<synthetic pointer>, penv=0xffff8001025d4d70, pvm=0xffff8001025d4d68) at
> /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:1479
> #10 JavaMain (_args=<optimized out>) at /srv/openjdk/hs/src/java.base/share/native/libjli/java.c:412
> #11 0xffff80010024b874 in start_thread (arg=0xffff8001025d5910) at pthread_create.c:463
> #12 0xffff800100667140 in __thread_start () at ../sysdeps/unix/sysv/linux/sparc/sparc64/clone.S:78
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)
>
> Adrian
>
From glaubitz at physik.fu-berlin.de Mon Apr 9 21:15:48 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 9 Apr 2018 23:15:48 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
Message-ID: <6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
On 04/09/2018 11:11 PM, David Holmes wrote:
>> (gdb) bt
>> #0? 0xffff8001080d7f68 in ?? ()
>> #1? 0xffff800101c88a34 in SafeFetch32 (errValue=2748, adr=0xabc0000000000abc) at /srv/openjdk/hs/src/hotspot/share/runtime/stubRoutines.hpp:460
>
> This isn't the assertion failure stack.
You're right. Somehow gdb tricked me.
I think this looks better:
(gdb) bt
#0 0xffff8001006afb9c in __libc_signal_restore_set (set=0xffff80012df915b8) at ../sysdeps/unix/sysv/linux/nptl-signals.h:80
#1 __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#2 0xffff8001006b1144 in __GI_abort () at abort.c:79
#3 0xffff800101af17ac in os::abort (dump_core=<optimized out>, siginfo=0x0, context=0x0) at /srv/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:1423
#4 0xffff800101f0d45c in VMError::report_and_die (id=id at entry=-536870912, message=message at entry=0xffff800101fef9a0 "assert(!(is_cti(prev) && is_cti(insn)))
failed",
detail_fmt=detail_fmt at entry=0xffff800101fef988 "CTI-CTI not allowed.", detail_args=detail_args at entry=0xffff80012df91d10,
thread=thread at entry=0xffff8001042cf000,
pc=pc at entry=0x0, siginfo=0x0, context=0x0, filename=0xffff800101fef948 "/srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.cpp", lineno=52, size=0)
at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1504
#5 0xffff800101f0e298 in VMError::report_and_die (thread=0xffff8001042cf000, context=context at entry=0x0,
filename=filename at entry=0xffff800101fef948 "/srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.cpp", lineno=lineno at entry=52,
message=message at entry=0xffff800101fef9a0 "assert(!(is_cti(prev) && is_cti(insn))) failed", detail_fmt=detail_fmt at entry=0xffff800101fef988 "CTI-CTI not
allowed.",
detail_args=<optimized out>) at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1244
#6 0xffff80010117cdec in report_vm_error (file=0xffff800101fef948 "/srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.cpp", line=line at entry=52,
error_msg=0xffff800101fef9a0 "assert(!(is_cti(prev) && is_cti(insn))) failed", detail_fmt=0xffff800101fef988 "CTI-CTI not allowed.")
at /srv/openjdk/hs/src/hotspot/share/utilities/debug.cpp:230
#7 0xffff800100c92e70 in Assembler::validate_no_pipeline_hazards (this=this at entry=0xffff800180029510) at
/srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.cpp:52
#8 0xffff800100d220ec in Assembler::flush (this=0xffff800180029510) at /srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.hpp:786
#9 Compilation::emit_code_epilog (assembler=0xffff80012df91df8, this=0xffff80012df92310) at /srv/openjdk/hs/src/hotspot/share/c1/c1_Compilation.cpp:319
#10 Compilation::emit_code_body (this=this at entry=0xffff80012df92310) at /srv/openjdk/hs/src/hotspot/share/c1/c1_Compilation.cpp:355
#11 0xffff800100d228e0 in Compilation::compile_java_method (this=this at entry=0xffff80012df92310) at /srv/openjdk/hs/src/hotspot/share/c1/c1_Compilation.cpp:404
#12 0xffff800100d23960 in Compilation::compile_method (this=this at entry=0xffff80012df92310) at /srv/openjdk/hs/src/hotspot/share/c1/c1_Compilation.cpp:460
#13 0xffff800100d24754 in Compilation::Compilation (this=0xffff80012df92310, compiler=<optimized out>, env=<optimized out>, method=0xffff800180010ee0,
osr_bci=<optimized out>, buffer_blob=<optimized out>, directive=0xffff8001041f7980) at /srv/openjdk/hs/src/hotspot/share/c1/c1_Compilation.cpp:584
#14 0xffff800100d2717c in Compiler::compile_method (this=0xffff80010429f8a0, env=0xffff80012df92828, method=0xffff800180010ee0, entry_bci=<optimized out>,
directive=<optimized out>) at /srv/openjdk/hs/src/hotspot/share/c1/c1_Compiler.cpp:249
#15 0xffff8001010da944 in CompileBroker::invoke_compiler_on_method (task=task at entry=0xffff8001042c9650)
at /srv/openjdk/hs/src/hotspot/share/compiler/compileBroker.cpp:1915
#16 0xffff8001010dcf14 in CompileBroker::compiler_thread_loop () at /srv/openjdk/hs/src/hotspot/share/compiler/compileBroker.cpp:1620
#17 0xffff800101e3d21c in JavaThread::thread_main_inner (this=this at entry=0xffff8001042cf000) at /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:1797
#18 0xffff800101e3d810 in JavaThread::run (this=0xffff8001042cf000) at /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:1777
#19 0xffff800101afb5c8 in thread_native_entry (thread=0xffff8001042cf000) at /srv/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:710
#20 0xffff800100347874 in start_thread (arg=0xffff80012df93910) at pthread_create.c:463
#21 0xffff800100763140 in __thread_start () at ../sysdeps/unix/sysv/linux/sparc/sparc64/clone.S:78
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From david.holmes at oracle.com Mon Apr 9 21:31:50 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Apr 2018 07:31:50 +1000
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
<6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
Message-ID: <7f4d51d2-be2f-0984-946b-efa557a7ecc8@oracle.com>
On 10/04/2018 7:15 AM, John Paul Adrian Glaubitz wrote:
> On 04/09/2018 11:11 PM, David Holmes wrote:
>>> (gdb) bt
>>> #0? 0xffff8001080d7f68 in ?? ()
>>> #1? 0xffff800101c88a34 in SafeFetch32 (errValue=2748, adr=0xabc0000000000abc) at /srv/openjdk/hs/src/hotspot/share/runtime/stubRoutines.hpp:460
>>
>> This isn't the assertion failure stack.
>
> You're right. Somehow gdb tricked me.
>
> I think this looks better:
Looks like you will need compiler folk to jump in here. No idea why this
would be linux-sparc specific, but would need to see exactly what was
being compiled at the time the invalid code sequence was encountered.
Sorry. This is what happens when code is no longer actively maintained.
David
------
> (gdb) bt
> #0 0xffff8001006afb9c in __libc_signal_restore_set (set=0xffff80012df915b8) at ../sysdeps/unix/sysv/linux/nptl-signals.h:80
> #1 __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:48
> #2 0xffff8001006b1144 in __GI_abort () at abort.c:79
> #3 0xffff800101af17ac in os::abort (dump_core=<optimized out>, siginfo=0x0, context=0x0) at /srv/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:1423
> #4 0xffff800101f0d45c in VMError::report_and_die (id=id at entry=-536870912, message=message at entry=0xffff800101fef9a0 "assert(!(is_cti(prev) && is_cti(insn)))
> failed",
> detail_fmt=detail_fmt at entry=0xffff800101fef988 "CTI-CTI not allowed.", detail_args=detail_args at entry=0xffff80012df91d10,
> thread=thread at entry=0xffff8001042cf000,
> pc=pc at entry=0x0, siginfo=0x0, context=0x0, filename=0xffff800101fef948 "/srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.cpp", lineno=52, size=0)
> at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1504
> #5 0xffff800101f0e298 in VMError::report_and_die (thread=0xffff8001042cf000, context=context at entry=0x0,
> filename=filename at entry=0xffff800101fef948 "/srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.cpp", lineno=lineno at entry=52,
> message=message at entry=0xffff800101fef9a0 "assert(!(is_cti(prev) && is_cti(insn))) failed", detail_fmt=detail_fmt at entry=0xffff800101fef988 "CTI-CTI not
> allowed.",
> detail_args=<optimized out>) at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1244
> #6 0xffff80010117cdec in report_vm_error (file=0xffff800101fef948 "/srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.cpp", line=line at entry=52,
> error_msg=0xffff800101fef9a0 "assert(!(is_cti(prev) && is_cti(insn))) failed", detail_fmt=0xffff800101fef988 "CTI-CTI not allowed.")
> at /srv/openjdk/hs/src/hotspot/share/utilities/debug.cpp:230
> #7 0xffff800100c92e70 in Assembler::validate_no_pipeline_hazards (this=this at entry=0xffff800180029510) at
> /srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.cpp:52
> #8 0xffff800100d220ec in Assembler::flush (this=0xffff800180029510) at /srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.hpp:786
> #9 Compilation::emit_code_epilog (assembler=0xffff80012df91df8, this=0xffff80012df92310) at /srv/openjdk/hs/src/hotspot/share/c1/c1_Compilation.cpp:319
> #10 Compilation::emit_code_body (this=this at entry=0xffff80012df92310) at /srv/openjdk/hs/src/hotspot/share/c1/c1_Compilation.cpp:355
> #11 0xffff800100d228e0 in Compilation::compile_java_method (this=this at entry=0xffff80012df92310) at /srv/openjdk/hs/src/hotspot/share/c1/c1_Compilation.cpp:404
> #12 0xffff800100d23960 in Compilation::compile_method (this=this at entry=0xffff80012df92310) at /srv/openjdk/hs/src/hotspot/share/c1/c1_Compilation.cpp:460
> #13 0xffff800100d24754 in Compilation::Compilation (this=0xffff80012df92310, compiler=<optimized out>, env=<optimized out>, method=0xffff800180010ee0,
> osr_bci=<optimized out>, buffer_blob=<optimized out>, directive=0xffff8001041f7980) at /srv/openjdk/hs/src/hotspot/share/c1/c1_Compilation.cpp:584
> #14 0xffff800100d2717c in Compiler::compile_method (this=0xffff80010429f8a0, env=0xffff80012df92828, method=0xffff800180010ee0, entry_bci=<optimized out>,
> directive=<optimized out>) at /srv/openjdk/hs/src/hotspot/share/c1/c1_Compiler.cpp:249
> #15 0xffff8001010da944 in CompileBroker::invoke_compiler_on_method (task=task at entry=0xffff8001042c9650)
> at /srv/openjdk/hs/src/hotspot/share/compiler/compileBroker.cpp:1915
> #16 0xffff8001010dcf14 in CompileBroker::compiler_thread_loop () at /srv/openjdk/hs/src/hotspot/share/compiler/compileBroker.cpp:1620
> #17 0xffff800101e3d21c in JavaThread::thread_main_inner (this=this at entry=0xffff8001042cf000) at /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:1797
> #18 0xffff800101e3d810 in JavaThread::run (this=0xffff8001042cf000) at /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:1777
> #19 0xffff800101afb5c8 in thread_native_entry (thread=0xffff8001042cf000) at /srv/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:710
> #20 0xffff800100347874 in start_thread (arg=0xffff80012df93910) at pthread_create.c:463
> #21 0xffff800100763140 in __thread_start () at ../sysdeps/unix/sysv/linux/sparc/sparc64/clone.S:78
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)
>
From david.holmes at oracle.com Mon Apr 9 21:47:30 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Apr 2018 07:47:30 +1000
Subject: RFR (XL) 8081519 Split globals.hpp to factor out the Flag class
In-Reply-To: <8009E1D8-0493-48FC-97C3-3BBDFE76A13F@oracle.com>
References: <D6E4A4E8-8356-4694-BD9C-03AB5FA5BC65@oracle.com>
<6656E162-56BE-4E75-8343-7567715F30C7@oracle.com>
<8009E1D8-0493-48FC-97C3-3BBDFE76A13F@oracle.com>
Message-ID: <65af12b9-c14d-bb07-ba70-f8ec1eb4ad1c@oracle.com>
Hi Gerard,
I had another scan through this and it seems okay.
Thanks,
David
On 10/04/2018 4:35 AM, Gerard Ziemski wrote:
> Hi all,
>
> Here is http://cr.openjdk.java.net/~gziemski/8081519_rev3 with the addition requested by Coleen to include jvmFlag.hpp directly anywhere jvmFlag is used.
>
> Tested locally with open/closed, debug/product, precompiled header/no precompiled header build variations.
>
>
> cheers
>
>> On Apr 5, 2018, at 12:46 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
>>
>> Hi all,
>>
>> Here is webrev 2 with the following additions:
>>
>> #1 Factor FlagSetting class out of "runtime/flags/jvmFlag.hpp" and into its own "runtime/flags/flagSetting.hpp", so that FlagSetting class can extend from ?public StackObj? (thanks Coleen)
>>
>> #2 change the hierarchy from ?runtime/jvmFlag/? to "runtime/flags/? (thanks David)
>>
>> #3 Fix the header files, so that both closed and open repository build with and without precompiled headers
>>
>> #4 Add ?runtime/flags/*.hpp? headers to ?precompiled.hpp?
>>
>> The number of touched files got even longer - sorry about that and big thank you for taking your time to review!
>>
>> Running final Mach5 hs_tier1-5 tests? (it passed earlier iterations). Passes local builds (on Mac OS X) with and without precompiled headers for both closed and open repos and both debug and product versions (should I try any other build varations?)
>>
>> http://cr.openjdk.java.net/~gziemski/8081519_rev2
>>
>>
>> cheers
>>
>>> On Mar 29, 2018, at 2:01 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
>>>
>>> Hi all,
>>>
>>> Please review this large and tedious (sorry), but simple fix that accomplishes the following:
>>>
>>> #1 factor out the command option flag related APIs out of globals.hpp/.cpp into its own dedicated files, i.e. jvmFlag.hpp/.cpp
>>> #2 merge Flag (too generic name) and CommandLineFlag classes and rename them as JVMFlag
>>> #3 cleanup globals.hpp includes originally added by the JEP-245
>>>
>>> Note: the renamed file retain their history, but one needs to add ?follow? flag, ex. ?hg log -f file?
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8081519
>>> http://cr.openjdk.java.net/~gziemski/8081519_rev1
>>>
>>> Passes Mach5 hs_tier1-tier5, jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges tests.
>>>
>>>
>>> cheers
>>
>
From coleen.phillimore at oracle.com Mon Apr 9 22:21:47 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 9 Apr 2018 18:21:47 -0400
Subject: RFR (M) 8198313: Wrap holder object for ClassLoaderData in a
WeakHandle
In-Reply-To: <6A97EFE4-58F5-4916-B59B-7A0AB39F8817@oracle.com>
References: <3fe8b4c5-3e1d-d192-07ce-0828e3982e75@oracle.com>
<9C48FEF4-59DD-4415-AF18-B95ADBDFACB4@oracle.com>
<c62305c3-4567-d5c1-7aca-c5d47f885978@oracle.com>
<304110c1-f4e0-63c8-d94b-bc779b737411@oracle.com>
<4C4FB5D1-A0BA-4CC8-ADB7-8BED6BC2B88C@oracle.com>
<8372a910-f110-05df-85d0-e7c1859e4de4@oracle.com>
<5223d028-8eed-1835-d857-e2a277530f61@oracle.com>
<6A97EFE4-58F5-4916-B59B-7A0AB39F8817@oracle.com>
Message-ID: <c367a0ba-417b-fc0b-4b68-85ea02243df5@oracle.com>
On 4/9/18 3:33 PM, Kim Barrett wrote:
>> On Apr 9, 2018, at 9:10 AM, coleen.phillimore at oracle.com wrote:
>>
>>
>> I had an extensive conversation offline with Stefan, Robbin and Kim and have reworked this change to walk the CLDG weak roots with the SystemDictionary. Also, I moved the WeakHandle holder creation into the ClassLoaderData constructor, and made WeakHandle a template class so that multiple weak roots are supported.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8198313.04/webrev
>>
>> This passes tier1-5 tests on linux-x64 and windows-x64. I've also done another performance test aka. dev-submit with no significant difference.
>>
>> The additional change to make _class_loader oop into an OopHandle or otherwise remove from ClassLoaderData will be done as a separate change because it breaks JFR.
> ------------------------------------------------------------------------------
> src/hotspot/share/oops/weakHandle.inline.hpp
>
> Do resolve and peek actually need a check for NULL? Could they assert
> non-null instead? I'm guessing that the places that need these
> operations should never get there with a not-initialized handle.
>
> Oh, but maybe this is needed for the null class loader? If so, ick!
Yes, it's needed for the ClassLoaderData for the null class loader, but
it was mostly left over from when the holder was initialized later.
I've added a case for the null class loader in
ClassLoaderData::holder_phantom() instead and taken out the null
conditions in resolve and peek.
>
> ------------------------------------------------------------------------------
> src/hotspot/share/oops/weakHandle.hpp
> 60 void clear() { _obj = NULL; } // for class loading race loss
>
> Is this really needed? Why not just call release?
>
> Especially since the one caller (CLD::update_holder) looks
> suspiciously like a leak of an OopStorage entry.
This code is wrong.? It should be *_obj = NULL.? I've also moved this to
be handled in WeakHandle::release().? Even though this loses the assert
that the released pointer is NULL in OopStorage.? It looks cleaner this
way.? I also added a comment.
>
> ------------------------------------------------------------------------------
> src/hotspot/share/classfile/classLoaderData.cpp
> 104 ClassLoaderData::ClassLoaderData(Handle h_class_loader, bool is_anonymous) :
>
> Re: Removal of _packages(NULL) from the initializer list, I would have
> instead initialized all the members in the initializer list, and then
> update them when appropriate. That would eliminate the else-clause
> starting at line 137, and (to me) make the state easier to follow.
If these fields are in the initializer list and then also initialized in
the constructor, aren't they initialized twice?? I guess even a stupid
optimizer could figure this out though.? I agree, I'll change this so
the anonymous case need not NULL out these fields.
>
> ------------------------------------------------------------------------------
> src/hotspot/share/classfile/classLoaderData.cpp
> 978 // need to clear the holder for this case.
> 979 cld->update_holder(Handle());
>
> If WeakHandle::release had
> RootAccess<ON_PHANTOM_OOP_REF>::oop_store(_obj, (oop)NULL);
> before calling OopStorage::release, then I think the above two lines
> aren't needed?
Yes.? Thanks for the Access call.
>
> ------------------------------------------------------------------------------
> src/hotspot/share/classfile/classLoaderData.cpp
> 1250 int loaders_processed = 0;
> 1251 int loaders_removed = 0;
>
> s/int/uint/
>
> And update the log message to use %u rather than %d.
Thanks, fixed.? Hope it doesn't get that large.
>
> ------------------------------------------------------------------------------
> src/hotspot/share/classfile/classLoaderData.hpp
> 224 oop _class_loader; // oop used to uniquely identify a class loader
> 225 // class loader or a canonical class path
>
> Lost earlier (some previous webrev in this series, I think) fix to the
> comment.
Should have been fixed in webrev.04 but I don't think I fixed the webrev
after I noticed this.? It'll be in the full webrev.
>
> ------------------------------------------------------------------------------
> src/hotspot/share/classfile/systemDictionary.cpp
> 1018 // Anonymous classes must update ClassLoaderData holder (was host_klass loader)
> 1019 // so that they can be unloaded when the mirror is no longer referenced.
> 1020 k->class_loader_data()->update_holder(Handle(THREAD, k->java_mirror()));
>
> The comment here suggests the holder has been set to something else
> and now we need to update it. But the CLD constructor only calls
> update_holder for non-anonymous classes. This suggests that if the
> call to update_holder mentioned above (to clear it) were eliminated,
> then update_holder could be once-only (with an assert) and should be
> called initialize_holder.
Yup. I renamed the function initialize_holder.
This is the incremental change:
http://cr.openjdk.java.net/~coleenp/8198313.incr.05/webrev/index.html
Full changes:
open webrev at http://cr.openjdk.java.net/~coleenp/8198313.05/webrev
Thanks,
Coleen
>
> ------------------------------------------------------------------------------
>
From kim.barrett at oracle.com Tue Apr 10 00:39:31 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 9 Apr 2018 20:39:31 -0400
Subject: RFR (M) 8198313: Wrap holder object for ClassLoaderData in a
WeakHandle
In-Reply-To: <c367a0ba-417b-fc0b-4b68-85ea02243df5@oracle.com>
References: <3fe8b4c5-3e1d-d192-07ce-0828e3982e75@oracle.com>
<9C48FEF4-59DD-4415-AF18-B95ADBDFACB4@oracle.com>
<c62305c3-4567-d5c1-7aca-c5d47f885978@oracle.com>
<304110c1-f4e0-63c8-d94b-bc779b737411@oracle.com>
<4C4FB5D1-A0BA-4CC8-ADB7-8BED6BC2B88C@oracle.com>
<8372a910-f110-05df-85d0-e7c1859e4de4@oracle.com>
<5223d028-8eed-1835-d857-e2a277530f61@oracle.com>
<6A97EFE4-58F5-4916-B59B-7A0AB39F8817@oracle.com>
<c367a0ba-417b-fc0b-4b68-85ea02243df5@oracle.com>
Message-ID: <976145A0-081B-4101-B3FE-E00D9D137763@oracle.com>
> On Apr 9, 2018, at 6:21 PM, coleen.phillimore at oracle.com wrote:
> This is the incremental change:
>
> http://cr.openjdk.java.net/~coleenp/8198313.incr.05/webrev/index.html
>
> Full changes:
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8198313.05/webrev
>
> Thanks,
> Coleen
>>
>> ------------------------------------------------------------------------------
Looks good.
From david.holmes at oracle.com Tue Apr 10 00:54:40 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Apr 2018 10:54:40 +1000
Subject: RFR: 8200550: Xcode 9.3 produce warning on heapRegionSet.hpp
In-Reply-To: <BECE3459-7EA9-433A-8B65-30E94D783D3B@oracle.com>
References: <0734D26B-5E3D-45A1-8321-23896819851A@oracle.com>
<1523098983.2294.7.camel@oracle.com>
<F5144B4C-CC79-44DE-8FA4-9D96B69C86B2@oracle.com>
<1523136263.2260.39.camel@oracle.com>
<1D3A3B61-7BC0-4A6E-B084-F2AAF464CEBE@oracle.com>
<915e05b8-c6c0-f5f0-f46a-eac6eb6e3678@oracle.com>
<BECE3459-7EA9-433A-8B65-30E94D783D3B@oracle.com>
Message-ID: <0617031a-c128-5284-defa-5be6074c9ac3@oracle.com>
On 10/04/2018 6:47 AM, Kim Barrett wrote:
>> On Apr 9, 2018, at 3:01 AM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Kim,
>>
>> The now GC changes look fine (as did the original GC change). I'll leave the revised GC change to the GC folk.
>
> Thanks.
>
> (I assume you meant s/now GC/non-GC/.)
yep - sorry
David
>> Thanks,
>> David
>
From kim.barrett at oracle.com Tue Apr 10 01:15:25 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 9 Apr 2018 21:15:25 -0400
Subject: RFR (M) 8198313: Wrap holder object for ClassLoaderData in a
WeakHandle
In-Reply-To: <976145A0-081B-4101-B3FE-E00D9D137763@oracle.com>
References: <3fe8b4c5-3e1d-d192-07ce-0828e3982e75@oracle.com>
<9C48FEF4-59DD-4415-AF18-B95ADBDFACB4@oracle.com>
<c62305c3-4567-d5c1-7aca-c5d47f885978@oracle.com>
<304110c1-f4e0-63c8-d94b-bc779b737411@oracle.com>
<4C4FB5D1-A0BA-4CC8-ADB7-8BED6BC2B88C@oracle.com>
<8372a910-f110-05df-85d0-e7c1859e4de4@oracle.com>
<5223d028-8eed-1835-d857-e2a277530f61@oracle.com>
<6A97EFE4-58F5-4916-B59B-7A0AB39F8817@oracle.com>
<c367a0ba-417b-fc0b-4b68-85ea02243df5@oracle.com>
<976145A0-081B-4101-B3FE-E00D9D137763@oracle.com>
Message-ID: <9BD26D9A-E2EC-4E08-B977-9F7EB697D31C@oracle.com>
> On Apr 9, 2018, at 8:39 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>
>> On Apr 9, 2018, at 6:21 PM, coleen.phillimore at oracle.com wrote:
>> This is the incremental change:
>>
>> http://cr.openjdk.java.net/~coleenp/8198313.incr.05/webrev/index.html
>>
>> Full changes:
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8198313.05/webrev
>>
>> Thanks,
>> Coleen
>>>
>>> ------------------------------------------------------------------------------
>
> Looks good.
I forgot to mention, in WeakHandle resolve and peek, consider asserting !is_null().
From david.holmes at oracle.com Tue Apr 10 01:16:32 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Apr 2018 11:16:32 +1000
Subject: Supported platforms
In-Reply-To: <CAJwKKmbdaARqETcDXB88YnO6d=_Tuba4BAkDYb2uM5n=8a-FOg@mail.gmail.com>
References: <209e831bd10929184afdbedb7e811652@juanantonio.info>
<15333dda-c4f6-8514-6b32-9a7d76df405c@oracle.com>
<5feb9980b20e82d036c06f74f7d89ed9@juanantonio.info>
<5ACA276C.7030505@cjnash.com>
<4b1f262d-b9d2-6844-e453-dd53b42b2d74@oracle.com> <5ACB90F6.50607@cjnash.com>
<CAJwKKmbdaARqETcDXB88YnO6d=_Tuba4BAkDYb2uM5n=8a-FOg@mail.gmail.com>
Message-ID: <d31809bb-e3de-c3c9-4ffd-39c5a8faa21a@oracle.com>
On 10/04/2018 2:40 AM, Mario Torre wrote:
> On Mon, Apr 9, 2018 at 6:12 PM, Simon Nash <simon at cjnash.com> wrote:
>
>> Thanks for this. I think I should clarify what I mean by a supported
>> platform. This would be a platform for which bugs affecting the ability
>> to build a working OpenJDK binary for that platform would be considered
>> valid by the OpenJDK community and a user-submitted patch to fix such a
>> bug would be considered for integration into the OpenJDK codebase.
>
> Being a Community project, I would say everything that is relevant for
> users is relevant for the project.
>
> Now, "everything" doesn't mean "absolutely" everything of course ;)
> but within reasonable limits "almost" everything is a good bet. If you
> plan in adding support for new architectures you will have better luck
> with a Porting sponsored projects, if you want to fix some bugs in
> some weird architecture that is already existing, or help building
> with some Linux distribution not currently covered for some reason,
> I'm sure that will be accepted quickly too, in all cases some
> discussion would be good to have before start proposing patches.
We are in a situation where previously "supported" platforms (by Oracle)
are no longer supported as, AFAIK, no one has stepped up to take
ownership of said platforms - which is a requirement for getting a new
port accepted into mainline. Without such ownership the code may not
only bit-rot, it may in time be stripped out completely. Any interested
parties would then need to look at (re)forming a port project for that
platform to keep it going in OpenJDK (or of course they are free to take
it elsewhere).
Cheers,
David
> But again, this is a case-by-case thing, so probably you can just tell
> us what you are interested in contributing and see if there are
> objections or other reasons not to have that code in.
>
> Cheers,
> Mario
>
From coleen.phillimore at oracle.com Tue Apr 10 01:28:27 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 9 Apr 2018 21:28:27 -0400
Subject: RFR (XL) 8081519 Split globals.hpp to factor out the Flag class
In-Reply-To: <8009E1D8-0493-48FC-97C3-3BBDFE76A13F@oracle.com>
References: <D6E4A4E8-8356-4694-BD9C-03AB5FA5BC65@oracle.com>
<6656E162-56BE-4E75-8343-7567715F30C7@oracle.com>
<8009E1D8-0493-48FC-97C3-3BBDFE76A13F@oracle.com>
Message-ID: <f0f8f4d6-f23a-792d-af7d-874d197647d1@oracle.com>
Looks good!? Nice refactoring!
Coleen
On 4/9/18 2:35 PM, Gerard Ziemski wrote:
> Hi all,
>
> Here is http://cr.openjdk.java.net/~gziemski/8081519_rev3 with the addition requested by Coleen to include jvmFlag.hpp directly anywhere jvmFlag is used.
>
> Tested locally with open/closed, debug/product, precompiled header/no precompiled header build variations.
>
>
> cheers
>
>> On Apr 5, 2018, at 12:46 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
>>
>> Hi all,
>>
>> Here is webrev 2 with the following additions:
>>
>> #1 Factor FlagSetting class out of "runtime/flags/jvmFlag.hpp" and into its own "runtime/flags/flagSetting.hpp", so that FlagSetting class can extend from ?public StackObj? (thanks Coleen)
>>
>> #2 change the hierarchy from ?runtime/jvmFlag/? to "runtime/flags/? (thanks David)
>>
>> #3 Fix the header files, so that both closed and open repository build with and without precompiled headers
>>
>> #4 Add ?runtime/flags/*.hpp? headers to ?precompiled.hpp?
>>
>> The number of touched files got even longer - sorry about that and big thank you for taking your time to review!
>>
>> Running final Mach5 hs_tier1-5 tests? (it passed earlier iterations). Passes local builds (on Mac OS X) with and without precompiled headers for both closed and open repos and both debug and product versions (should I try any other build varations?)
>>
>> http://cr.openjdk.java.net/~gziemski/8081519_rev2
>>
>>
>> cheers
>>
>>> On Mar 29, 2018, at 2:01 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
>>>
>>> Hi all,
>>>
>>> Please review this large and tedious (sorry), but simple fix that accomplishes the following:
>>>
>>> #1 factor out the command option flag related APIs out of globals.hpp/.cpp into its own dedicated files, i.e. jvmFlag.hpp/.cpp
>>> #2 merge Flag (too generic name) and CommandLineFlag classes and rename them as JVMFlag
>>> #3 cleanup globals.hpp includes originally added by the JEP-245
>>>
>>> Note: the renamed file retain their history, but one needs to add ?follow? flag, ex. ?hg log -f file?
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8081519
>>> http://cr.openjdk.java.net/~gziemski/8081519_rev1
>>>
>>> Passes Mach5 hs_tier1-tier5, jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges tests.
>>>
>>>
>>> cheers
From stefan.karlsson at oracle.com Tue Apr 10 08:06:27 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 10 Apr 2018 10:06:27 +0200
Subject: RFR: 8201168: Move GC command line constraint functions to GC
specific files
In-Reply-To: <1964E10D-BA6B-4B2B-82CC-0F3E51AB5A71@oracle.com>
References: <99b6d120-44bf-b243-7fa1-5a5cb9c44b8b@oracle.com>
<1964E10D-BA6B-4B2B-82CC-0F3E51AB5A71@oracle.com>
Message-ID: <9124d77f-929d-917f-83cc-fd917ea7f766@oracle.com>
Hi Gerard,
On 2018-04-09 18:53, Gerard Ziemski wrote:
> hi Stefan,
>
> Nice cleanup, looks good.
>
> Shouldn?t the new files have just ?2018," as the copyright year, not "2015, 2018,"?
Since I copied the code from files with copyright years 2015, 2018 I
transfered those years over to the new files.
>
> Also, what tests did you run?
I've been running hs-tier1 and hs-tier2. I'll run hs-tier3 to ensure
that the TestOptionsWithRanges test is run.
>
> ps. Don?t worry about my changes, I will wait for yours to go in, then I?ll merge.
OK. Thanks!
StefanK
>
>
> cheers
>
>> On Apr 5, 2018, at 5:03 AM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
>>
>> Hi all,
>>
>> Please review this patch to move the GC flag constraint functions into GC specific files.
>>
>> http://cr.openjdk.java.net/~stefank/8201168/webrev.01
>> https://bugs.openjdk.java.net/browse/JDK-8201168
>>
>> This is one step towards:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8200729 - Conditional compilation of GCs
>>
>> I know that this conflicts with Gerards rename of the flags to JVMFlags, but I don't want to wait for that to get pushed before publishing this review request.
>>
>> Thanks,
>> StefanK
>
From shade at redhat.com Tue Apr 10 09:35:03 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 10 Apr 2018 11:35:03 +0200
Subject: RFR (XS) 8201359: Incorrect header guards after JDK-8198949
(Modularize arraycopy stub routine GC barriers)
Message-ID: <18ae2482-f7a6-75f8-47d4-b439ac8741ff@redhat.com>
Spotted this when pulling upstream changes to Epsilon sandbox branch.
Trivial RFE:
https://bugs.openjdk.java.net/browse/JDK-8201359
Fix:
http://cr.openjdk.java.net/~shade/8201359/webrev.01/
Testing: x86_64 build
Thanks,
-Aleksey
From stefan.karlsson at oracle.com Tue Apr 10 10:02:45 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 10 Apr 2018 12:02:45 +0200
Subject: RFR (XS) 8201359: Incorrect header guards after JDK-8198949
(Modularize arraycopy stub routine GC barriers)
In-Reply-To: <18ae2482-f7a6-75f8-47d4-b439ac8741ff@redhat.com>
References: <18ae2482-f7a6-75f8-47d4-b439ac8741ff@redhat.com>
Message-ID: <135e91d6-35d1-bfec-888e-f5c80a599839@oracle.com>
Looks good.
StefanK
On 2018-04-10 11:35, Aleksey Shipilev wrote:
> Spotted this when pulling upstream changes to Epsilon sandbox branch.
>
> Trivial RFE:
> https://bugs.openjdk.java.net/browse/JDK-8201359
>
> Fix:
> http://cr.openjdk.java.net/~shade/8201359/webrev.01/
>
> Testing: x86_64 build
>
> Thanks,
> -Aleksey
>
From david.holmes at oracle.com Tue Apr 10 10:04:05 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Apr 2018 20:04:05 +1000
Subject: RFR (XS) 8201359: Incorrect header guards after JDK-8198949
(Modularize arraycopy stub routine GC barriers)
In-Reply-To: <18ae2482-f7a6-75f8-47d4-b439ac8741ff@redhat.com>
References: <18ae2482-f7a6-75f8-47d4-b439ac8741ff@redhat.com>
Message-ID: <da285f73-86c9-927d-bdcd-a01cdc3d435c@oracle.com>
Looks fine to me. And trivial.
Thanks,
David
On 10/04/2018 7:35 PM, Aleksey Shipilev wrote:
> Spotted this when pulling upstream changes to Epsilon sandbox branch.
>
> Trivial RFE:
> https://bugs.openjdk.java.net/browse/JDK-8201359
>
> Fix:
> http://cr.openjdk.java.net/~shade/8201359/webrev.01/
>
> Testing: x86_64 build
>
> Thanks,
> -Aleksey
>
From shade at redhat.com Tue Apr 10 10:23:07 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 10 Apr 2018 12:23:07 +0200
Subject: RFR (XS) 8201359: Incorrect header guards after JDK-8198949
(Modularize arraycopy stub routine GC barriers)
In-Reply-To: <da285f73-86c9-927d-bdcd-a01cdc3d435c@oracle.com>
References: <18ae2482-f7a6-75f8-47d4-b439ac8741ff@redhat.com>
<da285f73-86c9-927d-bdcd-a01cdc3d435c@oracle.com>
Message-ID: <ed1fb113-9a51-4144-5345-2a632ea06a73@redhat.com>
Thanks guys, pushed.
-Aleksey
On 04/10/2018 12:04 PM, David Holmes wrote:
> Looks fine to me. And trivial.
>
> Thanks,
> David
>
> On 10/04/2018 7:35 PM, Aleksey Shipilev wrote:
>> Spotted this when pulling upstream changes to Epsilon sandbox branch.
>>
>> Trivial RFE:
>> ?? https://bugs.openjdk.java.net/browse/JDK-8201359
>>
>> Fix:
>> ?? http://cr.openjdk.java.net/~shade/8201359/webrev.01/
>>
>> Testing: x86_64 build
>>
>> Thanks,
>> -Aleksey
>>
From glaubitz at physik.fu-berlin.de Tue Apr 10 10:36:48 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 10 Apr 2018 12:36:48 +0200
Subject: Zero fails to build on SPARC again, similar to JDK-8186578
In-Reply-To: <09c3fb5b-ab74-f478-c72d-538c7f8faaa8@physik.fu-berlin.de>
References: <09c3fb5b-ab74-f478-c72d-538c7f8faaa8@physik.fu-berlin.de>
Message-ID: <2bacfb4d-b32f-4f9b-3f28-ec0067617986@physik.fu-berlin.de>
On 04/09/2018 01:38 PM, John Paul Adrian Glaubitz wrote:
> This is reminiscent of JDK-8186578 and I would have expected the change made there
> to be still working [2]. The relative path to memset_with_concurrent_readers_sparc.cpp
> is still correct though.
I have already tried adding it to make/hotspot/lib/CompileJvm.gmk and make/lib/CoreLibraries.gmk:
diff -r a47d1e21b3f1 make/hotspot/lib/CompileJvm.gmk
--- a/make/hotspot/lib/CompileJvm.gmk Thu Apr 05 10:54:53 2018 +0200
+++ b/make/hotspot/lib/CompileJvm.gmk Tue Apr 10 13:28:59 2018 +0300
@@ -174,6 +174,14 @@
JVM_EXCLUDE_PATTERNS += x86_32
endif
+ifeq ($(call check-jvm-feature, zero), true)
+ JVM_CFLAGS_FEATURES += -DZERO -DCC_INTERP -DZERO_LIBARCH='"$(OPENJDK_TARGET_CPU_LEGACY_LIB)"' $(LIBFFI_CFLAGS)
+ JVM_LIBS_FEATURES += $(LIBFFI_LIBS)
+ ifeq ($(OPENJDK_TARGET_CPU), sparcv9)
+ BUILD_LIBJVM_EXTRA_FILES := $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp
+ endif
+endif
+
# Inline assembly for solaris
ifeq ($(OPENJDK_TARGET_OS), solaris)
ifeq ($(OPENJDK_TARGET_CPU), x86_64)
diff -r a47d1e21b3f1 make/lib/CoreLibraries.gmk
--- a/make/lib/CoreLibraries.gmk Thu Apr 05 10:54:53 2018 +0200
+++ b/make/lib/CoreLibraries.gmk Tue Apr 10 13:28:59 2018 +0300
@@ -238,6 +238,9 @@
ifeq ($(call check-jvm-variant, zero), true)
ERGO_FAMILY := zero
+ ifeq ($(OPENJDK_TARGET_CPU), sparcv9)
+ BUILD_LIBJVM_EXTRA_FILES := $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp
+ endif
else
ifeq ($(OPENJDK_TARGET_CPU_ARCH), x86)
ERGO_FAMILY := i586
But that didn't help.
Any ideas?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From david.holmes at oracle.com Tue Apr 10 10:48:18 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Apr 2018 20:48:18 +1000
Subject: Zero fails to build on SPARC again, similar to JDK-8186578
In-Reply-To: <2bacfb4d-b32f-4f9b-3f28-ec0067617986@physik.fu-berlin.de>
References: <09c3fb5b-ab74-f478-c72d-538c7f8faaa8@physik.fu-berlin.de>
<2bacfb4d-b32f-4f9b-3f28-ec0067617986@physik.fu-berlin.de>
Message-ID: <94be4fc8-25dc-c54c-417b-dd69ee0b721f@oracle.com>
I'm guessing, as this relates to gtest, that you need to do something in
make/hotspot/lib/CompileGtest.gmk
David
On 10/04/2018 8:36 PM, John Paul Adrian Glaubitz wrote:
> On 04/09/2018 01:38 PM, John Paul Adrian Glaubitz wrote:
>> This is reminiscent of JDK-8186578 and I would have expected the
>> change made there
>> to be still working [2]. The relative path to
>> memset_with_concurrent_readers_sparc.cpp
>> is still correct though.
>
> I have already tried adding it to make/hotspot/lib/CompileJvm.gmk and
> make/lib/CoreLibraries.gmk:
>
> diff -r a47d1e21b3f1 make/hotspot/lib/CompileJvm.gmk
> --- a/make/hotspot/lib/CompileJvm.gmk?? Thu Apr 05 10:54:53 2018 +0200
> +++ b/make/hotspot/lib/CompileJvm.gmk?? Tue Apr 10 13:28:59 2018 +0300
> @@ -174,6 +174,14 @@
> ?? JVM_EXCLUDE_PATTERNS += x86_32
> ?endif
>
> +ifeq ($(call check-jvm-feature, zero), true)
> +? JVM_CFLAGS_FEATURES += -DZERO -DCC_INTERP
> -DZERO_LIBARCH='"$(OPENJDK_TARGET_CPU_LEGACY_LIB)"' $(LIBFFI_CFLAGS)
> +? JVM_LIBS_FEATURES += $(LIBFFI_LIBS)
> +? ifeq ($(OPENJDK_TARGET_CPU), sparcv9)
> +??? BUILD_LIBJVM_EXTRA_FILES :=
> $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp
> +? endif
> +endif
> +
> ?# Inline assembly for solaris
> ?ifeq ($(OPENJDK_TARGET_OS), solaris)
> ?? ifeq ($(OPENJDK_TARGET_CPU), x86_64)
> diff -r a47d1e21b3f1 make/lib/CoreLibraries.gmk
> --- a/make/lib/CoreLibraries.gmk??????? Thu Apr 05 10:54:53 2018 +0200
> +++ b/make/lib/CoreLibraries.gmk??????? Tue Apr 10 13:28:59 2018 +0300
> @@ -238,6 +238,9 @@
>
> ?ifeq ($(call check-jvm-variant, zero), true)
> ?? ERGO_FAMILY := zero
> +? ifeq ($(OPENJDK_TARGET_CPU), sparcv9)
> +??? BUILD_LIBJVM_EXTRA_FILES :=
> $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp
> +? endif
> ?else
> ?? ifeq ($(OPENJDK_TARGET_CPU_ARCH), x86)
> ???? ERGO_FAMILY := i586
>
> But that didn't help.
>
> Any ideas?
>
> Adrian
>
From glaubitz at physik.fu-berlin.de Tue Apr 10 11:00:55 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 10 Apr 2018 13:00:55 +0200
Subject: Zero fails to build on SPARC again, similar to JDK-8186578
In-Reply-To: <94be4fc8-25dc-c54c-417b-dd69ee0b721f@oracle.com>
References: <09c3fb5b-ab74-f478-c72d-538c7f8faaa8@physik.fu-berlin.de>
<2bacfb4d-b32f-4f9b-3f28-ec0067617986@physik.fu-berlin.de>
<94be4fc8-25dc-c54c-417b-dd69ee0b721f@oracle.com>
Message-ID: <64e6256a-c706-acf3-27c7-758dfeb54ea8@physik.fu-berlin.de>
On 04/10/2018 12:48 PM, David Holmes wrote:
> I'm guessing, as this relates to gtest, that you need to do something in make/hotspot/lib/CompileGtest.gmk
Ah, good catch. I missed the part where it mentions the gtest context.
Trying to add the necessary source there now.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From glaubitz at physik.fu-berlin.de Tue Apr 10 11:21:19 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 10 Apr 2018 13:21:19 +0200
Subject: Zero fails to build on SPARC again, similar to JDK-8186578
In-Reply-To: <64e6256a-c706-acf3-27c7-758dfeb54ea8@physik.fu-berlin.de>
References: <09c3fb5b-ab74-f478-c72d-538c7f8faaa8@physik.fu-berlin.de>
<2bacfb4d-b32f-4f9b-3f28-ec0067617986@physik.fu-berlin.de>
<94be4fc8-25dc-c54c-417b-dd69ee0b721f@oracle.com>
<64e6256a-c706-acf3-27c7-758dfeb54ea8@physik.fu-berlin.de>
Message-ID: <6e56596c-21bc-7e2f-c7e2-3ca1763162cd@physik.fu-berlin.de>
On 04/10/2018 01:00 PM, John Paul Adrian Glaubitz wrote:
> Trying to add the necessary source there now.
Hmm, I tried various ways of adding it now:
diff -r a47d1e21b3f1 make/hotspot/lib/CompileGtest.gmk
--- a/make/hotspot/lib/CompileGtest.gmk Thu Apr 05 10:54:53 2018 +0200
+++ b/make/hotspot/lib/CompileGtest.gmk Tue Apr 10 14:15:36 2018 +0300
@@ -52,6 +52,14 @@
$(call create-mapfile)
endif
+ifeq ($(call check-jvm-feature, zero), true)
+ JVM_CFLAGS_FEATURES += -DZERO -DCC_INTERP -DZERO_LIBARCH='"$(OPENJDK_TARGET_CPU_LEGACY_LIB)"' $(LIBFFI_CFLAGS)
+ JVM_LIBS_FEATURES += $(LIBFFI_LIBS)
+ ifeq ($(OPENJDK_TARGET_CPU), sparcv9)
+ BUILD_LIBJVM_EXTRA_FILES := $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp
+ endif
+endif
+
# Disabling undef, switch, format-nonliteral and tautological-undefined-compare
# warnings for clang because of test source.
@@ -71,7 +79,8 @@
EXCLUDES := $(JVM_EXCLUDES), \
EXCLUDE_FILES := gtestLauncher.cpp, \
EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \
- EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/src/gtest-all.cc, \
+ EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/src/gtest-all.cc \
+ $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp, \
EXTRA_OBJECT_FILES := $(filter-out %/operator_new$(OBJ_SUFFIX), \
$(BUILD_LIBJVM_ALL_OBJS)), \
CFLAGS := $(JVM_CFLAGS) -I$(GTEST_FRAMEWORK_SRC) \
@@ -109,7 +118,8 @@
NAME := gtestLauncher, \
TYPE := EXECUTABLE, \
OUTPUT_DIR := $(JVM_OUTPUTDIR)/gtest, \
- EXTRA_FILES := $(GTEST_LAUNCHER_SRC), \
+ EXTRA_FILES := $(GTEST_LAUNCHER_SRC) \
+ $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp, \
OBJECT_DIR := $(JVM_OUTPUTDIR)/gtest/launcher-objs, \
CFLAGS := $(JVM_CFLAGS) -I$(GTEST_FRAMEWORK_SRC) \
-I$(GTEST_FRAMEWORK_SRC)/include, \
diff -r a47d1e21b3f1 make/hotspot/lib/CompileJvm.gmk
--- a/make/hotspot/lib/CompileJvm.gmk Thu Apr 05 10:54:53 2018 +0200
+++ b/make/hotspot/lib/CompileJvm.gmk Tue Apr 10 14:15:36 2018 +0300
@@ -197,6 +197,14 @@
endif
endif
+ifeq ($(call check-jvm-feature, zero), true)
+ JVM_CFLAGS_FEATURES += -DZERO -DCC_INTERP -DZERO_LIBARCH='"$(OPENJDK_TARGET_CPU_LEGACY_LIB)"' $(LIBFFI_CFLAGS)
+ JVM_LIBS_FEATURES += $(LIBFFI_LIBS)
+ ifeq ($(OPENJDK_TARGET_CPU), sparcv9)
+ BUILD_LIBJVM_EXTRA_FILES := $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp
+ endif
+endif
+
ifeq ($(OPENJDK_TARGET_OS), windows)
ifeq ($(OPENJDK_TARGET_CPU_BITS), 64)
RC_DESC := 64-Bit$(SPACE)
It does build it, but the build system is unable to find the object files:
glaubitz at deb4g:/srv/glaubitz/hs$ find . -name "memset_with_concurrent_readers_sparc.o"
./build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/gtest/objs/memset_with_concurrent_readers_sparc.o
./build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/gtest/launcher-objs/memset_with_concurrent_readers_sparc.o
glaubitz at deb4g:/srv/glaubitz/hs$
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From david.holmes at oracle.com Tue Apr 10 11:34:05 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Apr 2018 21:34:05 +1000
Subject: Zero fails to build on SPARC again, similar to JDK-8186578
In-Reply-To: <6e56596c-21bc-7e2f-c7e2-3ca1763162cd@physik.fu-berlin.de>
References: <09c3fb5b-ab74-f478-c72d-538c7f8faaa8@physik.fu-berlin.de>
<2bacfb4d-b32f-4f9b-3f28-ec0067617986@physik.fu-berlin.de>
<94be4fc8-25dc-c54c-417b-dd69ee0b721f@oracle.com>
<64e6256a-c706-acf3-27c7-758dfeb54ea8@physik.fu-berlin.de>
<6e56596c-21bc-7e2f-c7e2-3ca1763162cd@physik.fu-berlin.de>
Message-ID: <19489bbb-6b34-2f8a-1296-2e7cb9a74d48@oracle.com>
Adding in build-dev. I think the build guys need to help you figure this
out.
Cheers,
David
On 10/04/2018 9:21 PM, John Paul Adrian Glaubitz wrote:
> On 04/10/2018 01:00 PM, John Paul Adrian Glaubitz wrote:
>> Trying to add the necessary source there now.
>
> Hmm, I tried various ways of adding it now:
>
> diff -r a47d1e21b3f1 make/hotspot/lib/CompileGtest.gmk
> --- a/make/hotspot/lib/CompileGtest.gmk Thu Apr 05 10:54:53 2018 +0200
> +++ b/make/hotspot/lib/CompileGtest.gmk Tue Apr 10 14:15:36 2018 +0300
> @@ -52,6 +52,14 @@
> ??????? $(call create-mapfile)
> ?endif
>
> +ifeq ($(call check-jvm-feature, zero), true)
> +? JVM_CFLAGS_FEATURES += -DZERO -DCC_INTERP
> -DZERO_LIBARCH='"$(OPENJDK_TARGET_CPU_LEGACY_LIB)"' $(LIBFFI_CFLAGS)
> +? JVM_LIBS_FEATURES += $(LIBFFI_LIBS)
> +? ifeq ($(OPENJDK_TARGET_CPU), sparcv9)
> +??? BUILD_LIBJVM_EXTRA_FILES :=
> $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp
> +? endif
> +endif
> +
> ?# Disabling undef, switch, format-nonliteral and
> tautological-undefined-compare
> ?# warnings for clang because of test source.
>
> @@ -71,7 +79,8 @@
> ???? EXCLUDES := $(JVM_EXCLUDES), \
> ???? EXCLUDE_FILES := gtestLauncher.cpp, \
> ???? EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \
> -??? EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/src/gtest-all.cc, \
> +??? EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/src/gtest-all.cc \
> +
> $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp, \
> ???? EXTRA_OBJECT_FILES := $(filter-out %/operator_new$(OBJ_SUFFIX), \
> ???????? $(BUILD_LIBJVM_ALL_OBJS)), \
> ???? CFLAGS := $(JVM_CFLAGS) -I$(GTEST_FRAMEWORK_SRC) \
> @@ -109,7 +118,8 @@
> ???? NAME := gtestLauncher, \
> ???? TYPE := EXECUTABLE, \
> ???? OUTPUT_DIR := $(JVM_OUTPUTDIR)/gtest, \
> -??? EXTRA_FILES := $(GTEST_LAUNCHER_SRC), \
> +??? EXTRA_FILES := $(GTEST_LAUNCHER_SRC) \
> +
> $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp, \
> ???? OBJECT_DIR := $(JVM_OUTPUTDIR)/gtest/launcher-objs, \
> ???? CFLAGS := $(JVM_CFLAGS) -I$(GTEST_FRAMEWORK_SRC) \
> ???????? -I$(GTEST_FRAMEWORK_SRC)/include, \
> diff -r a47d1e21b3f1 make/hotspot/lib/CompileJvm.gmk
> --- a/make/hotspot/lib/CompileJvm.gmk?? Thu Apr 05 10:54:53 2018 +0200
> +++ b/make/hotspot/lib/CompileJvm.gmk?? Tue Apr 10 14:15:36 2018 +0300
> @@ -197,6 +197,14 @@
> ?? endif
> ?endif
>
> +ifeq ($(call check-jvm-feature, zero), true)
> +? JVM_CFLAGS_FEATURES += -DZERO -DCC_INTERP
> -DZERO_LIBARCH='"$(OPENJDK_TARGET_CPU_LEGACY_LIB)"' $(LIBFFI_CFLAGS)
> +? JVM_LIBS_FEATURES += $(LIBFFI_LIBS)
> +? ifeq ($(OPENJDK_TARGET_CPU), sparcv9)
> +??? BUILD_LIBJVM_EXTRA_FILES :=
> $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp
> +? endif
> +endif
> +
> ?ifeq ($(OPENJDK_TARGET_OS), windows)
> ?? ifeq ($(OPENJDK_TARGET_CPU_BITS), 64)
> ???? RC_DESC := 64-Bit$(SPACE)
>
> It does build it, but the build system is unable to find the object files:
>
> glaubitz at deb4g:/srv/glaubitz/hs$ find . -name
> "memset_with_concurrent_readers_sparc.o"
> ./build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/gtest/objs/memset_with_concurrent_readers_sparc.o
>
> ./build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/gtest/launcher-objs/memset_with_concurrent_readers_sparc.o
>
> glaubitz at deb4g:/srv/glaubitz/hs$
>
> Adrian
>
From glaubitz at physik.fu-berlin.de Tue Apr 10 11:37:34 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 10 Apr 2018 13:37:34 +0200
Subject: Zero fails to build on SPARC again, similar to JDK-8186578
In-Reply-To: <19489bbb-6b34-2f8a-1296-2e7cb9a74d48@oracle.com>
References: <09c3fb5b-ab74-f478-c72d-538c7f8faaa8@physik.fu-berlin.de>
<2bacfb4d-b32f-4f9b-3f28-ec0067617986@physik.fu-berlin.de>
<94be4fc8-25dc-c54c-417b-dd69ee0b721f@oracle.com>
<64e6256a-c706-acf3-27c7-758dfeb54ea8@physik.fu-berlin.de>
<6e56596c-21bc-7e2f-c7e2-3ca1763162cd@physik.fu-berlin.de>
<19489bbb-6b34-2f8a-1296-2e7cb9a74d48@oracle.com>
Message-ID: <53bf36cd-f168-1805-20d7-9dbf99494834@physik.fu-berlin.de>
On 04/10/2018 01:34 PM, David Holmes wrote:
> Adding in build-dev. I think the build guys need to help you figure this out.
Good idea.
@buildd-dev:
I need to build memset_with_concurrent_readers_sparc.cpp for Zero on SPARC as
the Zero build now bails out with linker errors:
=== Output from failing command(s) repeated here ===
/usr/bin/printf "* For target hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:\n"
* For target hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:
(/bin/grep -v -e "^Note: including file:" < /srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.log || true) | /usr/bin/head -n 12
/srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/gtest/objs/test_memset_with_concurrent_readers.o: In function `gc_memset_with_concurrent_readers_test_Test::TestBody()':
/srv/glaubitz/hs/test/hotspot/gtest/gc/shared/test_memset_with_concurrent_readers.cpp:66: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o: In function `BlockOffsetArray::single_block(HeapWord*, HeapWord*)':
/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o: In function `BlockOffsetArrayNonContigSpace::alloc_block(HeapWord*, HeapWord*)':
/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o:/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: more undefined references to `memset_with_concurrent_readers(void*, int, unsigned long)' follow
collect2: error: ld returned 1 exit status
if test `/usr/bin/wc -l < /srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi
/usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link:\n"
* For target hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link:
(/bin/grep -v -e "^Note: including file:" < /srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link.log || true) | /usr/bin/head -n 12
/srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o: In function `BlockOffsetArray::single_block(HeapWord*, HeapWord*)':
/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o: In function `BlockOffsetArrayNonContigSpace::alloc_block(HeapWord*, HeapWord*)':
/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o: In function `BlockOffsetArray::BlockOffsetArray(BlockOffsetSharedArray*, MemRegion, bool)':
/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: undefined reference to `memset_with_concurrent_readers(void*, int, unsigned long)'
/srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/blockOffsetTable.o:/srv/glaubitz/hs/src/hotspot/share/gc/shared/blockOffsetTable.hpp:160: more undefined references to `memset_with_concurrent_readers(void*, int, unsigned long)' follow
collect2: error: ld returned 1 exit status
if test `/usr/bin/wc -l < /srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi
/usr/bin/printf "* For target jdk_modules_java.base__the.java.base_batch:\n"
* For target jdk_modules_java.base__the.java.base_batch:
(/bin/grep -v -e "^Note: including file:" < /srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/jdk_modules_java.base__the.java.base_batch.log || true) | /usr/bin/head -n 12
if test `/usr/bin/wc -l < /srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/jdk_modules_java.base__the.java.base_batch.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi
/usr/bin/printf "\n* All command lines available in /srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs.\n"
* All command lines available in /srv/glaubitz/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs.
/usr/bin/printf "=== End of repeated output ===\n"
=== End of repeated output ===
Any ideas?
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From per.liden at oracle.com Tue Apr 10 11:42:55 2018
From: per.liden at oracle.com (Per Liden)
Date: Tue, 10 Apr 2018 13:42:55 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
Message-ID: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
As part of the effort to make GCs more pluggable, the G1-specific data
in JavaThread should be moved out into a more appropriate abstraction.
This is the second step (building on JDK-8201316), which introduces
GCThreadLocalData, an opaque data area in Thread. Each GC is free to
decide the internal structure and contents of this area.
With this in place, we can remove G1's thread-local SATB queue and dirty
card queue from JavaThread and instead let G1 use the data area provided
by GCThreadLocalData to store these.
Other GCs that wants to store pre-thread information (e.g. ZGC and
Shenandoah) are encouraged to look at what G1 is doing here and use that
as a template/example.
Bug: https://bugs.openjdk.java.net/browse/JDK-8201318
Webrev: http://cr.openjdk.java.net/~pliden/8201318/webrev.0/
Testing: hs-tier{1-3}
/Per
From glaubitz at physik.fu-berlin.de Tue Apr 10 11:58:50 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 10 Apr 2018 13:58:50 +0200
Subject: Zero fails to build on SPARC again, similar to JDK-8186578
In-Reply-To: <53bf36cd-f168-1805-20d7-9dbf99494834@physik.fu-berlin.de>
References: <09c3fb5b-ab74-f478-c72d-538c7f8faaa8@physik.fu-berlin.de>
<2bacfb4d-b32f-4f9b-3f28-ec0067617986@physik.fu-berlin.de>
<94be4fc8-25dc-c54c-417b-dd69ee0b721f@oracle.com>
<64e6256a-c706-acf3-27c7-758dfeb54ea8@physik.fu-berlin.de>
<6e56596c-21bc-7e2f-c7e2-3ca1763162cd@physik.fu-berlin.de>
<19489bbb-6b34-2f8a-1296-2e7cb9a74d48@oracle.com>
<53bf36cd-f168-1805-20d7-9dbf99494834@physik.fu-berlin.de>
Message-ID: <9fede789-1f9a-a4e4-da4d-acdf8d40f91b@physik.fu-berlin.de>
On 04/10/2018 01:37 PM, John Paul Adrian Glaubitz wrote:
> @buildd-dev:
>
> I need to build memset_with_concurrent_readers_sparc.cpp for Zero on SPARC as
> the Zero build now bails out with linker errors:
Add the source file in question to EXTRA_FILES:
glaubitz at deb4g:/srv/glaubitz/hs$ hg diff
diff -r b3c09ab95c1a make/hotspot/lib/CompileGtest.gmk
--- a/make/hotspot/lib/CompileGtest.gmk Tue Apr 10 12:21:58 2018 +0200
+++ b/make/hotspot/lib/CompileGtest.gmk Tue Apr 10 14:57:05 2018 +0300
@@ -71,7 +71,8 @@
EXCLUDES := $(JVM_EXCLUDES), \
EXCLUDE_FILES := gtestLauncher.cpp, \
EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \
- EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/src/gtest-all.cc, \
+ EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/src/gtest-all.cc \
+ $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp, \
EXTRA_OBJECT_FILES := $(filter-out %/operator_new$(OBJ_SUFFIX), \
$(BUILD_LIBJVM_ALL_OBJS)), \
CFLAGS := $(JVM_CFLAGS) -I$(GTEST_FRAMEWORK_SRC) \
@@ -109,7 +110,8 @@
NAME := gtestLauncher, \
TYPE := EXECUTABLE, \
OUTPUT_DIR := $(JVM_OUTPUTDIR)/gtest, \
- EXTRA_FILES := $(GTEST_LAUNCHER_SRC), \
+ EXTRA_FILES := $(GTEST_LAUNCHER_SRC) \
+ $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp, \
OBJECT_DIR := $(JVM_OUTPUTDIR)/gtest/launcher-objs, \
CFLAGS := $(JVM_CFLAGS) -I$(GTEST_FRAMEWORK_SRC) \
-I$(GTEST_FRAMEWORK_SRC)/include, \
glaubitz at deb4g:/srv/glaubitz/hs$
Causes the object files to be built. But for some reason, the linker is not
picking up those object files even though they are located in the object
directories of gtest:
glaubitz at deb4g:/srv/glaubitz/hs$ find . -name "memset_with_concurrent_readers_sparc.o"
./build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/gtest/objs/memset_with_concurrent_readers_sparc.o
./build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/gtest/launcher-objs/memset_with_concurrent_readers_sparc.o
glaubitz at deb4g:/srv/glaubitz/hs$
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From coleen.phillimore at oracle.com Tue Apr 10 12:09:22 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 10 Apr 2018 08:09:22 -0400
Subject: RFR (M) 8198313: Wrap holder object for ClassLoaderData in a
WeakHandle
In-Reply-To: <9BD26D9A-E2EC-4E08-B977-9F7EB697D31C@oracle.com>
References: <3fe8b4c5-3e1d-d192-07ce-0828e3982e75@oracle.com>
<9C48FEF4-59DD-4415-AF18-B95ADBDFACB4@oracle.com>
<c62305c3-4567-d5c1-7aca-c5d47f885978@oracle.com>
<304110c1-f4e0-63c8-d94b-bc779b737411@oracle.com>
<4C4FB5D1-A0BA-4CC8-ADB7-8BED6BC2B88C@oracle.com>
<8372a910-f110-05df-85d0-e7c1859e4de4@oracle.com>
<5223d028-8eed-1835-d857-e2a277530f61@oracle.com>
<6A97EFE4-58F5-4916-B59B-7A0AB39F8817@oracle.com>
<c367a0ba-417b-fc0b-4b68-85ea02243df5@oracle.com>
<976145A0-081B-4101-B3FE-E00D9D137763@oracle.com>
<9BD26D9A-E2EC-4E08-B977-9F7EB697D31C@oracle.com>
Message-ID: <390b1a48-fd1b-f1d6-16a5-3c166b0ab800@oracle.com>
On 4/9/18 9:15 PM, Kim Barrett wrote:
>> On Apr 9, 2018, at 8:39 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>>
>>> On Apr 9, 2018, at 6:21 PM, coleen.phillimore at oracle.com wrote:
>>> This is the incremental change:
>>>
>>> http://cr.openjdk.java.net/~coleenp/8198313.incr.05/webrev/index.html
>>>
>>> Full changes:
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8198313.05/webrev
>>>
>>> Thanks,
>>> Coleen
>>>> ------------------------------------------------------------------------------
>> Looks good.
> I forgot to mention, in WeakHandle resolve and peek, consider asserting !is_null().
Sure I can do that.? It's more understandable than the insane assert I
get from Access.
Coleen
>
From robbin.ehn at oracle.com Tue Apr 10 12:18:55 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Tue, 10 Apr 2018 14:18:55 +0200
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
Message-ID: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
Hi all,
We have moved the global-counter to a separate change-set. The global-counter
uses a counter to determine current generation. Any reader needs to have a local
counter for which generation is currently read. By increment the global-counter
and scan for threads reading an old generation and wait for them to complete, we
know when an old generation is not visible (no pre-existing reader). In RCU
terms, this creates a grace-period. Making this mechanism suitable for a
read-mostly scenario. In this initial change-set we scan JavaThreads and the
VMThread.
A couple of enhancement to the global-counter will be looked into:
- Quiescent state RCU semantic by using the natural state of JavaThreads in the VM.
- Asynchronous write synchronize, where reclamation, if there are per-existing
reader, is done by the last reader leaving that generation.
- Register/deregister threads.
The current usage is the upcoming hash-table which uses the global-counter to
reclaim memory and to concurrently grow. We have also potential use-cases in
other work-in-progress code.
The new gtest passes on our platforms. For now you can look at the gtest if you
think you have a use-case for this as an example.
Code: http://cr.openjdk.java.net/~rehn/8195099/v1/webrev/
Issue: https://bugs.openjdk.java.net/browse/JDK-8195099
Thanks, Robbin
From per.liden at oracle.com Tue Apr 10 12:26:31 2018
From: per.liden at oracle.com (Per Liden)
Date: Tue, 10 Apr 2018 14:26:31 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
Message-ID: <978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
Hi Martin & Roman,
I just want to highlight that this change touches platform code for
s390/ppc and aarch64, so please verify that it doesn't break your builds.
cheers,
Per
On 04/10/2018 01:42 PM, Per Liden wrote:
> As part of the effort to make GCs more pluggable, the G1-specific data
> in JavaThread should be moved out into a more appropriate abstraction.
>
> This is the second step (building on JDK-8201316), which introduces
> GCThreadLocalData, an opaque data area in Thread. Each GC is free to
> decide the internal structure and contents of this area.
>
> With this in place, we can remove G1's thread-local SATB queue and dirty
> card queue from JavaThread and instead let G1 use the data area provided
> by GCThreadLocalData to store these.
>
> Other GCs that wants to store pre-thread information (e.g. ZGC and
> Shenandoah) are encouraged to look at what G1 is doing here and use that
> as a template/example.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201318
> Webrev: http://cr.openjdk.java.net/~pliden/8201318/webrev.0/
>
> Testing: hs-tier{1-3}
>
> /Per
>
From erik.osterlund at oracle.com Tue Apr 10 12:45:49 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Tue, 10 Apr 2018 14:45:49 +0200
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
Message-ID: <da8fea92-e08e-5801-544b-1e4b6200d6b2@oracle.com>
Hi Robbin,
The local counter loaded in critical_section_begin/end should not be
volatile (the compiler will produce unnecessarily crappy code).
globalCounter.hpp lacks a few includes:
memory/allocation.hpp and memory/padded.hpp.
Otherwise it looks good to me. I note that the lack of
release_store_fence() in critical_section_end() means that stores and
loads can float up into the critical section. I'm assuming that is fine
in the envisioned use cases, as long as accesses do not float out from
the critical section.
Thanks,
/Erik
On 2018-04-10 14:18, Robbin Ehn wrote:
> Hi all,
>
> We have moved the global-counter to a separate change-set. The
> global-counter
> uses a counter to determine current generation. Any reader needs to
> have a local
> counter for which generation is currently read. By increment the
> global-counter
> and scan for threads reading an old generation and wait for them to
> complete, we
> know when an old generation is not visible (no pre-existing reader).
> In RCU
> terms, this creates a grace-period. Making this mechanism suitable for
> a read-mostly scenario. In this initial change-set we scan JavaThreads
> and the VMThread.
>
> A couple of enhancement to the global-counter will be looked into:
> - Quiescent state RCU semantic by using the natural state of
> JavaThreads in the VM.
> - Asynchronous write synchronize, where reclamation, if there are
> per-existing
> reader, is done by the last reader leaving that generation.
> - Register/deregister threads.
>
> The current usage is the upcoming hash-table which uses the
> global-counter to reclaim memory and to concurrently grow. We have
> also potential use-cases in
> other work-in-progress code.
>
> The new gtest passes on our platforms. For now you can look at the
> gtest if you think you have a use-case for this as an example.
>
> Code: http://cr.openjdk.java.net/~rehn/8195099/v1/webrev/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8195099
>
> Thanks, Robbin
From per.liden at oracle.com Tue Apr 10 12:51:18 2018
From: per.liden at oracle.com (Per Liden)
Date: Tue, 10 Apr 2018 14:51:18 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
Message-ID: <1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
A couple of commits were pushed, which causes conflicts with this
change, so here's a rebased version:
http://cr.openjdk.java.net/~pliden/8201318/webrev.1
cheers,
Per
On 04/10/2018 02:26 PM, Per Liden wrote:
> Hi Martin & Roman,
>
> I just want to highlight that this change touches platform code for
> s390/ppc and aarch64, so please verify that it doesn't break your builds.
>
> cheers,
> Per
>
> On 04/10/2018 01:42 PM, Per Liden wrote:
>> As part of the effort to make GCs more pluggable, the G1-specific data
>> in JavaThread should be moved out into a more appropriate abstraction.
>>
>> This is the second step (building on JDK-8201316), which introduces
>> GCThreadLocalData, an opaque data area in Thread. Each GC is free to
>> decide the internal structure and contents of this area.
>>
>> With this in place, we can remove G1's thread-local SATB queue and
>> dirty card queue from JavaThread and instead let G1 use the data area
>> provided by GCThreadLocalData to store these.
>>
>> Other GCs that wants to store pre-thread information (e.g. ZGC and
>> Shenandoah) are encouraged to look at what G1 is doing here and use
>> that as a template/example.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201318
>> Webrev: http://cr.openjdk.java.net/~pliden/8201318/webrev.0/
>>
>> Testing: hs-tier{1-3}
>>
>> /Per
>>
From martin.doerr at sap.com Tue Apr 10 14:42:28 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 10 Apr 2018 14:42:28 +0000
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
Message-ID: <830dfd22c7414fb28f1c8af60b8a9774@sap.com>
Hi Per,
builds on PPC64 and s390 after applying 8201316 and 8201318.
Thanks and best regards,
Martin
-----Original Message-----
From: Per Liden [mailto:per.liden at oracle.com]
Sent: Dienstag, 10. April 2018 14:51
To: Roman Kennke <rkennke at redhat.com>; Doerr, Martin <martin.doerr at sap.com>; hotspot-dev at openjdk.java.net
Subject: Re: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific data belonging to a thread
A couple of commits were pushed, which causes conflicts with this
change, so here's a rebased version:
http://cr.openjdk.java.net/~pliden/8201318/webrev.1
cheers,
Per
On 04/10/2018 02:26 PM, Per Liden wrote:
> Hi Martin & Roman,
>
> I just want to highlight that this change touches platform code for
> s390/ppc and aarch64, so please verify that it doesn't break your builds.
>
> cheers,
> Per
>
> On 04/10/2018 01:42 PM, Per Liden wrote:
>> As part of the effort to make GCs more pluggable, the G1-specific data
>> in JavaThread should be moved out into a more appropriate abstraction.
>>
>> This is the second step (building on JDK-8201316), which introduces
>> GCThreadLocalData, an opaque data area in Thread. Each GC is free to
>> decide the internal structure and contents of this area.
>>
>> With this in place, we can remove G1's thread-local SATB queue and
>> dirty card queue from JavaThread and instead let G1 use the data area
>> provided by GCThreadLocalData to store these.
>>
>> Other GCs that wants to store pre-thread information (e.g. ZGC and
>> Shenandoah) are encouraged to look at what G1 is doing here and use
>> that as a template/example.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201318
>> Webrev: http://cr.openjdk.java.net/~pliden/8201318/webrev.0/
>>
>> Testing: hs-tier{1-3}
>>
>> /Per
>>
From robbin.ehn at oracle.com Tue Apr 10 14:42:38 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Tue, 10 Apr 2018 16:42:38 +0200
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <da8fea92-e08e-5801-544b-1e4b6200d6b2@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<da8fea92-e08e-5801-544b-1e4b6200d6b2@oracle.com>
Message-ID: <31e3f7cc-7df2-5bfe-cb56-9d7064d12fd7@oracle.com>
Hi Erik,
On 04/10/2018 02:45 PM, Erik ?sterlund wrote:
> Hi Robbin,
>
> The local counter loaded in critical_section_begin/end should not be volatile
> (the compiler will produce unnecessarily crappy code).
Thanks, fixed!
>
> globalCounter.hpp lacks a few includes:
> memory/allocation.hpp and memory/padded.hpp.
Thanks, fixed!
>
> Otherwise it looks good to me. I note that the lack of release_store_fence() in
> critical_section_end() means that stores and loads can float up into the
> critical section. I'm assuming that is fine in the envisioned use cases, as long
> as accesses do not float out from the critical section.
Yes, you are correct, added a comment.
Full: http://cr.openjdk.java.net/~rehn/8195099/v2/webrev/
Inc : http://cr.openjdk.java.net/~rehn/8195099/v2/inc/webrev/
Thanks, Robbin
>
> Thanks,
> /Erik
>
> On 2018-04-10 14:18, Robbin Ehn wrote:
>> Hi all,
>>
>> We have moved the global-counter to a separate change-set. The global-counter
>> uses a counter to determine current generation. Any reader needs to have a local
>> counter for which generation is currently read. By increment the global-counter
>> and scan for threads reading an old generation and wait for them to complete, we
>> know when an old generation is not visible (no pre-existing reader). In RCU
>> terms, this creates a grace-period. Making this mechanism suitable for a
>> read-mostly scenario. In this initial change-set we scan JavaThreads and the
>> VMThread.
>>
>> A couple of enhancement to the global-counter will be looked into:
>> - Quiescent state RCU semantic by using the natural state of JavaThreads in
>> the VM.
>> - Asynchronous write synchronize, where reclamation, if there are per-existing
>> reader, is done by the last reader leaving that generation.
>> - Register/deregister threads.
>>
>> The current usage is the upcoming hash-table which uses the global-counter to
>> reclaim memory and to concurrently grow. We have also potential use-cases in
>> other work-in-progress code.
>>
>> The new gtest passes on our platforms. For now you can look at the gtest if
>> you think you have a use-case for this as an example.
>>
>> Code: http://cr.openjdk.java.net/~rehn/8195099/v1/webrev/
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8195099
>>
>> Thanks, Robbin
>
From per.liden at oracle.com Tue Apr 10 14:45:57 2018
From: per.liden at oracle.com (Per Liden)
Date: Tue, 10 Apr 2018 16:45:57 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <830dfd22c7414fb28f1c8af60b8a9774@sap.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<830dfd22c7414fb28f1c8af60b8a9774@sap.com>
Message-ID: <e061eecb-d691-a6df-47c2-3a8658ef8af8@oracle.com>
Thanks for verifying Martin!
/Per
On 04/10/2018 04:42 PM, Doerr, Martin wrote:
> Hi Per,
>
> builds on PPC64 and s390 after applying 8201316 and 8201318.
>
> Thanks and best regards,
> Martin
>
>
> -----Original Message-----
> From: Per Liden [mailto:per.liden at oracle.com]
> Sent: Dienstag, 10. April 2018 14:51
> To: Roman Kennke <rkennke at redhat.com>; Doerr, Martin <martin.doerr at sap.com>; hotspot-dev at openjdk.java.net
> Subject: Re: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific data belonging to a thread
>
> A couple of commits were pushed, which causes conflicts with this
> change, so here's a rebased version:
>
> http://cr.openjdk.java.net/~pliden/8201318/webrev.1
>
> cheers,
> Per
>
> On 04/10/2018 02:26 PM, Per Liden wrote:
>> Hi Martin & Roman,
>>
>> I just want to highlight that this change touches platform code for
>> s390/ppc and aarch64, so please verify that it doesn't break your builds.
>>
>> cheers,
>> Per
>>
>> On 04/10/2018 01:42 PM, Per Liden wrote:
>>> As part of the effort to make GCs more pluggable, the G1-specific data
>>> in JavaThread should be moved out into a more appropriate abstraction.
>>>
>>> This is the second step (building on JDK-8201316), which introduces
>>> GCThreadLocalData, an opaque data area in Thread. Each GC is free to
>>> decide the internal structure and contents of this area.
>>>
>>> With this in place, we can remove G1's thread-local SATB queue and
>>> dirty card queue from JavaThread and instead let G1 use the data area
>>> provided by GCThreadLocalData to store these.
>>>
>>> Other GCs that wants to store pre-thread information (e.g. ZGC and
>>> Shenandoah) are encouraged to look at what G1 is doing here and use
>>> that as a template/example.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201318
>>> Webrev: http://cr.openjdk.java.net/~pliden/8201318/webrev.0/
>>>
>>> Testing: hs-tier{1-3}
>>>
>>> /Per
>>>
From erik.osterlund at oracle.com Tue Apr 10 14:50:06 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Tue, 10 Apr 2018 16:50:06 +0200
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <31e3f7cc-7df2-5bfe-cb56-9d7064d12fd7@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<da8fea92-e08e-5801-544b-1e4b6200d6b2@oracle.com>
<31e3f7cc-7df2-5bfe-cb56-9d7064d12fd7@oracle.com>
Message-ID: <8a766594-7c28-3db7-c69b-aff875eaa129@oracle.com>
Hi Robbin,
Looks good.
Thanks,
/Erik
On 2018-04-10 16:42, Robbin Ehn wrote:
> Hi Erik,
>
> On 04/10/2018 02:45 PM, Erik ?sterlund wrote:
>> Hi Robbin,
>>
>> The local counter loaded in critical_section_begin/end should not be
>> volatile (the compiler will produce unnecessarily crappy code).
>
> Thanks, fixed!
>
>>
>> globalCounter.hpp lacks a few includes:
>> memory/allocation.hpp and memory/padded.hpp.
>
> Thanks, fixed!
>
>>
>> Otherwise it looks good to me. I note that the lack of
>> release_store_fence() in critical_section_end() means that stores and
>> loads can float up into the critical section. I'm assuming that is
>> fine in the envisioned use cases, as long as accesses do not float
>> out from the critical section.
>
> Yes, you are correct, added a comment.
>
> Full: http://cr.openjdk.java.net/~rehn/8195099/v2/webrev/
> Inc : http://cr.openjdk.java.net/~rehn/8195099/v2/inc/webrev/
>
> Thanks, Robbin
>
>>
>> Thanks,
>> /Erik
>>
>> On 2018-04-10 14:18, Robbin Ehn wrote:
>>> Hi all,
>>>
>>> We have moved the global-counter to a separate change-set. The
>>> global-counter
>>> uses a counter to determine current generation. Any reader needs to
>>> have a local
>>> counter for which generation is currently read. By increment the
>>> global-counter
>>> and scan for threads reading an old generation and wait for them to
>>> complete, we
>>> know when an old generation is not visible (no pre-existing reader).
>>> In RCU
>>> terms, this creates a grace-period. Making this mechanism suitable
>>> for a read-mostly scenario. In this initial change-set we scan
>>> JavaThreads and the VMThread.
>>>
>>> A couple of enhancement to the global-counter will be looked into:
>>> - Quiescent state RCU semantic by using the natural state of
>>> JavaThreads in the VM.
>>> - Asynchronous write synchronize, where reclamation, if there are
>>> per-existing
>>> reader, is done by the last reader leaving that generation.
>>> - Register/deregister threads.
>>>
>>> The current usage is the upcoming hash-table which uses the
>>> global-counter to reclaim memory and to concurrently grow. We have
>>> also potential use-cases in
>>> other work-in-progress code.
>>>
>>> The new gtest passes on our platforms. For now you can look at the
>>> gtest if you think you have a use-case for this as an example.
>>>
>>> Code: http://cr.openjdk.java.net/~rehn/8195099/v1/webrev/
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8195099
>>>
>>> Thanks, Robbin
>>
From shade at redhat.com Tue Apr 10 15:04:14 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 10 Apr 2018 17:04:14 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
Message-ID: <6b382992-af7a-fd67-1494-ad9301c110db@redhat.com>
On 04/10/2018 02:51 PM, Per Liden wrote:
> A couple of commits were pushed, which causes conflicts with this change, so here's a rebased version:
>
> http://cr.openjdk.java.net/~pliden/8201318/webrev.1
*) I wonder if we can make the special accessors for the composite offsets? E.g. instead of
Address in_progress(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_offset() +
SATBMarkQueue::byte_offset_of_active()));
Address queue_index(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_offset() +
SATBMarkQueue::byte_offset_of_index()));
Address buffer(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_offset() +
SATBMarkQueue::byte_offset_of_buf()));
...do:
Address in_progress(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_active_offset()));
Address queue_index(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_index_offset()));
Address buffer(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_buf_offset()));
That probably eliminates the header dependency on SATBMarkQueue/DirtyCardQueue from
compiler/assembler stubs?
*) Should these new methods accept JavaThread*? I.e. we are expecting the GC thread-local data only
for JavaThreads, like attach/detach does?
virtual void on_thread_create(Thread* thread);
virtual void on_thread_destroy(Thread* thread);
virtual void on_thread_attach(JavaThread* thread);
virtual void on_thread_detach(JavaThread* thread);
*) Wait, why do we call JVMCI members JavaThread_*?
64 static int JavaThread_satb_mark_queue_offset;
65 static int JavaThread_dirty_card_queue_offset;
*) I would probably add assert(UseG1GC) to G1ThreadLocalData accessor methods
Thanks,
-Aleksey
From robbin.ehn at oracle.com Tue Apr 10 15:25:26 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Tue, 10 Apr 2018 17:25:26 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
Message-ID: <155309e7-e495-4ec7-7351-51e261ec7f1c@oracle.com>
Hi Per,
Had quick look, what I saw looked good. (not a full review)
Is there a reason for moving the gc data to 'zero offset' in Thread?
/Robbin
On 2018-04-10 14:51, Per Liden wrote:
> A couple of commits were pushed, which causes conflicts with this change, so here's a rebased version:
>
> http://cr.openjdk.java.net/~pliden/8201318/webrev.1
>
> cheers,
> Per
>
> On 04/10/2018 02:26 PM, Per Liden wrote:
>> Hi Martin & Roman,
>>
>> I just want to highlight that this change touches platform code for s390/ppc and aarch64, so please verify that it
>> doesn't break your builds.
>>
>> cheers,
>> Per
>>
>> On 04/10/2018 01:42 PM, Per Liden wrote:
>>> As part of the effort to make GCs more pluggable, the G1-specific data in JavaThread should be moved out into a more
>>> appropriate abstraction.
>>>
>>> This is the second step (building on JDK-8201316), which introduces GCThreadLocalData, an opaque data area in Thread.
>>> Each GC is free to decide the internal structure and contents of this area.
>>>
>>> With this in place, we can remove G1's thread-local SATB queue and dirty card queue from JavaThread and instead let
>>> G1 use the data area provided by GCThreadLocalData to store these.
>>>
>>> Other GCs that wants to store pre-thread information (e.g. ZGC and Shenandoah) are encouraged to look at what G1 is
>>> doing here and use that as a template/example.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201318
>>> Webrev: http://cr.openjdk.java.net/~pliden/8201318/webrev.0/
>>>
>>> Testing: hs-tier{1-3}
>>>
>>> /Per
>>>
From goetz.lindenmaier at sap.com Tue Apr 10 15:34:28 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 10 Apr 2018 15:34:28 +0000
Subject: RFR (M): 8201247: Various cleanups in the attach framework
In-Reply-To: <14dff9b0cf5a4b888aef1d6452801b57@sap.com>
References: <14dff9b0cf5a4b888aef1d6452801b57@sap.com>
Message-ID: <29475f2084e24093892b4289b1e34f62@sap.com>
Hi Christoph,
thanks for doing this laborious change ... comparing all these files :)
Change looks good, just some minor comments:
You say you are sorting the includes, but in the VirtualMachineImpl.c
files the order is changed, but according to which order? It's
not alphabetical as in other files.
In windows VirtualMachineImpl.c, what was wrong with printing the
last error code?
Best regards,
Goetz.
> -----Original Message-----
> From: serviceability-dev [mailto:serviceability-dev-
> bounces at openjdk.java.net] On Behalf Of Langer, Christoph
> Sent: Freitag, 6. April 2018 17:02
> To: serviceability-dev at openjdk.java.net
> Cc: hotspot-dev at openjdk.java.net
> Subject: [CAUTION] RFR (M): 8201247: Various cleanups in the attach
> framework
>
> Hi,
>
>
>
> can I please get reviews for a set of clean up changes that I came across
> when doing some integration work.
>
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201247
> <https://bugs.openjdk.java.net/browse/JDK-8201247>
>
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/
> <http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/>
>
>
>
> Detailed comments about the changes can be found in the bug.
>
>
>
> Thanks & best regards
>
> Christoph
>
>
>
>
From aph at redhat.com Tue Apr 10 15:35:44 2018
From: aph at redhat.com (Andrew Haley)
Date: Tue, 10 Apr 2018 16:35:44 +0100
Subject: Graal inlining and AOT
Message-ID: <99a2b807-e21e-3cd6-033e-c6fc0798f6fd@redhat.com>
So I upgraded Graal by pulling from master. Inlining has
gone *crazy*. This method when AOT compiled
public static void main(String[] args) {
System.out.println("Hello, World!");
}
... now generates half a freakin' megabyte of code.
So, has anyone touched the knob that controls inlining? :-)
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From shade at redhat.com Tue Apr 10 15:47:05 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 10 Apr 2018 17:47:05 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <155309e7-e495-4ec7-7351-51e261ec7f1c@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<155309e7-e495-4ec7-7351-51e261ec7f1c@oracle.com>
Message-ID: <989c2ec0-ef6a-017b-d15a-85eacb0017e0@redhat.com>
On 04/10/2018 05:25 PM, Robbin Ehn wrote:
> Had quick look, what I saw looked good. (not a full review)
> Is there a reason for moving the gc data to 'zero offset' in Thread?
Oh! I missed that, and I fully agree with this move. At least one reason I see, smaller offsets
against TLS open up opportunities for denser code-generation when e.g. GC barriers poll thread-local
data. Right now SATB barrier generates something like "cmpb $0x0, 0x3d8(%r15)", while it could
generate just "cmpb $0x0, 0x0(%r15)" now :)
Thanks,
-Aleksey
From kim.barrett at oracle.com Tue Apr 10 15:53:20 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 10 Apr 2018 11:53:20 -0400
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <31e3f7cc-7df2-5bfe-cb56-9d7064d12fd7@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<da8fea92-e08e-5801-544b-1e4b6200d6b2@oracle.com>
<31e3f7cc-7df2-5bfe-cb56-9d7064d12fd7@oracle.com>
Message-ID: <F5A643B9-CBD4-416C-B200-205363665719@oracle.com>
> On Apr 10, 2018, at 10:42 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>
> Full: http://cr.openjdk.java.net/~rehn/8195099/v2/webrev/
> Inc : http://cr.openjdk.java.net/~rehn/8195099/v2/inc/webrev/
------------------------------------------------------------------------------
GlobalCounter describes its implementation, but is not the least bit
evocative of its purpose. I don't have a good name suggestion though.
------------------------------------------------------------------------------
This is being put in utilities. Similarly we put SpinYield in
utilities. But I'm not sure either of those are properly placed
there. These are synchronization building blocks, and all other
synchronization stuff is in runtime.
------------------------------------------------------------------------------
src/hotspot/share/utilities/globalCounter.hpp
Consider just forward declaring Thread (at namespace scope).
Consider just forward declaring CounterThreadCheck at class scope,
with the definition in the .cpp file.
With those changes, don't need to #include thread.hpp in this header.
Although globalCounter.inline.hpp still needs to #include thread.hpp,
so maybe this doesn't matter so much?
------------------------------------------------------------------------------
src/hotspot/share/utilities/globalCounter.hpp
Although CriticalSection is fully defined in this header, I think it
can't be instantiated without including globalCounter.inline.hpp.
Consider just forward declaring in the GlobalCounter definition, with
the definition in the .inline.hpp.
------------------------------------------------------------------------------
src/hotspot/share/utilities/globalCounter.inline.hpp
Missing #include globalCounter.hpp.
------------------------------------------------------------------------------
src/hotspot/share/utilities/globalCounter.inline.hpp
36 OrderAccess::release_store_fence(thread->get_rcu_counter(), gbl_cnt + 1);
"gbl_cnt + 1" => "gbl_cnt | COUNTER_ACTIVE".
------------------------------------------------------------------------------
src/hotspot/share/utilities/globalCounter.hpp
74 // Must be called after finished accessing the data.
75 // Do not provide fence, allows load/stores moving into the critical section.
76 static void critical_section_end(Thread *thread);
Both begin and end should have descriptions of their ordering
behavior. I'm thinking something similar to the descriptions we have
for Atomic operations.
------------------------------------------------------------------------------
From robbin.ehn at oracle.com Tue Apr 10 15:59:06 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Tue, 10 Apr 2018 17:59:06 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <989c2ec0-ef6a-017b-d15a-85eacb0017e0@redhat.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<155309e7-e495-4ec7-7351-51e261ec7f1c@oracle.com>
<989c2ec0-ef6a-017b-d15a-85eacb0017e0@redhat.com>
Message-ID: <5d6c54ae-1e72-3ac2-9d56-dae81fa4de9e@oracle.com>
On 2018-04-10 17:47, Aleksey Shipilev wrote:
> On 04/10/2018 05:25 PM, Robbin Ehn wrote:
>> Had quick look, what I saw looked good. (not a full review)
>> Is there a reason for moving the gc data to 'zero offset' in Thread?
>
> Oh! I missed that, and I fully agree with this move. At least one reason I see, smaller offsets
> against TLS open up opportunities for denser code-generation when e.g. GC barriers poll thread-local
> data. Right now SATB barrier generates something like "cmpb $0x0, 0x3d8(%r15)", while it could
> generate just "cmpb $0x0, 0x0(%r15)" now :)
Yes, but it pushes down e.g.:
333 volatile void* _polling_page; // Thread local polling page
Which may not matter, as long as it's on the first page I suppose.
/Robbin
>
> Thanks,
> -Aleksey
>
From shade at redhat.com Tue Apr 10 16:50:40 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 10 Apr 2018 18:50:40 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <5d6c54ae-1e72-3ac2-9d56-dae81fa4de9e@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<155309e7-e495-4ec7-7351-51e261ec7f1c@oracle.com>
<989c2ec0-ef6a-017b-d15a-85eacb0017e0@redhat.com>
<5d6c54ae-1e72-3ac2-9d56-dae81fa4de9e@oracle.com>
Message-ID: <7e60b7a8-1806-18dd-e09f-d56ffac8a8a9@redhat.com>
On 04/10/2018 05:59 PM, Robbin Ehn wrote:
> On 2018-04-10 17:47, Aleksey Shipilev wrote:
>> On 04/10/2018 05:25 PM, Robbin Ehn wrote:
>>> Had quick look, what I saw looked good. (not a full review)
>>> Is there a reason for moving the gc data to 'zero offset' in Thread?
>>
>> Oh! I missed that, and I fully agree with this move. At least one reason I see, smaller offsets
>> against TLS open up opportunities for denser code-generation when e.g. GC barriers poll thread-local
>> data. Right now SATB barrier generates something like "cmpb $0x0, 0x3d8(%r15)", while it could
>> generate just "cmpb $0x0, 0x0(%r15)" now :)
>
> Yes, but it pushes down e.g.:
> 333?? volatile void* _polling_page;???????????????? // Thread local polling page
> Which may not matter, as long as it's on the first page I suppose.
I think the major concern should be the instruction size. On x86 what matters is what category
immediate offset falls into. Some hand-crafted assembly:
0: 48 89 42 7f mov %rax,0x7f(%rdx)
4: 48 89 82 80 00 00 00 mov %rax,0x80(%rdx)
b: 80 7a 7f 00 cmpb $0x0,0x7f(%rdx)
f: 80 ba 80 00 00 00 00 cmpb $0x0,0x80(%rdx)
16: 80 7a 7f 41 cmpb $0x41,0x7f(%rdx)
1a: 80 ba 80 00 00 00 41 cmpb $0x41,0x80(%rdx)
21: f6 42 7f 00 testb $0x0,0x7f(%rdx)
25: f6 82 80 00 00 00 00 testb $0x0,0x80(%rdx)
2c: f6 42 7f 41 testb $0x41,0x7f(%rdx)
30: f6 82 80 00 00 00 41 testb $0x41,0x80(%rdx)
In our case, we want to pack the most used fields under first 128 bytes. Maybe we should put polling
page at offset 0, and trim GCTLD to 96 bytes?
Thanks,
-Aleksey
From shade at redhat.com Tue Apr 10 16:52:11 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 10 Apr 2018 18:52:11 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <7e60b7a8-1806-18dd-e09f-d56ffac8a8a9@redhat.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<155309e7-e495-4ec7-7351-51e261ec7f1c@oracle.com>
<989c2ec0-ef6a-017b-d15a-85eacb0017e0@redhat.com>
<5d6c54ae-1e72-3ac2-9d56-dae81fa4de9e@oracle.com>
<7e60b7a8-1806-18dd-e09f-d56ffac8a8a9@redhat.com>
Message-ID: <74242360-efbd-3ef2-0d70-6af579a4a7fe@redhat.com>
On 04/10/2018 06:50 PM, Aleksey Shipilev wrote:
> On 04/10/2018 05:59 PM, Robbin Ehn wrote:
>> On 2018-04-10 17:47, Aleksey Shipilev wrote:
>>> On 04/10/2018 05:25 PM, Robbin Ehn wrote:
>>>> Had quick look, what I saw looked good. (not a full review)
>>>> Is there a reason for moving the gc data to 'zero offset' in Thread?
>>>
>>> Oh! I missed that, and I fully agree with this move. At least one reason I see, smaller offsets
>>> against TLS open up opportunities for denser code-generation when e.g. GC barriers poll thread-local
>>> data. Right now SATB barrier generates something like "cmpb $0x0, 0x3d8(%r15)", while it could
>>> generate just "cmpb $0x0, 0x0(%r15)" now :)
>>
>> Yes, but it pushes down e.g.:
>> 333?? volatile void* _polling_page;???????????????? // Thread local polling page
>> Which may not matter, as long as it's on the first page I suppose.
>
> I think the major concern should be the instruction size. On x86 what matters is what category
> immediate offset falls into. Some hand-crafted assembly:
>
> 0: 48 89 42 7f mov %rax,0x7f(%rdx)
> 4: 48 89 82 80 00 00 00 mov %rax,0x80(%rdx)
> b: 80 7a 7f 00 cmpb $0x0,0x7f(%rdx)
> f: 80 ba 80 00 00 00 00 cmpb $0x0,0x80(%rdx)
> 16: 80 7a 7f 41 cmpb $0x41,0x7f(%rdx)
> 1a: 80 ba 80 00 00 00 41 cmpb $0x41,0x80(%rdx)
> 21: f6 42 7f 00 testb $0x0,0x7f(%rdx)
> 25: f6 82 80 00 00 00 00 testb $0x0,0x80(%rdx)
> 2c: f6 42 7f 41 testb $0x41,0x7f(%rdx)
> 30: f6 82 80 00 00 00 41 testb $0x41,0x80(%rdx)
>
>
> In our case, we want to pack the most used fields under first 128 bytes. Maybe we should put polling
> page at offset 0, and trim GCTLD to 96 bytes?
Should have used %r15, of course, which does not change the picture qualitatively:
0: 49 89 47 7f mov %rax,0x7f(%r15)
4: 49 89 87 80 00 00 00 mov %rax,0x80(%r15)
b: 41 80 7f 7f 00 cmpb $0x0,0x7f(%r15)
10: 41 80 bf 80 00 00 00 cmpb $0x0,0x80(%r15)
17: 00
18: 41 80 7f 7f 41 cmpb $0x41,0x7f(%r15)
1d: 41 80 bf 80 00 00 00 cmpb $0x41,0x80(%r15)
24: 41
25: 41 f6 47 7f 00 testb $0x0,0x7f(%r15)
2a: 41 f6 87 80 00 00 00 testb $0x0,0x80(%r15)
31: 00
32: 41 f6 47 7f 41 testb $0x41,0x7f(%r15)
37: 41 f6 87 80 00 00 00 testb $0x41,0x80(%r15)
3e: 41
-Aleksey
From erik.joelsson at oracle.com Tue Apr 10 16:54:11 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 10 Apr 2018 09:54:11 -0700
Subject: Zero fails to build on SPARC again, similar to JDK-8186578
In-Reply-To: <9fede789-1f9a-a4e4-da4d-acdf8d40f91b@physik.fu-berlin.de>
References: <09c3fb5b-ab74-f478-c72d-538c7f8faaa8@physik.fu-berlin.de>
<2bacfb4d-b32f-4f9b-3f28-ec0067617986@physik.fu-berlin.de>
<94be4fc8-25dc-c54c-417b-dd69ee0b721f@oracle.com>
<64e6256a-c706-acf3-27c7-758dfeb54ea8@physik.fu-berlin.de>
<6e56596c-21bc-7e2f-c7e2-3ca1763162cd@physik.fu-berlin.de>
<19489bbb-6b34-2f8a-1296-2e7cb9a74d48@oracle.com>
<53bf36cd-f168-1805-20d7-9dbf99494834@physik.fu-berlin.de>
<9fede789-1f9a-a4e4-da4d-acdf8d40f91b@physik.fu-berlin.de>
Message-ID: <d4d05936-c1da-00d0-d0bf-eebf3bf1e866@oracle.com>
I've found the problem. In JvmFeatures.gmk we have:
ifeq ($(call check-jvm-feature, zero), true)
? JVM_CFLAGS_FEATURES += -DZERO -DCC_INTERP
-DZERO_LIBARCH='"$(OPENJDK_TARGET_CPU_LEGACY_LIB)"' $(LIBFFI_CFLAGS)
? JVM_LIBS_FEATURES += $(LIBFFI_LIBS)
? ifeq ($(OPENJDK_TARGET_CPU), sparcv9)
??? BUILD_LIBJVM_EXTRA_FILES :=
$(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp
? endif
endif
The BUILD_LIBJVM_EXTRA_FILES is implicitly trying to set the EXTRA_FILES
argument to the BUILD_LIBJVM SetupNativeCompilation call. This used to
work because there was no setting of that parameter in the actual call.
In a recent change, that parameter is not set to something else,
overriding the assignment above.
To fix this, you need to add $(BUILD_LIBJVM_EXTRA_FILES) to the
EXTRA_FILES line in CompileJvm.gmk.
/Erik
On 2018-04-10 04:58, John Paul Adrian Glaubitz wrote:
> On 04/10/2018 01:37 PM, John Paul Adrian Glaubitz wrote:
>> @buildd-dev:
>>
>> I need to build memset_with_concurrent_readers_sparc.cpp for Zero on
>> SPARC as
>> the Zero build now bails out with linker errors:
> Add the source file in question to EXTRA_FILES:
>
> glaubitz at deb4g:/srv/glaubitz/hs$ hg diff
> diff -r b3c09ab95c1a make/hotspot/lib/CompileGtest.gmk
> --- a/make/hotspot/lib/CompileGtest.gmk Tue Apr 10 12:21:58 2018 +0200
> +++ b/make/hotspot/lib/CompileGtest.gmk Tue Apr 10 14:57:05 2018 +0300
> @@ -71,7 +71,8 @@
> ???? EXCLUDES := $(JVM_EXCLUDES), \
> ???? EXCLUDE_FILES := gtestLauncher.cpp, \
> ???? EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \
> -??? EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/src/gtest-all.cc, \
> +??? EXTRA_FILES := $(GTEST_FRAMEWORK_SRC)/src/gtest-all.cc \
> +
> $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp,
> \
> ???? EXTRA_OBJECT_FILES := $(filter-out %/operator_new$(OBJ_SUFFIX), \
> ???????? $(BUILD_LIBJVM_ALL_OBJS)), \
> ???? CFLAGS := $(JVM_CFLAGS) -I$(GTEST_FRAMEWORK_SRC) \
> @@ -109,7 +110,8 @@
> ???? NAME := gtestLauncher, \
> ???? TYPE := EXECUTABLE, \
> ???? OUTPUT_DIR := $(JVM_OUTPUTDIR)/gtest, \
> -??? EXTRA_FILES := $(GTEST_LAUNCHER_SRC), \
> +??? EXTRA_FILES := $(GTEST_LAUNCHER_SRC) \
> +
> $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp,
> \
> ???? OBJECT_DIR := $(JVM_OUTPUTDIR)/gtest/launcher-objs, \
> ???? CFLAGS := $(JVM_CFLAGS) -I$(GTEST_FRAMEWORK_SRC) \
> ???????? -I$(GTEST_FRAMEWORK_SRC)/include, \
> glaubitz at deb4g:/srv/glaubitz/hs$
>
> Causes the object files to be built. But for some reason, the linker
> is not
> picking up those object files even though they are located in the object
> directories of gtest:
>
> glaubitz at deb4g:/srv/glaubitz/hs$ find . -name
> "memset_with_concurrent_readers_sparc.o"
> ./build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/gtest/objs/memset_with_concurrent_readers_sparc.o
>
> ./build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/gtest/launcher-objs/memset_with_concurrent_readers_sparc.o
>
> glaubitz at deb4g:/srv/glaubitz/hs$
>
> Adrian
>
From boris.ulasevich at bell-sw.com Tue Apr 10 16:56:48 2018
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Tue, 10 Apr 2018 19:56:48 +0300
Subject: RFR (S) 8201370: Minimal VM build fail
Message-ID: <ae347b5b-0d19-c9da-ff69-ed9f621643c2@bell-sw.com>
Hi all,
Please review this patch to fix Minimal VM build fail caused by recent
GC headers updating.
https://bugs.openjdk.java.net/browse/JDK-8201370
http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8201370/webrev.00/
I will post separate review on arm32-specific changes.
Thanks,
Boris
From boris.ulasevich at bell-sw.com Tue Apr 10 16:58:37 2018
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Tue, 10 Apr 2018 19:58:37 +0300
Subject: RFR (S) 8201372: aarch32 - 'minimal' build fails because CMS bits are
referred unconditionally
Message-ID: <e5f65fff-b80e-b16b-d091-0242a6de398b@bell-sw.com>
Hi all,
Please review this patch to fix Minimal VM build fail caused by recent
GC headers updating.
https://bugs.openjdk.java.net/browse/JDK-8201372
http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8201372/webrev.00/
Thanks,
Boris
From shade at redhat.com Tue Apr 10 17:06:05 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 10 Apr 2018 19:06:05 +0200
Subject: RFR (S) 8201370: Minimal VM build fail
In-Reply-To: <ae347b5b-0d19-c9da-ff69-ed9f621643c2@bell-sw.com>
References: <ae347b5b-0d19-c9da-ff69-ed9f621643c2@bell-sw.com>
Message-ID: <cc077d0c-1d0c-455d-03c8-f437463d58b7@redhat.com>
On 04/10/2018 06:56 PM, Boris Ulasevich wrote:
> Please review this patch to fix Minimal VM build fail caused by recent GC headers updating.
>
> ?https://bugs.openjdk.java.net/browse/JDK-8201370
> ?http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8201370/webrev.00/
This looks good and trivial to me.
-Aleksey
From shade at redhat.com Tue Apr 10 17:06:50 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 10 Apr 2018 19:06:50 +0200
Subject: RFR (S) 8201372: aarch32 - 'minimal' build fails because CMS bits
are referred unconditionally
In-Reply-To: <e5f65fff-b80e-b16b-d091-0242a6de398b@bell-sw.com>
References: <e5f65fff-b80e-b16b-d091-0242a6de398b@bell-sw.com>
Message-ID: <fa06022e-3b74-ac0e-09be-f9a2f433d148@redhat.com>
On 04/10/2018 06:58 PM, Boris Ulasevich wrote:
> Please review this patch to fix Minimal VM build fail caused by recent GC headers updating.
>
> ?https://bugs.openjdk.java.net/browse/JDK-8201372
> ?http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8201372/webrev.00/
This looks good and trivial to me too.
-Aleksey
From chris.plummer at oracle.com Tue Apr 10 17:31:19 2018
From: chris.plummer at oracle.com (Chris Plummer)
Date: Tue, 10 Apr 2018 10:31:19 -0700
Subject: RFR (M): 8201247: Various cleanups in the attach framework
In-Reply-To: <29475f2084e24093892b4289b1e34f62@sap.com>
References: <14dff9b0cf5a4b888aef1d6452801b57@sap.com>
<29475f2084e24093892b4289b1e34f62@sap.com>
Message-ID: <50b1511e-9f45-60eb-bbec-9734da10f373@oracle.com>
On 4/10/18 8:34 AM, Lindenmaier, Goetz wrote:
> Hi Christoph,
>
> thanks for doing this laborious change ... comparing all these files :)
>
> Change looks good, just some minor comments:
>
> You say you are sorting the includes, but in the VirtualMachineImpl.c
> files the order is changed, but according to which order? It's
> not alphabetical as in other files.
>
> In windows VirtualMachineImpl.c, what was wrong with printing the
> last error code?
JNU_ThrowIOExceptionWithLastError already includes it.
Chris
>
> Best regards,
> Goetz.
>
>
>
>> -----Original Message-----
>> From: serviceability-dev [mailto:serviceability-dev-
>> bounces at openjdk.java.net] On Behalf Of Langer, Christoph
>> Sent: Freitag, 6. April 2018 17:02
>> To: serviceability-dev at openjdk.java.net
>> Cc: hotspot-dev at openjdk.java.net
>> Subject: [CAUTION] RFR (M): 8201247: Various cleanups in the attach
>> framework
>>
>> Hi,
>>
>>
>>
>> can I please get reviews for a set of clean up changes that I came across
>> when doing some integration work.
>>
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201247
>> <https://bugs.openjdk.java.net/browse/JDK-8201247>
>>
>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/
>> <http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/>
>>
>>
>>
>> Detailed comments about the changes can be found in the bug.
>>
>>
>>
>> Thanks & best regards
>>
>> Christoph
>>
>>
>>
>>
From glaubitz at physik.fu-berlin.de Tue Apr 10 17:50:40 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 10 Apr 2018 19:50:40 +0200
Subject: Zero fails to build on SPARC again, similar to JDK-8186578
In-Reply-To: <d4d05936-c1da-00d0-d0bf-eebf3bf1e866@oracle.com>
References: <09c3fb5b-ab74-f478-c72d-538c7f8faaa8@physik.fu-berlin.de>
<2bacfb4d-b32f-4f9b-3f28-ec0067617986@physik.fu-berlin.de>
<94be4fc8-25dc-c54c-417b-dd69ee0b721f@oracle.com>
<64e6256a-c706-acf3-27c7-758dfeb54ea8@physik.fu-berlin.de>
<6e56596c-21bc-7e2f-c7e2-3ca1763162cd@physik.fu-berlin.de>
<19489bbb-6b34-2f8a-1296-2e7cb9a74d48@oracle.com>
<53bf36cd-f168-1805-20d7-9dbf99494834@physik.fu-berlin.de>
<9fede789-1f9a-a4e4-da4d-acdf8d40f91b@physik.fu-berlin.de>
<d4d05936-c1da-00d0-d0bf-eebf3bf1e866@oracle.com>
Message-ID: <83aa56f4-d44c-f793-c2e1-0b1f8a15f14c@physik.fu-berlin.de>
Hi Erik!
On 04/10/2018 06:54 PM, Erik Joelsson wrote:
> I've found the problem. In JvmFeatures.gmk we have:
>
> ifeq ($(call check-jvm-feature, zero), true)
> ? JVM_CFLAGS_FEATURES += -DZERO -DCC_INTERP -DZERO_LIBARCH='"$(OPENJDK_TARGET_CPU_LEGACY_LIB)"' $(LIBFFI_CFLAGS)
> ? JVM_LIBS_FEATURES += $(LIBFFI_LIBS)
> ? ifeq ($(OPENJDK_TARGET_CPU), sparcv9)
> ??? BUILD_LIBJVM_EXTRA_FILES := $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp
> ? endif
> endif
>
> The BUILD_LIBJVM_EXTRA_FILES is implicitly trying to set the EXTRA_FILES argument to the BUILD_LIBJVM SetupNativeCompilation call. This used to work because there was no setting of that parameter in the actual call. In a recent change, that parameter is not set to something else, overriding the assignment above.
Aha! Do you happen to know which change was responsible for that? Then I can
adjust the bug summary accordingly.
> To fix this, you need to add $(BUILD_LIBJVM_EXTRA_FILES) to the EXTRA_FILES line in CompileJvm.gmk.
Indeed, this fixes it! Thanks so much, I was already about to give up ;).
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From erik.joelsson at oracle.com Tue Apr 10 18:04:39 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 10 Apr 2018 11:04:39 -0700
Subject: Zero fails to build on SPARC again, similar to JDK-8186578
In-Reply-To: <83aa56f4-d44c-f793-c2e1-0b1f8a15f14c@physik.fu-berlin.de>
References: <09c3fb5b-ab74-f478-c72d-538c7f8faaa8@physik.fu-berlin.de>
<2bacfb4d-b32f-4f9b-3f28-ec0067617986@physik.fu-berlin.de>
<94be4fc8-25dc-c54c-417b-dd69ee0b721f@oracle.com>
<64e6256a-c706-acf3-27c7-758dfeb54ea8@physik.fu-berlin.de>
<6e56596c-21bc-7e2f-c7e2-3ca1763162cd@physik.fu-berlin.de>
<19489bbb-6b34-2f8a-1296-2e7cb9a74d48@oracle.com>
<53bf36cd-f168-1805-20d7-9dbf99494834@physik.fu-berlin.de>
<9fede789-1f9a-a4e4-da4d-acdf8d40f91b@physik.fu-berlin.de>
<d4d05936-c1da-00d0-d0bf-eebf3bf1e866@oracle.com>
<83aa56f4-d44c-f793-c2e1-0b1f8a15f14c@physik.fu-berlin.de>
Message-ID: <3ea4b91f-d693-0506-f3bc-3e0503c830d5@oracle.com>
On 2018-04-10 10:50, John Paul Adrian Glaubitz wrote:
> Hi Erik!
>
> On 04/10/2018 06:54 PM, Erik Joelsson wrote:
>> I've found the problem. In JvmFeatures.gmk we have:
>>
>> ifeq ($(call check-jvm-feature, zero), true)
>> ?? JVM_CFLAGS_FEATURES += -DZERO -DCC_INTERP
>> -DZERO_LIBARCH='"$(OPENJDK_TARGET_CPU_LEGACY_LIB)"' $(LIBFFI_CFLAGS)
>> ?? JVM_LIBS_FEATURES += $(LIBFFI_LIBS)
>> ?? ifeq ($(OPENJDK_TARGET_CPU), sparcv9)
>> ???? BUILD_LIBJVM_EXTRA_FILES :=
>> $(TOPDIR)/src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp
>> ?? endif
>> endif
>>
>> The BUILD_LIBJVM_EXTRA_FILES is implicitly trying to set the
>> EXTRA_FILES argument to the BUILD_LIBJVM SetupNativeCompilation call.
>> This used to work because there was no setting of that parameter in
>> the actual call. In a recent change, that parameter is not set to
>> something else, overriding the assignment above.
>
> Aha! Do you happen to know which change was responsible for that? Then
> I can
> adjust the bug summary accordingly.
>
"JDK-8201236 Straighten out dtrace build logic"
>> To fix this, you need to add $(BUILD_LIBJVM_EXTRA_FILES) to the
>> EXTRA_FILES line in CompileJvm.gmk.
>
> Indeed, this fixes it! Thanks so much, I was already about to give up ;).
>
We should have been explicit with that parameter in the first place,
then Magnus would not have missed it. Glad I could help.
/Erik
> Adrian
>
From glaubitz at physik.fu-berlin.de Tue Apr 10 18:14:07 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 10 Apr 2018 20:14:07 +0200
Subject: Zero fails to build on SPARC again, similar to JDK-8186578
In-Reply-To: <3ea4b91f-d693-0506-f3bc-3e0503c830d5@oracle.com>
References: <09c3fb5b-ab74-f478-c72d-538c7f8faaa8@physik.fu-berlin.de>
<2bacfb4d-b32f-4f9b-3f28-ec0067617986@physik.fu-berlin.de>
<94be4fc8-25dc-c54c-417b-dd69ee0b721f@oracle.com>
<64e6256a-c706-acf3-27c7-758dfeb54ea8@physik.fu-berlin.de>
<6e56596c-21bc-7e2f-c7e2-3ca1763162cd@physik.fu-berlin.de>
<19489bbb-6b34-2f8a-1296-2e7cb9a74d48@oracle.com>
<53bf36cd-f168-1805-20d7-9dbf99494834@physik.fu-berlin.de>
<9fede789-1f9a-a4e4-da4d-acdf8d40f91b@physik.fu-berlin.de>
<d4d05936-c1da-00d0-d0bf-eebf3bf1e866@oracle.com>
<83aa56f4-d44c-f793-c2e1-0b1f8a15f14c@physik.fu-berlin.de>
<3ea4b91f-d693-0506-f3bc-3e0503c830d5@oracle.com>
Message-ID: <b27394c9-465c-b074-c1ca-b15b76ce7824@physik.fu-berlin.de>
On 04/10/2018 08:04 PM, Erik Joelsson wrote:
> "JDK-8201236 Straighten out dtrace build logic"
Aye, changeset is coming up ;).
>> Indeed, this fixes it! Thanks so much, I was already about to give up ;).
>>
> We should have been explicit with that parameter in the first place, then Magnus would not have missed it. Glad I could help.
After that, I'll try to tackle the server build on linux-sparc again.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From bob.vandette at oracle.com Tue Apr 10 19:06:40 2018
From: bob.vandette at oracle.com (Bob Vandette)
Date: Tue, 10 Apr 2018 15:06:40 -0400
Subject: RFR (S) 8201372: aarch32 - 'minimal' build fails because CMS bits
are referred unconditionally
In-Reply-To: <e5f65fff-b80e-b16b-d091-0242a6de398b@bell-sw.com>
References: <e5f65fff-b80e-b16b-d091-0242a6de398b@bell-sw.com>
Message-ID: <90766D9B-1D0B-4EA1-9EBC-C3D018B728F6@oracle.com>
Thanks for keeping the minimal VM build alive!
Any chance you could fix the Linux x64/x86 minimal builds with this integration as well?
/export/users/bobv/jdk11hs/open/src/hotspot/share/c1/c1_LIRGenerator.cpp: In member function 'void LIRGenerator::CardTableBarrierSet_post_barrier(LIR_OprDesc*, LIR_OprDesc*)':
/export/users/bobv/jdk11hs/open/src/hotspot/share/c1/c1_LIRGenerator.cpp:1662:31: error: 'CMSPrecleaningEnabled' was not declared in this scope
if (UseConcMarkSweepGC && CMSPrecleaningEnabled) {
^
Bob Vandette
> On Apr 10, 2018, at 12:58 PM, Boris Ulasevich <boris.ulasevich at bell-sw.com> wrote:
>
> Hi all,
>
> Please review this patch to fix Minimal VM build fail caused by recent GC headers updating.
>
> https://bugs.openjdk.java.net/browse/JDK-8201372
> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8201372/webrev.00/
>
> Thanks,
> Boris
From glaubitz at physik.fu-berlin.de Tue Apr 10 19:39:48 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 10 Apr 2018 21:39:48 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <7f4d51d2-be2f-0984-946b-efa557a7ecc8@oracle.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
<6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
<7f4d51d2-be2f-0984-946b-efa557a7ecc8@oracle.com>
Message-ID: <b89bee8c-c885-dab7-7fb9-07a91d481b70@physik.fu-berlin.de>
On 04/09/2018 11:31 PM, David Holmes wrote:
> Looks like you will need compiler folk to jump in here. No idea why this would be linux-sparc specific, but would need to see exactly what was being compiled at the time the invalid code sequence was encountered.
>
> Sorry. This is what happens when code is no longer actively maintained.
Update: I just ran "hg update && hg update --clean", applied the following diff
which includes the suggested fix for 8201360 and the change suggested by
Zhengyu:
glaubitz at deb4g:/srv/glaubitz/hs$ hg diff
diff -r 00805b129186 make/hotspot/lib/CompileJvm.gmk
--- a/make/hotspot/lib/CompileJvm.gmk Tue Apr 10 11:43:40 2018 -0700
+++ b/make/hotspot/lib/CompileJvm.gmk Tue Apr 10 22:38:12 2018 +0300
@@ -219,7 +219,7 @@
TOOLCHAIN := TOOLCHAIN_LINK_CXX, \
OUTPUT_DIR := $(JVM_LIB_OUTPUTDIR), \
SRC := $(JVM_SRC_DIRS), \
- EXTRA_FILES := $(DTRACE_EXTRA_SOURCE_FILES), \
+ EXTRA_FILES := $(BUILD_LIBJVM_EXTRA_FILES) $(DTRACE_EXTRA_SOURCE_FILES), \
EXCLUDES := $(JVM_EXCLUDES), \
EXCLUDE_FILES := $(JVM_EXCLUDE_FILES), \
EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \
diff -r 00805b129186 src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp
--- a/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp Tue Apr 10 11:43:40 2018 -0700
+++ b/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp Tue Apr 10 22:38:12 2018 +0300
@@ -48,7 +48,7 @@
if (vstr != NULL) {
// We have a matching line and a valid starting point to the value of
// the field, copy the string for keeps.
- _string = strdup(vstr);
+ _string = os::strdup(vstr, mtInternal);
break;
}
}
and now the crash is different:
glaubitz at deb4g:/srv/glaubitz/hs$ ./build/linux-sparcv9-normal-server-fastdebug/jdk/bin/java --version
Error occurred during initialization of boot layer
java.lang.module.FindException: Error reading module: /srv/glaubitz/hs/build/linux-sparcv9-normal-server-fastdebug/jdk/modules/java.datatransfer
Caused by: java.lang.module.InvalidModuleDescriptorException: Illegal load factor: -1.2197928E-12
glaubitz at deb4g:/srv/glaubitz/hs$
What exactly is the load factor?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From stefan.karlsson at oracle.com Tue Apr 10 19:45:12 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 10 Apr 2018 21:45:12 +0200
Subject: RFR (S) 8201370: Minimal VM build fail
In-Reply-To: <ae347b5b-0d19-c9da-ff69-ed9f621643c2@bell-sw.com>
References: <ae347b5b-0d19-c9da-ff69-ed9f621643c2@bell-sw.com>
Message-ID: <41da233d-84d1-07a0-e9b1-e0fc76366836@oracle.com>
Hi Boris,
Thanks for fixing this!
For some reason I didn't bring those changes over from my original patch
to prototype conditional compilation of the GCs:
http://cr.openjdk.java.net/~stefank/8200729/prototype/webrev.01/
I've rebased that patch on my latest pushed changes and this should be a
much smaller patch:
http://cr.openjdk.java.net/~stefank/8200729/prototype/webrev.02/
I'll go through that patch and see if there is something else I've missed.
Regarding your patch, I think that you could push this and get rid of
the Minimal VM build breakage, but please also consider the comments below:
I see that you've added some includes to precompiled.hpp. This might be
fine if you want to solve the urgent build problem, but ultimately we
should be able to compile minimalvm with '--build-configure-args
--disable-precompiled-headers'. Adding headers to the precompiled.hpp
file should never be done to solve include dependency problem. If there
are missing includes those needs to be added to the files that uses the
code in the missing header files.
Thanks,
StefanK
On 2018-04-10 18:56, Boris Ulasevich wrote:
> Hi all,
>
> Please review this patch to fix Minimal VM build fail caused by recent
> GC headers updating.
>
> ?https://bugs.openjdk.java.net/browse/JDK-8201370
> ?http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8201370/webrev.00/
>
> I will post separate review on arm32-specific changes.
>
> Thanks,
> Boris
From erik.osterlund at oracle.com Tue Apr 10 19:59:36 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Tue, 10 Apr 2018 21:59:36 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <7e60b7a8-1806-18dd-e09f-d56ffac8a8a9@redhat.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<155309e7-e495-4ec7-7351-51e261ec7f1c@oracle.com>
<989c2ec0-ef6a-017b-d15a-85eacb0017e0@redhat.com>
<5d6c54ae-1e72-3ac2-9d56-dae81fa4de9e@oracle.com>
<7e60b7a8-1806-18dd-e09f-d56ffac8a8a9@redhat.com>
Message-ID: <5d82515c-74a9-e27a-52c5-5d26339abbe5@oracle.com>
Hi Aleksey,
On 2018-04-10 18:50, Aleksey Shipilev wrote:
> On 04/10/2018 05:59 PM, Robbin Ehn wrote:
>> On 2018-04-10 17:47, Aleksey Shipilev wrote:
>>> On 04/10/2018 05:25 PM, Robbin Ehn wrote:
>>>> Had quick look, what I saw looked good. (not a full review)
>>>> Is there a reason for moving the gc data to 'zero offset' in Thread?
>>> Oh! I missed that, and I fully agree with this move. At least one reason I see, smaller offsets
>>> against TLS open up opportunities for denser code-generation when e.g. GC barriers poll thread-local
>>> data. Right now SATB barrier generates something like "cmpb $0x0, 0x3d8(%r15)", while it could
>>> generate just "cmpb $0x0, 0x0(%r15)" now :)
>> Yes, but it pushes down e.g.:
>> 333?? volatile void* _polling_page;???????????????? // Thread local polling page
>> Which may not matter, as long as it's on the first page I suppose.
> I think the major concern should be the instruction size. On x86 what matters is what category
> immediate offset falls into. Some hand-crafted assembly:
>
> 0: 48 89 42 7f mov %rax,0x7f(%rdx)
> 4: 48 89 82 80 00 00 00 mov %rax,0x80(%rdx)
> b: 80 7a 7f 00 cmpb $0x0,0x7f(%rdx)
> f: 80 ba 80 00 00 00 00 cmpb $0x0,0x80(%rdx)
> 16: 80 7a 7f 41 cmpb $0x41,0x7f(%rdx)
> 1a: 80 ba 80 00 00 00 41 cmpb $0x41,0x80(%rdx)
> 21: f6 42 7f 00 testb $0x0,0x7f(%rdx)
> 25: f6 82 80 00 00 00 00 testb $0x0,0x80(%rdx)
> 2c: f6 42 7f 41 testb $0x41,0x7f(%rdx)
> 30: f6 82 80 00 00 00 41 testb $0x41,0x80(%rdx)
>
>
> In our case, we want to pack the most used fields under first 128 bytes. Maybe we should put polling
> page at offset 0, and trim GCTLD to 96 bytes?
Note that the offset will not be 0 due to the vtable. It will be 8 on 64
bit machines. I once prototyped a thread-local poll utilizing
conditional branches that truly used offset 0 to get optimal encoding (6
bytes for the test and shortened branch - same size as the old testl
$page encoding for global polling). I had to go down a deep rabbit hole
of exposing the TLS in r15 at an offset into the Thread, adjusting all
offsets for our generated code, and making the locking code deal with
owners being "almost" equal, as the owner is either Thread* or an
internal pointer into that thread, depending on what part of the locking
code was being used. After a lot of blood, sweat and tears, my
conclusion from that exercise was that it made absolutely no observable
difference. But I got the T-shirt anyway.
Thanks,
/Erik
> Thanks,
> -Aleksey
From christoph.langer at sap.com Tue Apr 10 20:01:04 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 10 Apr 2018 20:01:04 +0000
Subject: RFR (M): 8201247: Various cleanups in the attach framework
In-Reply-To: <1497c4c6-d95e-7e25-b503-cc7da9d6d077@oracle.com>
References: <14dff9b0cf5a4b888aef1d6452801b57@sap.com>
<91d75e2d-47a4-e9ee-5d19-8f3e6dc13428@oracle.com>
<a3248ff5584e4186acc8a3baec06ab4b@sap.com>
<1497c4c6-d95e-7e25-b503-cc7da9d6d077@oracle.com>
Message-ID: <1e441d12b6ca421f8b6774562c8e30b9@sap.com>
Hi Chris,
I ran the jtreg tests under hotspot/jtreg/serviceability/attach and jdk/com/sun/tools/attach for the main platforms (Windows, Linux X86_64, mac, solaris and AIX).
I also pushed to submit-hs in branch "JDK-8201247" but it seems I have no luck and got no notification mails. May I ask you to check whether the build/test cycle was run and how the results looked like?
Please also do your closed testing and let me know the outcome.
Thanks a lot in advance
Christoph
> -----Original Message-----
> From: Chris Plummer [mailto:chris.plummer at oracle.com]
> Sent: Montag, 9. April 2018 20:05
> To: Langer, Christoph <christoph.langer at sap.com>; serviceability-
> dev at openjdk.java.net
> Cc: hotspot-dev at openjdk.java.net
> Subject: Re: RFR (M): 8201247: Various cleanups in the attach framework
>
> Hi Christoph,
>
> We have some closed "attach on demand" tests that should be run also. I
> can do this for you when you are ready. Please also let me know which
> other jtreg tests you have run.
>
> thanks,
>
> Chris
>
> On 4/9/18 12:08 AM, Langer, Christoph wrote:
> > Hi Chris,
> >
> > thanks for looking into this.
> >
> > As for ArgumentIterator::next, I must admit, I found this patch in our code
> base when taking over the code. I believe that an issue would be seen if an
> attach operation has 2 or 3 arguments and the first one is NULL/empty. I
> guess such a situation can't happen with the attach operations currently
> existing in OpenJDK as none of these ops would allow such type of
> arguments. However, in our implementation, we have for instance enhanced
> the "dump_heap" operation to work with null as first argument where one
> usually would specify the desired output file name. We implemented a
> mechanism to compute a default filename when the param is left blank. So
> we need the fix for that case, I guess.
> >
> > I'll run the patch through the submission forest now and do some jtreg
> testing.
> >
> > Best regards
> > Christoph
> >
> >> -----Original Message-----
> >> From: Chris Plummer [mailto:chris.plummer at oracle.com]
> >> Sent: Freitag, 6. April 2018 18:37
> >> To: Langer, Christoph <christoph.langer at sap.com>; serviceability-
> >> dev at openjdk.java.net
> >> Cc: hotspot-dev at openjdk.java.net
> >> Subject: Re: RFR (M): 8201247: Various cleanups in the attach framework
> >>
> >> Hi Christoph,
> >>
> >> Can you explain a bit more about "fix handling of null values in
> >> ArgumentIterator::next". When does this turn up? Is there a test case?
> >>
> >> Everything else looks good.
> >>
> >> thanks,
> >>
> >> Chris
> >>
> >> On 4/6/18 8:01 AM, Langer, Christoph wrote:
> >>> Hi,
> >>>
> >>> can I please get reviews for a set of clean up changes that I came
> >>> across when doing some integration work.
> >>>
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201247
> >>> <https://bugs.openjdk.java.net/browse/JDK-8201247>
> >>>
> >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/
> >>> <http://cr.openjdk.java.net/%7Eclanger/webrevs/8201247.0/>
> >>>
> >>> Detailed comments about the changes can be found in the bug.
> >>>
> >>> Thanks & best regards
> >>>
> >>> Christoph
> >>>
From chris.plummer at oracle.com Tue Apr 10 20:08:04 2018
From: chris.plummer at oracle.com (Chris Plummer)
Date: Tue, 10 Apr 2018 13:08:04 -0700
Subject: RFR (M): 8201247: Various cleanups in the attach framework
In-Reply-To: <1e441d12b6ca421f8b6774562c8e30b9@sap.com>
References: <14dff9b0cf5a4b888aef1d6452801b57@sap.com>
<91d75e2d-47a4-e9ee-5d19-8f3e6dc13428@oracle.com>
<a3248ff5584e4186acc8a3baec06ab4b@sap.com>
<1497c4c6-d95e-7e25-b503-cc7da9d6d077@oracle.com>
<1e441d12b6ca421f8b6774562c8e30b9@sap.com>
Message-ID: <630dcc82-81c3-f09f-76db-da4ff7d03363@oracle.com>
Hi Christoph,
I'm somewhat new to looking at submit-hs test jobs. However I see know
indication of there being a submit for JDK-8201247, so I don't think it
was run. I'll start my own testing with the last patch you sent out.
thanks,
Chris
On 4/10/18 1:01 PM, Langer, Christoph wrote:
> Hi Chris,
>
> I ran the jtreg tests under hotspot/jtreg/serviceability/attach and jdk/com/sun/tools/attach for the main platforms (Windows, Linux X86_64, mac, solaris and AIX).
>
> I also pushed to submit-hs in branch "JDK-8201247" but it seems I have no luck and got no notification mails. May I ask you to check whether the build/test cycle was run and how the results looked like?
>
> Please also do your closed testing and let me know the outcome.
>
> Thanks a lot in advance
> Christoph
>
>> -----Original Message-----
>> From: Chris Plummer [mailto:chris.plummer at oracle.com]
>> Sent: Montag, 9. April 2018 20:05
>> To: Langer, Christoph <christoph.langer at sap.com>; serviceability-
>> dev at openjdk.java.net
>> Cc: hotspot-dev at openjdk.java.net
>> Subject: Re: RFR (M): 8201247: Various cleanups in the attach framework
>>
>> Hi Christoph,
>>
>> We have some closed "attach on demand" tests that should be run also. I
>> can do this for you when you are ready. Please also let me know which
>> other jtreg tests you have run.
>>
>> thanks,
>>
>> Chris
>>
>> On 4/9/18 12:08 AM, Langer, Christoph wrote:
>>> Hi Chris,
>>>
>>> thanks for looking into this.
>>>
>>> As for ArgumentIterator::next, I must admit, I found this patch in our code
>> base when taking over the code. I believe that an issue would be seen if an
>> attach operation has 2 or 3 arguments and the first one is NULL/empty. I
>> guess such a situation can't happen with the attach operations currently
>> existing in OpenJDK as none of these ops would allow such type of
>> arguments. However, in our implementation, we have for instance enhanced
>> the "dump_heap" operation to work with null as first argument where one
>> usually would specify the desired output file name. We implemented a
>> mechanism to compute a default filename when the param is left blank. So
>> we need the fix for that case, I guess.
>>> I'll run the patch through the submission forest now and do some jtreg
>> testing.
>>> Best regards
>>> Christoph
>>>
>>>> -----Original Message-----
>>>> From: Chris Plummer [mailto:chris.plummer at oracle.com]
>>>> Sent: Freitag, 6. April 2018 18:37
>>>> To: Langer, Christoph <christoph.langer at sap.com>; serviceability-
>>>> dev at openjdk.java.net
>>>> Cc: hotspot-dev at openjdk.java.net
>>>> Subject: Re: RFR (M): 8201247: Various cleanups in the attach framework
>>>>
>>>> Hi Christoph,
>>>>
>>>> Can you explain a bit more about "fix handling of null values in
>>>> ArgumentIterator::next". When does this turn up? Is there a test case?
>>>>
>>>> Everything else looks good.
>>>>
>>>> thanks,
>>>>
>>>> Chris
>>>>
>>>> On 4/6/18 8:01 AM, Langer, Christoph wrote:
>>>>> Hi,
>>>>>
>>>>> can I please get reviews for a set of clean up changes that I came
>>>>> across when doing some integration work.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201247
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8201247>
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/
>>>>> <http://cr.openjdk.java.net/%7Eclanger/webrevs/8201247.0/>
>>>>>
>>>>> Detailed comments about the changes can be found in the bug.
>>>>>
>>>>> Thanks & best regards
>>>>>
>>>>> Christoph
>>>>>
From shade at redhat.com Tue Apr 10 20:25:13 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 10 Apr 2018 22:25:13 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <5d82515c-74a9-e27a-52c5-5d26339abbe5@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<155309e7-e495-4ec7-7351-51e261ec7f1c@oracle.com>
<989c2ec0-ef6a-017b-d15a-85eacb0017e0@redhat.com>
<5d6c54ae-1e72-3ac2-9d56-dae81fa4de9e@oracle.com>
<7e60b7a8-1806-18dd-e09f-d56ffac8a8a9@redhat.com>
<5d82515c-74a9-e27a-52c5-5d26339abbe5@oracle.com>
Message-ID: <44909a54-884d-a551-f23b-a6ff76f4bf66@redhat.com>
Hi Erik
On 04/10/2018 09:59 PM, Erik ?sterlund wrote:
>> I think the major concern should be the instruction size. On x86 what matters is what category
>> immediate offset falls into. Some hand-crafted assembly:
>>
>> ??? 0:??? 48 89 42 7f????????????? mov??? %rax,0x7f(%rdx)
>> ??? 4:??? 48 89 82 80 00 00 00???? mov??? %rax,0x80(%rdx)
>> ??? b:??? 80 7a 7f 00????????????? cmpb?? $0x0,0x7f(%rdx)
>> ??? f:??? 80 ba 80 00 00 00 00???? cmpb?? $0x0,0x80(%rdx)
>> ?? 16:??? 80 7a 7f 41????????????? cmpb?? $0x41,0x7f(%rdx)
>> ?? 1a:??? 80 ba 80 00 00 00 41???? cmpb?? $0x41,0x80(%rdx)
>> ?? 21:??? f6 42 7f 00????????????? testb? $0x0,0x7f(%rdx)
>> ?? 25:??? f6 82 80 00 00 00 00???? testb? $0x0,0x80(%rdx)
>> ?? 2c:??? f6 42 7f 41????????????? testb? $0x41,0x7f(%rdx)
>> ?? 30:??? f6 82 80 00 00 00 41???? testb? $0x41,0x80(%rdx)
>>
>>
>> In our case, we want to pack the most used fields under first 128 bytes. Maybe we should put polling
>> page at offset 0, and trim GCTLD to 96 bytes?
>
> Note that the offset will not be 0 due to the vtable. It will be 8 on 64 bit machines.
True! Regardless, I'll take 0x8(%r15) over 0x888(%r15) any day :)
> I once prototyped a thread-local poll utilizing conditional branches that truly used offset 0 to
> get optimal encoding (6 bytes for the test and shortened branch - same size as the old testl
> $page encoding for global polling). I had to go down a deep rabbit hole of exposing the TLS in
> r15 at an offset into the Thread, adjusting all offsets for our generated code, and making the
> locking code deal with owners being "almost" equal, as the owner is either Thread* or an internal
> pointer into that thread, depending on what part of the locking code was being used. After a lot
> of blood, sweat and tears, my conclusion from that exercise was that it made absolutely no
> observable difference. But I got the T-shirt anyway.
Cool. For safepoint polls, I would understand if it turned out performance-neutral. I also know from
Shenandoah that even the tiny codegen improvements for GC barriers (that are much more frequent than
safepoint polls even after optimizations) do pay off. Trying to fit the hottest JavaThread fields
below 128 bytes seems much easier to do than pulling off the real-0 thing.
The implication for this patch is that we should probably trim the GCTLD size below 128 bytes (from
Per's initial suggestion of 192), and reserve some some space for e.g. polling page (if we want to
move it to lower offset), and account for vtable waste. And then make a stronger comment about
making GCTLD larger than 128 bytes for the future engineers.
I suggest 96 bytes. G1 does not need this much anyhow. Shenandoah does not need this much as well.
ZGC does not need this much too, right?
Thanks,
-Aleksey
From david.holmes at oracle.com Tue Apr 10 21:45:57 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Apr 2018 07:45:57 +1000
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <b89bee8c-c885-dab7-7fb9-07a91d481b70@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
<6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
<7f4d51d2-be2f-0984-946b-efa557a7ecc8@oracle.com>
<b89bee8c-c885-dab7-7fb9-07a91d481b70@physik.fu-berlin.de>
Message-ID: <a4eb0183-d9b9-35d8-c7c6-9c2e132a3264@oracle.com>
On 11/04/2018 5:39 AM, John Paul Adrian Glaubitz wrote:
> On 04/09/2018 11:31 PM, David Holmes wrote:
>> Looks like you will need compiler folk to jump in here. No idea why
>> this would be linux-sparc specific, but would need to see exactly what
>> was being compiled at the time the invalid code sequence was encountered.
>>
>> Sorry. This is what happens when code is no longer actively maintained.
> Update: I just ran "hg update && hg update --clean", applied the
> following diff
> which includes the suggested fix for 8201360 and the change suggested by
> Zhengyu:
>
> glaubitz at deb4g:/srv/glaubitz/hs$ hg diff
> diff -r 00805b129186 make/hotspot/lib/CompileJvm.gmk
> --- a/make/hotspot/lib/CompileJvm.gmk?? Tue Apr 10 11:43:40 2018 -0700
> +++ b/make/hotspot/lib/CompileJvm.gmk?? Tue Apr 10 22:38:12 2018 +0300
> @@ -219,7 +219,7 @@
> ???? TOOLCHAIN := TOOLCHAIN_LINK_CXX, \
> ???? OUTPUT_DIR := $(JVM_LIB_OUTPUTDIR), \
> ???? SRC := $(JVM_SRC_DIRS), \
> -??? EXTRA_FILES := $(DTRACE_EXTRA_SOURCE_FILES), \
> +??? EXTRA_FILES := $(BUILD_LIBJVM_EXTRA_FILES)
> $(DTRACE_EXTRA_SOURCE_FILES), \
> ???? EXCLUDES := $(JVM_EXCLUDES), \
> ???? EXCLUDE_FILES := $(JVM_EXCLUDE_FILES), \
> ???? EXCLUDE_PATTERNS := $(JVM_EXCLUDE_PATTERNS), \
> diff -r 00805b129186
> src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp
> --- a/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp Tue Apr
> 10 11:43:40 2018 -0700
> +++ b/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp Tue Apr
> 10 22:38:12 2018 +0300
> @@ -48,7 +48,7 @@
> ???????? if (vstr != NULL) {
> ?????????? // We have a matching line and a valid starting point to the
> value of
> ?????????? // the field, copy the string for keeps.
> -????????? _string = strdup(vstr);
> +????????? _string = os::strdup(vstr, mtInternal);
> ?????????? break;
> ???????? }
> ?????? }
>
> and now the crash is different:
>
> glaubitz at deb4g:/srv/glaubitz/hs$
> ./build/linux-sparcv9-normal-server-fastdebug/jdk/bin/java --version
> Error occurred during initialization of boot layer
> java.lang.module.FindException: Error reading module:
> /srv/glaubitz/hs/build/linux-sparcv9-normal-server-fastdebug/jdk/modules/java.datatransfer
>
> Caused by: java.lang.module.InvalidModuleDescriptorException: Illegal
> load factor: -1.2197928E-12
> glaubitz at deb4g:/srv/glaubitz/hs$
>
> What exactly is the load factor?
The only reference to that message I can find is from HashMap/HashSet
where the load factor defines how full the collection becomes before it
resizes. I would have to guess some kind of floating-point issue here -
a very small number rather than 0 perhaps?
David
>
> Adrian
>
From david.holmes at oracle.com Tue Apr 10 21:58:58 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Apr 2018 07:58:58 +1000
Subject: RFR (S) 8201370: Minimal VM build fail
In-Reply-To: <41da233d-84d1-07a0-e9b1-e0fc76366836@oracle.com>
References: <ae347b5b-0d19-c9da-ff69-ed9f621643c2@bell-sw.com>
<41da233d-84d1-07a0-e9b1-e0fc76366836@oracle.com>
Message-ID: <a3cc4257-ac51-2eca-1695-07b4266786b1@oracle.com>
Hi Stefan,
On 11/04/2018 5:45 AM, Stefan Karlsson wrote:
> Hi Boris,
>
> Thanks for fixing this!
>
> For some reason I didn't bring those changes over from my original patch
> to prototype conditional compilation of the GCs:
> http://cr.openjdk.java.net/~stefank/8200729/prototype/webrev.01/
>
> I've rebased that patch on my latest pushed changes and this should be a
> much smaller patch:
> http://cr.openjdk.java.net/~stefank/8200729/prototype/webrev.02/
>
> I'll go through that patch and see if there is something else I've missed.
>
> Regarding your patch, I think that you could push this and get rid of
> the Minimal VM build breakage, but please also consider the comments below:
>
> I see that you've added some includes to precompiled.hpp. This might be
They weren't added, they were moved from being unconditional into the
INCLUDE_ALL_GCS section.
David
-----
> fine if you want to solve the urgent build problem, but ultimately we
> should be able to compile minimalvm with '--build-configure-args
> --disable-precompiled-headers'. Adding headers to the precompiled.hpp
> file should never be done to solve include dependency problem. If there
> are missing includes those needs to be added to the files that uses the
> code in the missing header files.
>
> Thanks,
> StefanK
>
> On 2018-04-10 18:56, Boris Ulasevich wrote:
>> Hi all,
>>
>> Please review this patch to fix Minimal VM build fail caused by recent
>> GC headers updating.
>>
>> ?https://bugs.openjdk.java.net/browse/JDK-8201370
>> ?http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8201370/webrev.00/
>>
>> I will post separate review on arm32-specific changes.
>>
>> Thanks,
>> Boris
>
>
From david.holmes at oracle.com Tue Apr 10 21:59:44 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Apr 2018 07:59:44 +1000
Subject: RFR (S) 8201370: Minimal VM build fail
In-Reply-To: <ae347b5b-0d19-c9da-ff69-ed9f621643c2@bell-sw.com>
References: <ae347b5b-0d19-c9da-ff69-ed9f621643c2@bell-sw.com>
Message-ID: <a3bd3eaa-5fd8-e440-3eb1-faa17ef4dfca@oracle.com>
Hi Boris,
This seems fine to me.
Thanks,
David
On 11/04/2018 2:56 AM, Boris Ulasevich wrote:
> Hi all,
>
> Please review this patch to fix Minimal VM build fail caused by recent
> GC headers updating.
>
> ?https://bugs.openjdk.java.net/browse/JDK-8201370
> ?http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8201370/webrev.00/
>
> I will post separate review on arm32-specific changes.
>
> Thanks,
> Boris
From david.holmes at oracle.com Tue Apr 10 22:03:27 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Apr 2018 08:03:27 +1000
Subject: RFR (S) 8201372: aarch32 - 'minimal' build fails because CMS bits
are referred unconditionally
In-Reply-To: <e5f65fff-b80e-b16b-d091-0242a6de398b@bell-sw.com>
References: <e5f65fff-b80e-b16b-d091-0242a6de398b@bell-sw.com>
Message-ID: <963def9b-085f-6e01-50ae-420882a02914@oracle.com>
Hi Boris,
This seems fine to me. Reviewed.
Thanks,
David
On 11/04/2018 2:58 AM, Boris Ulasevich wrote:
> Hi all,
>
> Please review this patch to fix Minimal VM build fail caused by recent
> GC headers updating.
>
> ?https://bugs.openjdk.java.net/browse/JDK-8201372
> ?http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8201372/webrev.00/
>
> Thanks,
> Boris
From jcbeyler at google.com Tue Apr 10 22:24:12 2018
From: jcbeyler at google.com (JC Beyler)
Date: Tue, 10 Apr 2018 22:24:12 +0000
Subject: JEP 331: Low-Overhead Heap Profiling
In-Reply-To: <87765ba4-2952-d654-3b38-c4fd91d85239@oracle.com>
References: <20180329171223.64A4C1973B3@eggemoggin.niobe.net>
<cfb1b563-2702-a0b8-b122-da0e46b3b26f@redhat.com>
<CAF9BGBz_167RNNsHVEzs1Q-eiyih5mzB3BrTt0_Vu67SQUuwVg@mail.gmail.com>
<19dc905f-dbdd-ac8d-6092-1fe26e56cb24@redhat.com>
<CAF9BGByMimzf94oZJ7S1Xxw8-yOc7yuHP-+xnESFrhGXK5ReZQ@mail.gmail.com>
<19755e74-61bb-cc70-c1c1-c373dbdda822@oracle.com>
<CAF9BGBxSt4GNYxb8+BsozDjbbKdSEaTE1nEJaXmv5NGyF0rRHw@mail.gmail.com>
<87765ba4-2952-d654-3b38-c4fd91d85239@oracle.com>
Message-ID: <CAF9BGBwxviLZ3HmWKjM21BobsuxwG97+a98jGmqDZPYb1GVcKQ@mail.gmail.com>
Hi all,
Just wanted to come back to one point that was not answered. Aleksey, did
my change to the JEP text with the implementation details answer your
questions/concerns?
Are there any other question/concerns from other people on the mailing list?
Thanks!
Jc
On Thu, Apr 5, 2018 at 3:10 PM serguei.spitsyn at oracle.com <
serguei.spitsyn at oracle.com> wrote:
> Hi Jc,
>
> Ok, thanks!
> Serguei
>
>
> On 4/5/18 15:04, JC Beyler wrote:
>
> Added your comments to the text Serguei and changed the name of the
> section to JVMTI agent.
>
> Thanks!
> Jc
>
> On Thu, Apr 5, 2018 at 2:07 PM serguei.spitsyn at oracle.com <
> serguei.spitsyn at oracle.com> wrote:
>
>> Hi Jc and Aleksey,
>>
>> Please, find a couple of comments below.
>>
>>
>> On 4/5/18 09:05, JC Beyler wrote:
>> > Hi Aleksey,
>> >
>> > I inlined my answers :)
>> >
>> > On Thu, Apr 5, 2018 at 4:09 AM Aleksey Shipilev <shade at redhat.com>
>> wrote:
>> >
>> >> On 04/05/2018 12:23 AM, JC Beyler wrote:
>> >>> On Wed, Apr 4, 2018 at 3:41 AM Aleksey Shipilev <shade at redhat.com
>> >> <mailto:shade at redhat.com>> wrote:
>> >>> *) It would be nice to mention the implementation details in the JEP
>> >> itself, i.e. where are the
>> >>> points it injects into GCs to sample? I assume it has to inject
>> into
>> >> CollectedHeap::allocate_tlab,
>> >>> and it has to cap the max TLAB sizes to get into allocation
>> slowpath
>> >> often enough?
>> >>> My understanding was that a JEP was the idea and specification and
>> that
>> >> more technical information
>> >>> like that was out of scope for the JEP (implementations can change,
>> etc.)
>> >> Well, yes. But if you have the implementation ideas, it is better to
>> >> demonstrate them along with the
>> >> idea. Discussing implementation approaches serves several purposes: a)
>> it
>> >> empirically proves the
>> >> idea is implementable; b) it highlights tricky design decisions the
>> >> implementation has to force,
>> >> which aids the understanding of the scope; c) it prevents handwaving
>> >> against existing approaches :)
>> >>
>> > Fair enough, I've added an implementation design/state with a link to
>> the
>> > current webrev at the end of the JEP issue
>> > <https://bugs.openjdk.java.net/browse/JDK-8171119>. Let me know if
>> that is
>> > what you had in mind.
>> >
>> >
>> >>> It actually does not cap the max TLAB sizes, it changes the end
>> pointer
>> >> to force paths into
>> >>> "thinking" the tlab is full; then in the slowpath it samples and fixes
>> >> things the pointers up for
>> >>> the next sample.
>> >> Ooof. So this has implications for JEP scope, and thus should be
>> mentioned.
>> >>
>> > Perhaps, again I saw the JEP as a different level of abstraction and
>> this
>> > is more in the details of implementation. However, I have added a full
>> > explanation of this into the JEP at the end, let me know if it makes
>> sense.
>> > For convenience, let me copy-paste what I wrote there:
>> >
>> > "
>> > 2) The TLAB structure is augmented with a new allocation_end pointer
>> and a
>> > current_end pointer. If the sampling is disabled, the two pointers are
>> > always equal and the code performs as before. If the sampling is
>> enabled,
>> > the current_end is modified to be where the next sample point is
>> requested.
>> > Then, any fast path will "think" the TLAB is full at that point and go
>> down
>> > the slow path, which is explained in (3)
>> > "
>> >
>> >
>> >>
>> >>> *) Since JC apparently has the prototype, it would be easier to
>> put
>> >> it somewhere, and link it into
>> >>> the JEP itself. Webrevs are interesting, but they get outdated
>> >> pretty quickly, so maybe putting the
>> >>> whole thing in JDK Sandbox [1] is the way to go.
>> >>>
>> >>> I've been keeping the webrevs up to date so there should be no real
>> >> problem. From what I read, you
>> >>> have to be a commiter for the JDK Sandbox, no? So I'm not sure that
>> >> would make sense there?
>> >>
>> >> Right, you have to be a Committer. Link the webrev to the JEP then?
>> >>
>> > I added the link and a few paragraphs on the implementation.
>> >
>> >
>> >>
>> >>> *) Motivation says: "The downsides [of JFR] are that a) it is
>> tied
>> >> to a particular allocation
>> >>> implementation (TLABs), and misses allocations that don?t meet
>> that
>> >> pattern; b) it doesn?t allow the
>> >>> user to customize the sampling rate; c) it only logs
>> allocations, so
>> >> you cannot distinguish between
>> >>> live and dead objects."
>> >>>
>> >>> ...but then JEP apparently describes sampling the allocations
>> via
>> >> TLABs? So, the real difference is
>> >>> (b), allowing to customize the sampling rate, or do I miss
>> something?
>> >>>
>> >>> There are various differences between the JFR tlab events and this
>> >> system. First the JFR system
>> >>> provides a buffer event system, meaning you can miss samples if the
>> >> event buffer is full and threw
>> >>> out a sampling event before a reader got to it. Second, you don't get
>> a
>> >> callback at the allocation
>> >>> spot, so you cannot have a means to do an action at that sampling
>> point,
>> >> which means you have no way
>> >>> of knowing when an object is effectively dead using the JFR events.
>> >> Hopefully that makes sense?
>> >>
>> >> This paragraph should be in JEP text then?
>> >>
>> > Done, I revamped and edited the section into this now:
>> >
>> >
>> > "There are multiple alternatives to the system presented in this JEP.
>> The
>> > introduction presented two already: The Java Flight Recorder
>> > <http://openjdk.java.net/jeps/328> system provides an interesting
>> > alternative but is not perfect due to it not allowing the sampling size
>> to
>> > be set and not providing a callback.
>> >
>> > The JFR system does use the TLAB creation as a means to track memory
>> > allocation but, instead of a callback, JFR events use a buffer system
>> that
>> > can lead to missing some sampled allocations. Finally, the JFR event
>> system
>> > does not provide a means to track objects that have been garbage
>> collected,
>> > which means it is not possible currently to have a system provide
>> > information about live and garbage collected objects using the JFR event
>> > system."
>>
>> I'd like to highlight an important difference with the JFR.
>> The JEP adds new feature into the JVMTI which is an important
>> API/framework for various development and monitoring tools.
>> Now, a JVMTI agent can use a low overhead heap profiling API along with
>> the rest of JVMTI functionality.
>> It provides great flexibility to the tools.
>> For instance, it is up to the agent to decide if a stack trace needs to
>> be collected at each event point.
>>
>>
>> > Let me know if that works for you.
>> >
>> >
>> >
>> >>> *) Goals say: "Can give information about both live and dead Java
>> >> objects."
>> >>> ...but there is not discussion what/how does it give information
>> >> about the dead Java objects. I am
>> >>> struggling to imagine how allocation sampling would give this. Is
>> >> the goal too broad, or some API is
>> >>> not described in the JEP?
>> >>>
>> >>> Originally the JEP provided a means to the user to get that
>> information
>> >> directly. Now because the
>> >>> sampling callback provides an oop, the user in the agent can add a
>> weak
>> >> reference and use that to
>> >>> determine liveness.
>> >
>> >> Ooof! I guess that technically works. Please mention it.
>> >>
>> > I did already add it here:
>> >
>> >
>> > "E) What the Java agent can do
>>
>> I'd suggest to replace the "Java agent" with the "JVMTI agent" for
>> accuracy.
>> The term "Java agent" is used for JPLIS agents that are based on the
>> java.lang.instrument API:
>>
>> https://docs.oracle.com/javase/8/docs/technotes/guides/instrumentation/index.html
>>
>>
>> Thanks,
>> Serguei
>>
>> > The user of the callback can then pick up a stacktrace at the moment of
>> the
>> > callback using the JVMTI GetStackTrace method for example. The oop
>> obtained
>> > by the callback can be also wrapped into a JNI weak reference to help
>> > determine when the object has been garbage collected. The idea behind
>> that
>> > is to provide data on what objects were sampled and are still considered
>> > live or garbage collected, which can be a good means to understand the
>> > job's behavior.
>> >
>> > The sampling rate will provide a different sampling precision but also
>> can
>> > be a means to mitigate overhead due to the profiling. Using a sampling
>> rate
>> > of 512k and the sampling solution, the overhead should be low enough
>> that a
>> > user could reasonably leave the system on by default."
>> >
>> >
>> > ------
>> >
>> >
>> > I also have the proof of concept in tests here
>> > <
>> http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.10/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorGCTest.java.html
>> >
>> > and
>> > the native implementation is here
>> > <
>> http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.10/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/libHeapMonitorTest.c.html
>> >
>> > .
>> >
>> > Let me know if my additions to the JEP are what you were looking for
>> and is
>> > there anything else you think I should add information about!
>> >
>> > Thanks for reviewing it!
>> > Jc
>>
>>
>
From coleen.phillimore at oracle.com Tue Apr 10 22:29:56 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 10 Apr 2018 18:29:56 -0400
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <31e3f7cc-7df2-5bfe-cb56-9d7064d12fd7@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<da8fea92-e08e-5801-544b-1e4b6200d6b2@oracle.com>
<31e3f7cc-7df2-5bfe-cb56-9d7064d12fd7@oracle.com>
Message-ID: <73b2616b-f803-ba3c-7dc5-b451af2ed70b@oracle.com>
On 4/10/18 10:42 AM, Robbin Ehn wrote:
> Hi Erik,
>
> On 04/10/2018 02:45 PM, Erik ?sterlund wrote:
>> Hi Robbin,
>>
>> The local counter loaded in critical_section_begin/end should not be
>> volatile (the compiler will produce unnecessarily crappy code).
>
> Thanks, fixed!
>
>>
>> globalCounter.hpp lacks a few includes:
>> memory/allocation.hpp and memory/padded.hpp.
>
> Thanks, fixed!
I was going to point this out as my only comment, except you can forward
declare Thread rather than including thread.hpp.
The rest of the change looks good to me.
thanks!
Coleen
>
>>
>> Otherwise it looks good to me. I note that the lack of
>> release_store_fence() in critical_section_end() means that stores and
>> loads can float up into the critical section. I'm assuming that is
>> fine in the envisioned use cases, as long as accesses do not float
>> out from the critical section.
>
> Yes, you are correct, added a comment.
>
> Full: http://cr.openjdk.java.net/~rehn/8195099/v2/webrev/
> Inc : http://cr.openjdk.java.net/~rehn/8195099/v2/inc/webrev/
>
> Thanks, Robbin
>
>>
>> Thanks,
>> /Erik
>>
>> On 2018-04-10 14:18, Robbin Ehn wrote:
>>> Hi all,
>>>
>>> We have moved the global-counter to a separate change-set. The
>>> global-counter
>>> uses a counter to determine current generation. Any reader needs to
>>> have a local
>>> counter for which generation is currently read. By increment the
>>> global-counter
>>> and scan for threads reading an old generation and wait for them to
>>> complete, we
>>> know when an old generation is not visible (no pre-existing reader).
>>> In RCU
>>> terms, this creates a grace-period. Making this mechanism suitable
>>> for a read-mostly scenario. In this initial change-set we scan
>>> JavaThreads and the VMThread.
>>>
>>> A couple of enhancement to the global-counter will be looked into:
>>> - Quiescent state RCU semantic by using the natural state of
>>> JavaThreads in the VM.
>>> - Asynchronous write synchronize, where reclamation, if there are
>>> per-existing
>>> reader, is done by the last reader leaving that generation.
>>> - Register/deregister threads.
>>>
>>> The current usage is the upcoming hash-table which uses the
>>> global-counter to reclaim memory and to concurrently grow. We have
>>> also potential use-cases in
>>> other work-in-progress code.
>>>
>>> The new gtest passes on our platforms. For now you can look at the
>>> gtest if you think you have a use-case for this as an example.
>>>
>>> Code: http://cr.openjdk.java.net/~rehn/8195099/v1/webrev/
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8195099
>>>
>>> Thanks, Robbin
>>
From coleen.phillimore at oracle.com Tue Apr 10 22:40:36 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 10 Apr 2018 18:40:36 -0400
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <F5A643B9-CBD4-416C-B200-205363665719@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<da8fea92-e08e-5801-544b-1e4b6200d6b2@oracle.com>
<31e3f7cc-7df2-5bfe-cb56-9d7064d12fd7@oracle.com>
<F5A643B9-CBD4-416C-B200-205363665719@oracle.com>
Message-ID: <48a88461-71a9-d652-58bd-8ce6712e4ef2@oracle.com>
On 4/10/18 11:53 AM, Kim Barrett wrote:
>> On Apr 10, 2018, at 10:42 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>>
>> Full: http://cr.openjdk.java.net/~rehn/8195099/v2/webrev/
>> Inc : http://cr.openjdk.java.net/~rehn/8195099/v2/inc/webrev/
> ------------------------------------------------------------------------------
>
> GlobalCounter describes its implementation, but is not the least bit
> evocative of its purpose. I don't have a good name suggestion though.
I like the name because it's simple, unique in the vm, and there isn't a
better name that comes to mind. GlobalCounter<MutualExclusion> ?? I
think we should keep this as is until we find a better name, which might
take a while.
>
> ------------------------------------------------------------------------------
>
> This is being put in utilities. Similarly we put SpinYield in
> utilities. But I'm not sure either of those are properly placed
> there. These are synchronization building blocks, and all other
> synchronization stuff is in runtime.
The intended use is for a concurrent hashtable in utilities that will be
used by the StringTable (in classfile directory), so that's why
utilities seems a good choice (esp given SpinYield there).? I think it
would get confused with synchronizer.cpp (for Java level locks) if it
were in runtime.
>
> ------------------------------------------------------------------------------
> src/hotspot/share/utilities/globalCounter.hpp
>
> Consider just forward declaring Thread (at namespace scope).
>
> Consider just forward declaring CounterThreadCheck at class scope,
> with the definition in the .cpp file.
>
> With those changes, don't need to #include thread.hpp in this header.
> Although globalCounter.inline.hpp still needs to #include thread.hpp,
> so maybe this doesn't matter so much?
I had this comment too.
Coleen
> ------------------------------------------------------------------------------
> src/hotspot/share/utilities/globalCounter.hpp
>
> Although CriticalSection is fully defined in this header, I think it
> can't be instantiated without including globalCounter.inline.hpp.
> Consider just forward declaring in the GlobalCounter definition, with
> the definition in the .inline.hpp.
>
> ------------------------------------------------------------------------------
> src/hotspot/share/utilities/globalCounter.inline.hpp
>
> Missing #include globalCounter.hpp.
>
> ------------------------------------------------------------------------------
> src/hotspot/share/utilities/globalCounter.inline.hpp
> 36 OrderAccess::release_store_fence(thread->get_rcu_counter(), gbl_cnt + 1);
>
> "gbl_cnt + 1" => "gbl_cnt | COUNTER_ACTIVE".
>
> ------------------------------------------------------------------------------
> src/hotspot/share/utilities/globalCounter.hpp
>
> 74 // Must be called after finished accessing the data.
> 75 // Do not provide fence, allows load/stores moving into the critical section.
> 76 static void critical_section_end(Thread *thread);
>
> Both begin and end should have descriptions of their ordering
> behavior. I'm thinking something similar to the descriptions we have
> for Atomic operations.
>
> ------------------------------------------------------------------------------
>
From coleen.phillimore at oracle.com Tue Apr 10 22:49:00 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 10 Apr 2018 18:49:00 -0400
Subject: RFR: 8199417: Modularize interpreter GC barriers
In-Reply-To: <b6cdaf49-4715-7193-51ff-c3c19581d497@oracle.com>
References: <5AB8BDF9.4050106@oracle.com>
<3FFD79AD-84B8-4E9E-98E3-47ACBA01D91F@oracle.com>
<5AC4D555.9040800@oracle.com>
<80295FD9-254E-4670-AB47-E2A4B36C4143@oracle.com>
<b6cdaf49-4715-7193-51ff-c3c19581d497@oracle.com>
Message-ID: <3a0f68a9-7eee-c8c2-d3bf-288af3bfcfca@oracle.com>
On 4/9/18 4:05 PM, Erik ?sterlund wrote:
> Hi Kim,
>
> Thank you for looking at this. Since this was well received, I went
> ahead and implemented something similar on SPARC as well. Also added
> support for storing roots (rather than asserting that stores are in
> the heap only), just in case we need it in the future.
http://cr.openjdk.java.net/~eosterlund/8199417/webrev.02/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp.udiff.html
:( you're not going to do all of them since you changed this code too???
It would make it easier for us to pattern match for changes to other
platforms if you did, since we have no way of testing these platforms.
The sparc changes look reasonable too.
Coleen
>
> Full webrev:
> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.02/
>
> Incremental webrev:
> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01_02/
>
> On 2018-04-06 01:38, Kim Barrett wrote:
>>> On Apr 4, 2018, at 9:38 AM, Erik ?sterlund
>>> <erik.osterlund at oracle.com> wrote:
>>>
>>> Hi Kim,
>>>
>>> Thank you for reviewing this.
>>>
>>> I have made a new webrev with proposed changes to the x86/x64 code
>>> reflecting the concerns you and Coleen have.
>>> I thought we should settle for something we like in the x86/x64 code
>>> before going ahead and changing the other platforms too much (I
>>> don't want to bug Martin and Roman too much before).
>>>
>>> New full webrev:
>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01/
>>>
>>> Incremental:
>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.00_01/
>> This looks better, and you've mostly answered the issues I've raised
>> so far.? Some further discussion inline below.
>
> I'm glad to hear that.
>
>> Other things have come up and I'm not going to be able to properly get
>> back to this soon; don't hold up on my account, just drop me as a
>> reviewer.
>>
>>> On 2018-04-01 05:12, Kim Barrett wrote:
>>>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>>>> 364 #ifndef _LP64
>>>> 365?? InterpreterMacroAssembler *imasm =
>>>> static_cast<InterpreterMacroAssembler*>(masm);
>>>> 366 #endif
>>>>
>>>> In the old code, the function received an InterpreterMacroAssembler*.
>>>>
>>>> What is there about this context that lets us know the downcast is
>>>> safe here?? Is oop_store_at only ever called with an IMA*? If so,
>>>> then why isn't that the parameter type.? If not, then what?
>>> Yes, this is indeed only used by the InterpreterMacroAssembler. But
>>> I wanted the interface to use MacroAssembler. Why?
>>>
>>> 1) It's only 32 bit x86 that relies on this property, and I hope it
>>> will go away soon, and the save bcp hack with it.
>>> 2) previous load_heap_oop is used not only in the
>>> InterpreterMacroAssembler, and I wanted the same assembler in
>>> load_at and store_at.
>>>
>>> So for now it is only used in InterpreterMacroAssembler, and I doubt
>>> that will change any time soon. I am hoping 32 bit support will be
>>> dropped before that, and the hack will go away. For now, I have
>>> added a virtual is_interpreter_masm() call that I use in an assert
>>> to make sure this is not accidentally used in the wrong context
>>> until 32 bit support is gone.
>> The comment plus the new assert satisfies my complaint.
>
> Thanks.
>
>>>> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>>>> 698 address
>>>> TemplateInterpreterGenerator::generate_Reference_get_entry(void) {
>>>>
>>>> Almost all the code here (and much of the commentary) was/is specific
>>>> to G1 (or SATB collectors).? Shouldn't it all be in the barrier_set's
>>>> load_at?? As it is now, if (say) we're using Parallel GC then I think
>>>> there's a bunch of additional code being generated and executed here
>>>> that wasn't present before.
>>> It is true that interpreter Reference.get() intrinsics with
>>> Parallel/CMS/Serial currently run a few instructions more than they
>>> need to pay for the abstraction. There is no doubt in my mind that
>>> this abstraction is worth the cost. Reference.get in the interpreter
>>> is not a hot path, and does not need to optimize every cycle.
>>>
>>> I changed the G1 comments to more general comments instead.
>> Good point on this not being a hot path.
>>
>> "Preserve the sender sp in case the pre-barrier
>> calls the runtime"
>>
>> s/the pre-barrier/a load barrier/
>
> Fixed.
>
>>>> src/hotspot/cpu/x86/gc/shared/modRefBarrierSetAssembler_x86.cpp
>>>> 86 void ModRefBarrierSetAssembler::store_at(MacroAssembler* masm,
>>>> DecoratorSet decorators, BasicType type,
>>>> 87??????????????????????????????????????? Address dst, Register
>>>> val, Register tmp1, Register tmp2) {
>>>> 88?? if (type == T_OBJECT || type == T_ARRAY) {
>>>> 89???? oop_store_at(masm, decorators, type, dst, val, tmp1, tmp2);
>>>> 90?? } else {
>>>> 91???? BarrierSetAssembler::store_at(masm, decorators, type, dst,
>>>> val, tmp1, tmp2);
>>>> 92?? }
>>>> 93 }
>>>>
>>>> Doesn't the conditional conversion from store_at to oop_store_at
>>>> actually indicate a bug in the caller? That is, calling store_at with
>>>> a oop (T_OBJECT or T_ARRAY) value seems like a bug, and should be
>>>> asserted against, rather than translating.
>>>>
>>>> And oop_store_at should assert that the value *is* an oop value.
>>>>
>>>> And should there be any verification that the decorators and the type
>>>> are consistent?
>>>>
>>>> But maybe I'm not understanding the protocol around oop_store_at?
>>>> There being no documentation, it seems entirely possible that I've
>>>> misunderstood something here.? Maybe I'm being confused by
>>>> similarities in naming with Access:: that don't hold?
>>> The confusion roots in that Access and BarrierSetAssembler are not
>>> structured exactly the same.
>>>
>>> Access provides store_at and oop_store_at. The reason for providing
>>> both of these, is that I could not safely infer whether the passed
>>> in parameters were oops or not without changing oop and narrowOop to
>>> always be value objects, which I did not dare to do as the generated
>>> code was worse.
>>>
>>> In BarrierSetAssembler, there is no such restriction. The type for
>>> the access is always passed in to store_at/load_at as BasicType. It
>>> is the responsibility of ModRefBarrierSetAssembler to filter away
>>> non-oop references, and call oop_store_at for relevant accesses for
>>> ModRef. This follows the same pattern that the arraycopy stubs used.
>>> This allows, e.g. CardTableModRef to only override oop_store_at.
>>> This is similar to how ModRefBarrierSet::AccessBarrier<decorators,
>>> BarrierSetT>::oop_store_in_heap calls the concrete barriersets for
>>> help generating that access. I hope this helps understanding the
>>> structuring.
>>>
>>> This is also the reason why G1BarrierSetAssembler::load_at checks
>>> whether it is an oop that is loaded or not, because loads are not
>>> riding on the ModRef layer, which only knows about oop stores.
>> I see. The naming congurence, along with my having glazed over the
>> fact that oop_store_at is protected rather than public, led me astray.
>> I don't have any better suggestions for naming.? I would have found
>> some comments describing the protocols helpful.
>
> I added some comments describing the idea behind ModRef.
>
>> Shouldn't ModRef::oop_store_at be pure virtual?? That would have
>> helped my understanding too.
>
> Sure. Fixed.
>
> Thanks,
> /Erik
From david.holmes at oracle.com Wed Apr 11 01:34:17 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Apr 2018 11:34:17 +1000
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
Message-ID: <37e87dfc-1f1e-254b-a03e-8d8c1d4b0cef@oracle.com>
Hi Robin,
On 10/04/2018 10:18 PM, Robbin Ehn wrote:
> Hi all,
>
> We have moved the global-counter to a separate change-set. The
> global-counter
> uses a counter to determine current generation. Any reader needs to have
> a local
> counter for which generation is currently read. By increment the
> global-counter
> and scan for threads reading an old generation and wait for them to
> complete, we
> know when an old generation is not visible (no pre-existing reader). In RCU
> terms, this creates a grace-period. Making this mechanism suitable for a
> read-mostly scenario. In this initial change-set we scan JavaThreads and
> the VMThread.
Sorry but I don't understand how this works. If a reader calls:
31 inline void GlobalCounter::critical_section_begin(Thread *thread) {
32 assert(thread == Thread::current(), "must be current thread");
33 assert(thread->is_VM_thread() || thread->is_Java_thread(), "must
be VMThread or JavaThread");
34 assert((*thread->get_rcu_counter() & COUNTER_ACTIVE) == 0x0,
"nestled critical sections, not supported yet");
35 volatile uintx gbl_cnt =
OrderAccess::load_acquire(&_global_counter._counter);
36 OrderAccess::release_store_fence(thread->get_rcu_counter(),
gbl_cnt + 1);
37 }
and is preempted before the store at line 36, the writer will not see it
and can go ahead and free the data used in the critical section. The
reader does no validation of the counter value and so continues in to
the critical section. Surely there has to be a handshake between the
reader and writer, where the reader signals their intention to enter a
critical section for generation X, then re-reads the generation count to
check it has not changed. ??
src/hotspot/share/utilities/globalCounter.hpp
30 // The GlobalCounter provides a synchronization mechanism threads
which can be
The comment does not read correctly.
Thanks,
David
> A couple of enhancement to the global-counter will be looked into:
> - Quiescent state RCU semantic by using the natural state of JavaThreads
> in the VM.
> - Asynchronous write synchronize, where reclamation, if there are
> per-existing
> reader, is done by the last reader leaving that generation.
> - Register/deregister threads.
>
> The current usage is the upcoming hash-table which uses the
> global-counter to reclaim memory and to concurrently grow. We have also
> potential use-cases in
> other work-in-progress code.
>
> The new gtest passes on our platforms. For now you can look at the gtest
> if you think you have a use-case for this as an example.
>
> Code: http://cr.openjdk.java.net/~rehn/8195099/v1/webrev/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8195099
>
> Thanks, Robbin
From boris.ulasevich at bell-sw.com Wed Apr 11 05:33:55 2018
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Wed, 11 Apr 2018 08:33:55 +0300
Subject: RFR (S) 8201372: aarch32 - 'minimal' build fails because CMS bits
are referred unconditionally
In-Reply-To: <90766D9B-1D0B-4EA1-9EBC-C3D018B728F6@oracle.com>
References: <e5f65fff-b80e-b16b-d091-0242a6de398b@bell-sw.com>
<90766D9B-1D0B-4EA1-9EBC-C3D018B728F6@oracle.com>
Message-ID: <bea3accb-e912-5ffc-5176-c6d43512e62a@bell-sw.com>
Good point! I missed it.
As I can see, Stefan is going to fix this place in c1_LIRGenerator.cpp:
http://cr.openjdk.java.net/~stefank/8200729/prototype/webrev.02/
Boris
On 10.04.2018 22:06, Bob Vandette wrote:
> Thanks for keeping the minimal VM build alive!
>
> Any chance you could fix the Linux x64/x86 minimal builds with this
> integration as well?
>
> /export/users/bobv/jdk11hs/open/src/hotspot/share/c1/c1_LIRGenerator.cpp: In
> member function 'void
> LIRGenerator::CardTableBarrierSet_post_barrier(LIR_OprDesc*, LIR_OprDesc*)':
> /export/users/bobv/jdk11hs/open/src/hotspot/share/c1/c1_LIRGenerator.cpp:1662:31:
> error: 'CMSPrecleaningEnabled' was not declared in this scope
> ?? ??if (UseConcMarkSweepGC && CMSPrecleaningEnabled) {
> ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ??^
>
> Bob Vandette
>
>> On Apr 10, 2018, at 12:58 PM, Boris Ulasevich
>> <boris.ulasevich at bell-sw.com <mailto:boris.ulasevich at bell-sw.com>> wrote:
>>
>> Hi all,
>>
>> Please review this patch to fix Minimal VM build fail caused by recent
>> GC headers updating.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8201372
>> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8201372/webrev.00/
>>
>> Thanks,
>> Boris
>
From chris.plummer at oracle.com Wed Apr 11 05:36:54 2018
From: chris.plummer at oracle.com (Chris Plummer)
Date: Tue, 10 Apr 2018 22:36:54 -0700
Subject: RFR (M): 8201247: Various cleanups in the attach framework
In-Reply-To: <630dcc82-81c3-f09f-76db-da4ff7d03363@oracle.com>
References: <14dff9b0cf5a4b888aef1d6452801b57@sap.com>
<91d75e2d-47a4-e9ee-5d19-8f3e6dc13428@oracle.com>
<a3248ff5584e4186acc8a3baec06ab4b@sap.com>
<1497c4c6-d95e-7e25-b503-cc7da9d6d077@oracle.com>
<1e441d12b6ca421f8b6774562c8e30b9@sap.com>
<630dcc82-81c3-f09f-76db-da4ff7d03363@oracle.com>
Message-ID: <c777c14f-9d37-ab43-99b8-414fbb7fd4b9@oracle.com>
Hi Christoph,
I finished testing. No issues.
thanks,
Chris
On 4/10/18 1:08 PM, Chris Plummer wrote:
> Hi Christoph,
>
> I'm somewhat new to looking at submit-hs test jobs. However I see know
> indication of there being a submit for JDK-8201247, so I don't think
> it was run. I'll start my own testing with the last patch you sent out.
>
> thanks,
>
> Chris
>
> On 4/10/18 1:01 PM, Langer, Christoph wrote:
>> Hi Chris,
>>
>> I ran the jtreg tests under hotspot/jtreg/serviceability/attach and
>> jdk/com/sun/tools/attach for the main platforms (Windows, Linux
>> X86_64, mac, solaris and AIX).
>>
>> I also pushed to submit-hs in branch "JDK-8201247" but it seems I
>> have no luck and got no notification mails. May I ask you to check
>> whether the build/test cycle was run and how the results looked like?
>>
>> Please also do your closed testing and let me know the outcome.
>>
>> Thanks a lot in advance
>> Christoph
>>
>>> -----Original Message-----
>>> From: Chris Plummer [mailto:chris.plummer at oracle.com]
>>> Sent: Montag, 9. April 2018 20:05
>>> To: Langer, Christoph <christoph.langer at sap.com>; serviceability-
>>> dev at openjdk.java.net
>>> Cc: hotspot-dev at openjdk.java.net
>>> Subject: Re: RFR (M): 8201247: Various cleanups in the attach framework
>>>
>>> Hi Christoph,
>>>
>>> We have some closed "attach on demand" tests that should be run also. I
>>> can do this for you when you are ready. Please also let me know which
>>> other jtreg tests you have run.
>>>
>>> thanks,
>>>
>>> Chris
>>>
>>> On 4/9/18 12:08 AM, Langer, Christoph wrote:
>>>> Hi Chris,
>>>>
>>>> thanks for looking into this.
>>>>
>>>> As for ArgumentIterator::next, I must admit, I found this patch in
>>>> our code
>>> base when taking over the code. I believe that an issue would be
>>> seen if an
>>> attach operation has 2 or 3 arguments and the first one is
>>> NULL/empty. I
>>> guess such a situation can't happen with the attach operations
>>> currently
>>> existing in OpenJDK as none of these ops would allow such type of
>>> arguments. However, in our implementation, we have for instance
>>> enhanced
>>> the "dump_heap" operation to work with null as first argument where one
>>> usually would specify the desired output file name. We implemented a
>>> mechanism to compute a default filename when the param is left
>>> blank. So
>>> we need the fix for that case, I guess.
>>>> I'll run the patch through the submission forest now and do some jtreg
>>> testing.
>>>> Best regards
>>>> Christoph
>>>>
>>>>> -----Original Message-----
>>>>> From: Chris Plummer [mailto:chris.plummer at oracle.com]
>>>>> Sent: Freitag, 6. April 2018 18:37
>>>>> To: Langer, Christoph <christoph.langer at sap.com>; serviceability-
>>>>> dev at openjdk.java.net
>>>>> Cc: hotspot-dev at openjdk.java.net
>>>>> Subject: Re: RFR (M): 8201247: Various cleanups in the attach
>>>>> framework
>>>>>
>>>>> Hi Christoph,
>>>>>
>>>>> Can you explain a bit more about "fix handling of null values in
>>>>> ArgumentIterator::next". When does this turn up? Is there a test
>>>>> case?
>>>>>
>>>>> Everything else looks good.
>>>>>
>>>>> thanks,
>>>>>
>>>>> Chris
>>>>>
>>>>> On 4/6/18 8:01 AM, Langer, Christoph wrote:
>>>>>> Hi,
>>>>>>
>>>>>> can I please get reviews for a set of clean up changes that I came
>>>>>> across when doing some integration work.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201247
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8201247>
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/
>>>>>> <http://cr.openjdk.java.net/%7Eclanger/webrevs/8201247.0/>
>>>>>>
>>>>>> Detailed comments about the changes can be found in the bug.
>>>>>>
>>>>>> Thanks & best regards
>>>>>>
>>>>>> Christoph
>>>>>>
>
From goetz.lindenmaier at sap.com Wed Apr 11 05:58:22 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 11 Apr 2018 05:58:22 +0000
Subject: RFR (M): 8201247: Various cleanups in the attach framework
In-Reply-To: <50b1511e-9f45-60eb-bbec-9734da10f373@oracle.com>
References: <14dff9b0cf5a4b888aef1d6452801b57@sap.com>
<29475f2084e24093892b4289b1e34f62@sap.com>
<50b1511e-9f45-60eb-bbec-9734da10f373@oracle.com>
Message-ID: <0b78469d4d5a441da20572059ae5f216@sap.com>
Ah, ok, thanks for the info!
Best regards,
Goetz.
> -----Original Message-----
> From: Chris Plummer [mailto:chris.plummer at oracle.com]
> Sent: Dienstag, 10. April 2018 19:31
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Langer, Christoph
> <christoph.langer at sap.com>; serviceability-dev at openjdk.java.net
> Cc: hotspot-dev at openjdk.java.net
> Subject: Re: RFR (M): 8201247: Various cleanups in the attach framework
>
> On 4/10/18 8:34 AM, Lindenmaier, Goetz wrote:
> > Hi Christoph,
> >
> > thanks for doing this laborious change ... comparing all these files :)
> >
> > Change looks good, just some minor comments:
> >
> > You say you are sorting the includes, but in the VirtualMachineImpl.c
> > files the order is changed, but according to which order? It's
> > not alphabetical as in other files.
> >
> > In windows VirtualMachineImpl.c, what was wrong with printing the
> > last error code?
> JNU_ThrowIOExceptionWithLastError already includes it.
>
> Chris
> >
> > Best regards,
> > Goetz.
> >
> >
> >
> >> -----Original Message-----
> >> From: serviceability-dev [mailto:serviceability-dev-
> >> bounces at openjdk.java.net] On Behalf Of Langer, Christoph
> >> Sent: Freitag, 6. April 2018 17:02
> >> To: serviceability-dev at openjdk.java.net
> >> Cc: hotspot-dev at openjdk.java.net
> >> Subject: [CAUTION] RFR (M): 8201247: Various cleanups in the attach
> >> framework
> >>
> >> Hi,
> >>
> >>
> >>
> >> can I please get reviews for a set of clean up changes that I came across
> >> when doing some integration work.
> >>
> >>
> >>
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8201247
> >> <https://bugs.openjdk.java.net/browse/JDK-8201247>
> >>
> >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/
> >> <http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/>
> >>
> >>
> >>
> >> Detailed comments about the changes can be found in the bug.
> >>
> >>
> >>
> >> Thanks & best regards
> >>
> >> Christoph
> >>
> >>
> >>
> >>
From yang.zhang at linaro.org Wed Apr 11 07:18:11 2018
From: yang.zhang at linaro.org (Yang Zhang)
Date: Wed, 11 Apr 2018 15:18:11 +0800
Subject: [aarch64-port-dev ] AOT for AArch64: current status
In-Reply-To: <6ed685f0-c851-d12f-1788-a896f4e0d162@redhat.com>
References: <83f0e948-d002-6b71-e73f-6f65fce14e3b@redhat.com>
<15f51315-3497-6c01-2ecb-1f758762e99e@redhat.com>
<849a8fcf-85cd-b8c6-1134-9aea3877e9b7@redhat.com>
<2c42186a-523e-6912-6eb0-36c7ee2be09f@redhat.com>
<8b4a211e-44af-ed28-5abf-697d722771d1@redhat.com>
<97d96f0e-43b0-beca-3b31-3dabc6073f3a@redhat.com>
<8342caa0-e4d1-0250-02ab-c8f9cf8085bd@redhat.com>
<edaacf43-9be5-c029-99c8-1753d1c9f8b6@redhat.com>
<6ed685f0-c851-d12f-1788-a896f4e0d162@redhat.com>
Message-ID: <CAHMTGtaHQsLJupNvpzoDQ+MANWp6a38W7ZOesuuBNu_H4NzT0A@mail.gmail.com>
Hi Andrew
When I tested the new patch, I found there is a test case which is
passed with release jdk build, but is failed with fastdebug/slowdebug
jdk build.
compiler/aot/cli/jaotc/CompileClassWithDebugTest.java
With fastdebug:
TEST RESULT: Failed. Execution failed: `main' threw exception:
java.lang.RuntimeException: Expected to get exit value of [0]
This failure results from "Fix out-of-range branch " patch
https://github.com/theRealAph/graal/commit/d2ed61967b202cc9f623387619902315df20ede6
Regards
Yang
On 4 April 2018 at 01:28, Andrew Haley <aph at redhat.com> wrote:
> I fixed a bug in Graal which was causing
> compiler.aot.DeoptimizationTest to fail.
>
> I fixed the bug which was causing assertion failures due to branch out
> of range.
>
> I pulled from the tip of Graal master. It should all be up to date
> now.
>
> All pushed to https://github.com/theRealAph/graal.git aarch64-branch-overflows
>
> I'm still seeing some assertion failures, but they're not in my code
> and I don't think they're anything to do with me. They all seem to do
> with types not being registered. Updating Graal didn't help, so I
> need to try to figure out why this isn't a problem on x86.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From stefan.karlsson at oracle.com Wed Apr 11 07:25:55 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 11 Apr 2018 09:25:55 +0200
Subject: RFR (S) 8201370: Minimal VM build fail
In-Reply-To: <a3cc4257-ac51-2eca-1695-07b4266786b1@oracle.com>
References: <ae347b5b-0d19-c9da-ff69-ed9f621643c2@bell-sw.com>
<41da233d-84d1-07a0-e9b1-e0fc76366836@oracle.com>
<a3cc4257-ac51-2eca-1695-07b4266786b1@oracle.com>
Message-ID: <7a5831d3-bc90-a6bd-974b-7aad0a3c986e@oracle.com>
On 2018-04-10 23:58, David Holmes wrote:
> Hi Stefan,
>
> On 11/04/2018 5:45 AM, Stefan Karlsson wrote:
>> Hi Boris,
>>
>> Thanks for fixing this!
>>
>> For some reason I didn't bring those changes over from my original
>> patch to prototype conditional compilation of the GCs:
>> http://cr.openjdk.java.net/~stefank/8200729/prototype/webrev.01/
>>
>> I've rebased that patch on my latest pushed changes and this should be
>> a much smaller patch:
>> http://cr.openjdk.java.net/~stefank/8200729/prototype/webrev.02/
>>
>> I'll go through that patch and see if there is something else I've
>> missed.
>>
>> Regarding your patch, I think that you could push this and get rid of
>> the Minimal VM build breakage, but please also consider the comments
>> below:
>>
>> I see that you've added some includes to precompiled.hpp. This might be
>
> They weren't added, they were moved from being unconditional into the
> INCLUDE_ALL_GCS section.
You're right. I missed those red lines when I looked at this last night.
So, nothing to see here, please move along. ;)
Thanks,
StefanK
>
> David
> -----
>
>> fine if you want to solve the urgent build problem, but ultimately we
>> should be able to compile minimalvm with '--build-configure-args
>> --disable-precompiled-headers'. Adding headers to the precompiled.hpp
>> file should never be done to solve include dependency problem. If
>> there are missing includes those needs to be added to the files that
>> uses the code in the missing header files.
>>
>> Thanks,
>> StefanK
>>
>> On 2018-04-10 18:56, Boris Ulasevich wrote:
>>> Hi all,
>>>
>>> Please review this patch to fix Minimal VM build fail caused by
>>> recent GC headers updating.
>>>
>>> ?https://bugs.openjdk.java.net/browse/JDK-8201370
>>> ?http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8201370/webrev.00/
>>>
>>> I will post separate review on arm32-specific changes.
>>>
>>> Thanks,
>>> Boris
>>
>>
From christoph.langer at sap.com Wed Apr 11 07:44:56 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 11 Apr 2018 07:44:56 +0000
Subject: RFR (M): 8201247: Various cleanups in the attach framework
In-Reply-To: <29475f2084e24093892b4289b1e34f62@sap.com>
References: <14dff9b0cf5a4b888aef1d6452801b57@sap.com>
<29475f2084e24093892b4289b1e34f62@sap.com>
Message-ID: <5073b066ce2c43f78a17a5443a578379@sap.com>
Hi Goetz,
thanks for the review.
> You say you are sorting the includes, but in the VirtualMachineImpl.c
> files the order is changed, but according to which order? It's
> not alphabetical as in other files.
It is. However, I have put "subdirs" first. That is, the includes from sys/* come first (in alphabetical order).
Best regards
Christoph
From christoph.langer at sap.com Wed Apr 11 07:45:34 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 11 Apr 2018 07:45:34 +0000
Subject: RFR (M): 8201247: Various cleanups in the attach framework
In-Reply-To: <c777c14f-9d37-ab43-99b8-414fbb7fd4b9@oracle.com>
References: <14dff9b0cf5a4b888aef1d6452801b57@sap.com>
<91d75e2d-47a4-e9ee-5d19-8f3e6dc13428@oracle.com>
<a3248ff5584e4186acc8a3baec06ab4b@sap.com>
<1497c4c6-d95e-7e25-b503-cc7da9d6d077@oracle.com>
<1e441d12b6ca421f8b6774562c8e30b9@sap.com>
<630dcc82-81c3-f09f-76db-da4ff7d03363@oracle.com>
<c777c14f-9d37-ab43-99b8-414fbb7fd4b9@oracle.com>
Message-ID: <1fb9b7b44ce043ed91b9837b8a11ffe9@sap.com>
Thanks Chris, I'll push it then today.
> -----Original Message-----
> From: Chris Plummer [mailto:chris.plummer at oracle.com]
> Sent: Mittwoch, 11. April 2018 07:37
> To: Langer, Christoph <christoph.langer at sap.com>; serviceability-
> dev at openjdk.java.net
> Cc: hotspot-dev at openjdk.java.net
> Subject: Re: RFR (M): 8201247: Various cleanups in the attach framework
>
> Hi Christoph,
>
> I finished testing. No issues.
>
> thanks,
>
> Chris
>
> On 4/10/18 1:08 PM, Chris Plummer wrote:
> > Hi Christoph,
> >
> > I'm somewhat new to looking at submit-hs test jobs. However I see know
> > indication of there being a submit for JDK-8201247, so I don't think
> > it was run. I'll start my own testing with the last patch you sent out.
> >
> > thanks,
> >
> > Chris
> >
> > On 4/10/18 1:01 PM, Langer, Christoph wrote:
> >> Hi Chris,
> >>
> >> I ran the jtreg tests under hotspot/jtreg/serviceability/attach and
> >> jdk/com/sun/tools/attach for the main platforms (Windows, Linux
> >> X86_64, mac, solaris and AIX).
> >>
> >> I also pushed to submit-hs in branch "JDK-8201247" but it seems I
> >> have no luck and got no notification mails. May I ask you to check
> >> whether the build/test cycle was run and how the results looked like?
> >>
> >> Please also do your closed testing and let me know the outcome.
> >>
> >> Thanks a lot in advance
> >> Christoph
> >>
> >>> -----Original Message-----
> >>> From: Chris Plummer [mailto:chris.plummer at oracle.com]
> >>> Sent: Montag, 9. April 2018 20:05
> >>> To: Langer, Christoph <christoph.langer at sap.com>; serviceability-
> >>> dev at openjdk.java.net
> >>> Cc: hotspot-dev at openjdk.java.net
> >>> Subject: Re: RFR (M): 8201247: Various cleanups in the attach framework
> >>>
> >>> Hi Christoph,
> >>>
> >>> We have some closed "attach on demand" tests that should be run also.
> I
> >>> can do this for you when you are ready. Please also let me know which
> >>> other jtreg tests you have run.
> >>>
> >>> thanks,
> >>>
> >>> Chris
> >>>
> >>> On 4/9/18 12:08 AM, Langer, Christoph wrote:
> >>>> Hi Chris,
> >>>>
> >>>> thanks for looking into this.
> >>>>
> >>>> As for ArgumentIterator::next, I must admit, I found this patch in
> >>>> our code
> >>> base when taking over the code. I believe that an issue would be
> >>> seen if an
> >>> attach operation has 2 or 3 arguments and the first one is
> >>> NULL/empty. I
> >>> guess such a situation can't happen with the attach operations
> >>> currently
> >>> existing in OpenJDK as none of these ops would allow such type of
> >>> arguments. However, in our implementation, we have for instance
> >>> enhanced
> >>> the "dump_heap" operation to work with null as first argument where
> one
> >>> usually would specify the desired output file name. We implemented a
> >>> mechanism to compute a default filename when the param is left
> >>> blank. So
> >>> we need the fix for that case, I guess.
> >>>> I'll run the patch through the submission forest now and do some jtreg
> >>> testing.
> >>>> Best regards
> >>>> Christoph
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Chris Plummer [mailto:chris.plummer at oracle.com]
> >>>>> Sent: Freitag, 6. April 2018 18:37
> >>>>> To: Langer, Christoph <christoph.langer at sap.com>; serviceability-
> >>>>> dev at openjdk.java.net
> >>>>> Cc: hotspot-dev at openjdk.java.net
> >>>>> Subject: Re: RFR (M): 8201247: Various cleanups in the attach
> >>>>> framework
> >>>>>
> >>>>> Hi Christoph,
> >>>>>
> >>>>> Can you explain a bit more about "fix handling of null values in
> >>>>> ArgumentIterator::next". When does this turn up? Is there a test
> >>>>> case?
> >>>>>
> >>>>> Everything else looks good.
> >>>>>
> >>>>> thanks,
> >>>>>
> >>>>> Chris
> >>>>>
> >>>>> On 4/6/18 8:01 AM, Langer, Christoph wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> can I please get reviews for a set of clean up changes that I came
> >>>>>> across when doing some integration work.
> >>>>>>
> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201247
> >>>>>> <https://bugs.openjdk.java.net/browse/JDK-8201247>
> >>>>>>
> >>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/
> >>>>>> <http://cr.openjdk.java.net/%7Eclanger/webrevs/8201247.0/>
> >>>>>>
> >>>>>> Detailed comments about the changes can be found in the bug.
> >>>>>>
> >>>>>> Thanks & best regards
> >>>>>>
> >>>>>> Christoph
> >>>>>>
> >
From goetz.lindenmaier at sap.com Wed Apr 11 07:56:22 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 11 Apr 2018 07:56:22 +0000
Subject: RFR (M): 8201247: Various cleanups in the attach framework
In-Reply-To: <5073b066ce2c43f78a17a5443a578379@sap.com>
References: <14dff9b0cf5a4b888aef1d6452801b57@sap.com>
<29475f2084e24093892b4289b1e34f62@sap.com>
<5073b066ce2c43f78a17a5443a578379@sap.com>
Message-ID: <8b7165cb8e884c5bb6a8cf872817e527@sap.com>
Hi Christoph,
I'm familiar with the non-system includes in hotspot,
there mostly a total alphabetical ordering is followed, like in
http://hg.openjdk.java.net/jdk/hs/file/0d8ed8b2ac4f/src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp
> It is. However, I have put "subdirs" first. That is, the includes from sys/*
Also, that's not true, see the first file in your webrev, which is sorted as I would expect:
http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/src/hotspot/os/aix/attachListener_aix.cpp.html
while this sorts as you state:
http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/src/jdk.attach/linux/native/libattach/VirtualMachineImpl.c.html
Is there a different pattern followed in hotspot and jdk coding?
In case you resort them (have fun :) ), no new webrev is needed.
Best regards,
Goetz.
> -----Original Message-----
> From: Langer, Christoph
> Sent: Mittwoch, 11. April 2018 09:45
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; serviceability-
> dev at openjdk.java.net
> Cc: hotspot-dev at openjdk.java.net
> Subject: RE: RFR (M): 8201247: Various cleanups in the attach framework
>
> Hi Goetz,
>
> thanks for the review.
>
> > You say you are sorting the includes, but in the VirtualMachineImpl.c
> > files the order is changed, but according to which order? It's
> > not alphabetical as in other files.
>
> It is. However, I have put "subdirs" first. That is, the includes from sys/*
> come first (in alphabetical order).
>
> Best regards
> Christoph
From kim.barrett at oracle.com Wed Apr 11 08:01:12 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 11 Apr 2018 04:01:12 -0400
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <37e87dfc-1f1e-254b-a03e-8d8c1d4b0cef@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<37e87dfc-1f1e-254b-a03e-8d8c1d4b0cef@oracle.com>
Message-ID: <84D1CF4E-B765-4FF5-9D6A-79703947FCE8@oracle.com>
> On Apr 10, 2018, at 9:34 PM, David Holmes <david.holmes at oracle.com> wrote:
>
> Hi Robin,
>
> On 10/04/2018 10:18 PM, Robbin Ehn wrote:
>> Hi all,
>> We have moved the global-counter to a separate change-set. The global-counter
>> uses a counter to determine current generation. Any reader needs to have a local
>> counter for which generation is currently read. By increment the global-counter
>> and scan for threads reading an old generation and wait for them to complete, we
>> know when an old generation is not visible (no pre-existing reader). In RCU
>> terms, this creates a grace-period. Making this mechanism suitable for a read-mostly scenario. In this initial change-set we scan JavaThreads and the VMThread.
>
> Sorry but I don't understand how this works. If a reader calls:
>
> 31 inline void GlobalCounter::critical_section_begin(Thread *thread) {
> 32 assert(thread == Thread::current(), "must be current thread");
> 33 assert(thread->is_VM_thread() || thread->is_Java_thread(), "must be VMThread or JavaThread");
> 34 assert((*thread->get_rcu_counter() & COUNTER_ACTIVE) == 0x0, "nestled critical sections, not supported yet");
> 35 volatile uintx gbl_cnt = OrderAccess::load_acquire(&_global_counter._counter);
> 36 OrderAccess::release_store_fence(thread->get_rcu_counter(), gbl_cnt + 1);
> 37 }
>
> and is preempted before the store at line 36, the writer will not see it and can go ahead and free the data used in the critical section. The reader does no validation of the counter value and so continues in to the critical section. Surely there has to be a handshake between the reader and writer, where the reader signals their intention to enter a critical section for generation X, then re-reads the generation count to check it has not changed. ??
A writer updates its protected shared state and then waits for any
readers that might see the previous value of that shared state. That
is, any reader that is in the critical section (has the active bit set
in its local counter) *and* entered before the shared state was
updated. The latter is conservatively approximated by actually
checking whether the reader entered the critical section before the
wait started, with the wait ordered after the shared state update.
The wait check implements the latter condition via a range test. If
the reader entered before the wait, then it's local counter is "less
than" the writer's updated counter. This is implementated by an
unsigned subtract and checking for a large result. (With this
implementation there is a limit on just how stale the reader can be; a
reader must complete a critical section before max_uintx/4 writers
wait.)
When a writer updates protected shared state, increments the global
counter, and then checks / waits for readers,
(1) If a reader obtained a global counter value before that increment,
but has not yet set its local state to indicate it is active, then the
writer will not wait for it. But that's okay, because when the reader
gets around to entering the critical region and examining the
protected shared state, it is guaranteed not to see the old value of
the protected shared state.
(2) If a reader obtained a global counter value before that increment
and marked itself active, then the writer will wait until the reader
exits the critical section. The reader might see the old value of the
protected shared state while in the critical region.
(3) If a reader obtained a global counter value after that increment,
then it is guaranteed not to see the old value of the protected shared
state.
From christoph.langer at sap.com Wed Apr 11 08:02:52 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 11 Apr 2018 08:02:52 +0000
Subject: RFR (M): 8201247: Various cleanups in the attach framework
In-Reply-To: <8b7165cb8e884c5bb6a8cf872817e527@sap.com>
References: <14dff9b0cf5a4b888aef1d6452801b57@sap.com>
<29475f2084e24093892b4289b1e34f62@sap.com>
<5073b066ce2c43f78a17a5443a578379@sap.com>
<8b7165cb8e884c5bb6a8cf872817e527@sap.com>
Message-ID: <55c2c1c33c2748aca863332d521b9eb6@sap.com>
Hi Goetz,
I did not aim to sort the includes in the attachListener_<os>.cpp files. I also just saw that I made a change in attachListener_aix.cpp for some other merge-related reasons - but it was not correctly sorted before and neither is after ?? This has to be done in a future change...
Best regards
Christoph
> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Mittwoch, 11. April 2018 09:56
> To: Langer, Christoph <christoph.langer at sap.com>; serviceability-
> dev at openjdk.java.net
> Cc: hotspot-dev at openjdk.java.net
> Subject: RE: RFR (M): 8201247: Various cleanups in the attach framework
>
> Hi Christoph,
>
> I'm familiar with the non-system includes in hotspot,
> there mostly a total alphabetical ordering is followed, like in
> http://hg.openjdk.java.net/jdk/hs/file/0d8ed8b2ac4f/src/hotspot/cpu/x86/
> c1_CodeStubs_x86.cpp
> > It is. However, I have put "subdirs" first. That is, the includes from sys/*
> Also, that's not true, see the first file in your webrev, which is sorted as I
> would expect:
> http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/src/hotspot/os/aix
> /attachListener_aix.cpp.html
> while this sorts as you state:
> http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/src/jdk.attach/linux
> /native/libattach/VirtualMachineImpl.c.html
>
> Is there a different pattern followed in hotspot and jdk coding?
>
> In case you resort them (have fun :) ), no new webrev is needed.
>
> Best regards,
> Goetz.
>
>
> > -----Original Message-----
> > From: Langer, Christoph
> > Sent: Mittwoch, 11. April 2018 09:45
> > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; serviceability-
> > dev at openjdk.java.net
> > Cc: hotspot-dev at openjdk.java.net
> > Subject: RE: RFR (M): 8201247: Various cleanups in the attach framework
> >
> > Hi Goetz,
> >
> > thanks for the review.
> >
> > > You say you are sorting the includes, but in the VirtualMachineImpl.c
> > > files the order is changed, but according to which order? It's
> > > not alphabetical as in other files.
> >
> > It is. However, I have put "subdirs" first. That is, the includes from sys/*
> > come first (in alphabetical order).
> >
> > Best regards
> > Christoph
From stefan.karlsson at oracle.com Wed Apr 11 08:07:07 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 11 Apr 2018 10:07:07 +0200
Subject: RFR (S) 8201370: Minimal VM build fail
In-Reply-To: <ae347b5b-0d19-c9da-ff69-ed9f621643c2@bell-sw.com>
References: <ae347b5b-0d19-c9da-ff69-ed9f621643c2@bell-sw.com>
Message-ID: <d82ef3d3-2450-fc9c-bc16-63a036f6ac2a@oracle.com>
Hi again,
I tried to compile the Minimal VM on my machine and had to apply the
following patch to get it to work:
http://cr.openjdk.java.net/~stefank/8201370/webrev.01/
There's a few more changes, but nothing that seems non-trivial, so
should be enough to get one Reviewer to review this.
Do you want me to sponsor your patch and include the changes in my webrev?
Thanks,
StefanK
On 2018-04-10 18:56, Boris Ulasevich wrote:
> Hi all,
>
> Please review this patch to fix Minimal VM build fail caused by recent
> GC headers updating.
>
> ?https://bugs.openjdk.java.net/browse/JDK-8201370
> ?http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8201370/webrev.00/
>
> I will post separate review on arm32-specific changes.
>
> Thanks,
> Boris
From shade at redhat.com Wed Apr 11 08:11:21 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 11 Apr 2018 10:11:21 +0200
Subject: RFR (S) 8201370: Minimal VM build fail
In-Reply-To: <d82ef3d3-2450-fc9c-bc16-63a036f6ac2a@oracle.com>
References: <ae347b5b-0d19-c9da-ff69-ed9f621643c2@bell-sw.com>
<d82ef3d3-2450-fc9c-bc16-63a036f6ac2a@oracle.com>
Message-ID: <44d2bdb0-bd07-dc69-115d-6b2b595bcfe6@redhat.com>
On 04/11/2018 10:07 AM, Stefan Karlsson wrote:
> Hi again,
>
> I tried to compile the Minimal VM on my machine and had to apply the following patch to get it to work:
> http://cr.openjdk.java.net/~stefank/8201370/webrev.01/
>
> There's a few more changes, but nothing that seems non-trivial, so should be enough to get one
> Reviewer to review this.
This looks good.
-Aleksey
From erik.osterlund at oracle.com Wed Apr 11 08:57:26 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Wed, 11 Apr 2018 10:57:26 +0200
Subject: RFR: 8199417: Modularize interpreter GC barriers
In-Reply-To: <3a0f68a9-7eee-c8c2-d3bf-288af3bfcfca@oracle.com>
References: <5AB8BDF9.4050106@oracle.com>
<3FFD79AD-84B8-4E9E-98E3-47ACBA01D91F@oracle.com>
<5AC4D555.9040800@oracle.com>
<80295FD9-254E-4670-AB47-E2A4B36C4143@oracle.com>
<b6cdaf49-4715-7193-51ff-c3c19581d497@oracle.com>
<3a0f68a9-7eee-c8c2-d3bf-288af3bfcfca@oracle.com>
Message-ID: <5ACDCDF6.3000804@oracle.com>
Hi Coleen,
I have no plans to update the wrappers calling BarrierSetAssembler on
PPC, S390 and AArch64 code.
1) I simply can't check if my changes work or not on those platforms.
2) This is an interface between the platform specific code and the GC.
So I feel like the chosen wrapper to call into BarrierSetAssembler is up
to the maintainers of those platforms, and it feels like it is not my
call to tell other maintainers what wrapper functions they should use.
So basically, since I can't test on those platforms, I think it is up to
Martin Doerr and Roman Kennke to adopt the wrapper function if they like
it. And I think that is easiest to do as separate RFEs.
Thanks,
/Erik
On 2018-04-11 00:49, coleen.phillimore at oracle.com wrote:
>
>
> On 4/9/18 4:05 PM, Erik ?sterlund wrote:
>> Hi Kim,
>>
>> Thank you for looking at this. Since this was well received, I went
>> ahead and implemented something similar on SPARC as well. Also added
>> support for storing roots (rather than asserting that stores are in
>> the heap only), just in case we need it in the future.
>
> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.02/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp.udiff.html
>
>
> :( you're not going to do all of them since you changed this code
> too? It would make it easier for us to pattern match for changes to
> other platforms if you did, since we have no way of testing these
> platforms.
>
> The sparc changes look reasonable too.
>
> Coleen
>
>>
>> Full webrev:
>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.02/
>>
>> Incremental webrev:
>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01_02/
>>
>> On 2018-04-06 01:38, Kim Barrett wrote:
>>>> On Apr 4, 2018, at 9:38 AM, Erik ?sterlund
>>>> <erik.osterlund at oracle.com> wrote:
>>>>
>>>> Hi Kim,
>>>>
>>>> Thank you for reviewing this.
>>>>
>>>> I have made a new webrev with proposed changes to the x86/x64 code
>>>> reflecting the concerns you and Coleen have.
>>>> I thought we should settle for something we like in the x86/x64
>>>> code before going ahead and changing the other platforms too much
>>>> (I don't want to bug Martin and Roman too much before).
>>>>
>>>> New full webrev:
>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01/
>>>>
>>>> Incremental:
>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.00_01/
>>> This looks better, and you've mostly answered the issues I've raised
>>> so far. Some further discussion inline below.
>>
>> I'm glad to hear that.
>>
>>> Other things have come up and I'm not going to be able to properly get
>>> back to this soon; don't hold up on my account, just drop me as a
>>> reviewer.
>>>
>>>> On 2018-04-01 05:12, Kim Barrett wrote:
>>>>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>>>>> 364 #ifndef _LP64
>>>>> 365 InterpreterMacroAssembler *imasm =
>>>>> static_cast<InterpreterMacroAssembler*>(masm);
>>>>> 366 #endif
>>>>>
>>>>> In the old code, the function received an InterpreterMacroAssembler*.
>>>>>
>>>>> What is there about this context that lets us know the downcast is
>>>>> safe here? Is oop_store_at only ever called with an IMA*? If so,
>>>>> then why isn't that the parameter type. If not, then what?
>>>> Yes, this is indeed only used by the InterpreterMacroAssembler. But
>>>> I wanted the interface to use MacroAssembler. Why?
>>>>
>>>> 1) It's only 32 bit x86 that relies on this property, and I hope it
>>>> will go away soon, and the save bcp hack with it.
>>>> 2) previous load_heap_oop is used not only in the
>>>> InterpreterMacroAssembler, and I wanted the same assembler in
>>>> load_at and store_at.
>>>>
>>>> So for now it is only used in InterpreterMacroAssembler, and I
>>>> doubt that will change any time soon. I am hoping 32 bit support
>>>> will be dropped before that, and the hack will go away. For now, I
>>>> have added a virtual is_interpreter_masm() call that I use in an
>>>> assert to make sure this is not accidentally used in the wrong
>>>> context until 32 bit support is gone.
>>> The comment plus the new assert satisfies my complaint.
>>
>> Thanks.
>>
>>>>> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>>>>> 698 address
>>>>> TemplateInterpreterGenerator::generate_Reference_get_entry(void) {
>>>>>
>>>>> Almost all the code here (and much of the commentary) was/is specific
>>>>> to G1 (or SATB collectors). Shouldn't it all be in the barrier_set's
>>>>> load_at? As it is now, if (say) we're using Parallel GC then I think
>>>>> there's a bunch of additional code being generated and executed here
>>>>> that wasn't present before.
>>>> It is true that interpreter Reference.get() intrinsics with
>>>> Parallel/CMS/Serial currently run a few instructions more than they
>>>> need to pay for the abstraction. There is no doubt in my mind that
>>>> this abstraction is worth the cost. Reference.get in the
>>>> interpreter is not a hot path, and does not need to optimize every
>>>> cycle.
>>>>
>>>> I changed the G1 comments to more general comments instead.
>>> Good point on this not being a hot path.
>>>
>>> "Preserve the sender sp in case the pre-barrier
>>> calls the runtime"
>>>
>>> s/the pre-barrier/a load barrier/
>>
>> Fixed.
>>
>>>>> src/hotspot/cpu/x86/gc/shared/modRefBarrierSetAssembler_x86.cpp
>>>>> 86 void ModRefBarrierSetAssembler::store_at(MacroAssembler* masm,
>>>>> DecoratorSet decorators, BasicType type,
>>>>> 87 Address dst, Register
>>>>> val, Register tmp1, Register tmp2) {
>>>>> 88 if (type == T_OBJECT || type == T_ARRAY) {
>>>>> 89 oop_store_at(masm, decorators, type, dst, val, tmp1, tmp2);
>>>>> 90 } else {
>>>>> 91 BarrierSetAssembler::store_at(masm, decorators, type, dst,
>>>>> val, tmp1, tmp2);
>>>>> 92 }
>>>>> 93 }
>>>>>
>>>>> Doesn't the conditional conversion from store_at to oop_store_at
>>>>> actually indicate a bug in the caller? That is, calling store_at with
>>>>> a oop (T_OBJECT or T_ARRAY) value seems like a bug, and should be
>>>>> asserted against, rather than translating.
>>>>>
>>>>> And oop_store_at should assert that the value *is* an oop value.
>>>>>
>>>>> And should there be any verification that the decorators and the type
>>>>> are consistent?
>>>>>
>>>>> But maybe I'm not understanding the protocol around oop_store_at?
>>>>> There being no documentation, it seems entirely possible that I've
>>>>> misunderstood something here. Maybe I'm being confused by
>>>>> similarities in naming with Access:: that don't hold?
>>>> The confusion roots in that Access and BarrierSetAssembler are not
>>>> structured exactly the same.
>>>>
>>>> Access provides store_at and oop_store_at. The reason for providing
>>>> both of these, is that I could not safely infer whether the passed
>>>> in parameters were oops or not without changing oop and narrowOop
>>>> to always be value objects, which I did not dare to do as the
>>>> generated code was worse.
>>>>
>>>> In BarrierSetAssembler, there is no such restriction. The type for
>>>> the access is always passed in to store_at/load_at as BasicType. It
>>>> is the responsibility of ModRefBarrierSetAssembler to filter away
>>>> non-oop references, and call oop_store_at for relevant accesses for
>>>> ModRef. This follows the same pattern that the arraycopy stubs
>>>> used. This allows, e.g. CardTableModRef to only override
>>>> oop_store_at. This is similar to how
>>>> ModRefBarrierSet::AccessBarrier<decorators,
>>>> BarrierSetT>::oop_store_in_heap calls the concrete barriersets for
>>>> help generating that access. I hope this helps understanding the
>>>> structuring.
>>>>
>>>> This is also the reason why G1BarrierSetAssembler::load_at checks
>>>> whether it is an oop that is loaded or not, because loads are not
>>>> riding on the ModRef layer, which only knows about oop stores.
>>> I see. The naming congurence, along with my having glazed over the
>>> fact that oop_store_at is protected rather than public, led me astray.
>>> I don't have any better suggestions for naming. I would have found
>>> some comments describing the protocols helpful.
>>
>> I added some comments describing the idea behind ModRef.
>>
>>> Shouldn't ModRef::oop_store_at be pure virtual? That would have
>>> helped my understanding too.
>>
>> Sure. Fixed.
>>
>> Thanks,
>> /Erik
>
From rkennke at redhat.com Wed Apr 11 09:05:04 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 11 Apr 2018 11:05:04 +0200
Subject: RFR: 8199417: Modularize interpreter GC barriers
In-Reply-To: <5ACDCDF6.3000804@oracle.com>
References: <5AB8BDF9.4050106@oracle.com>
<3FFD79AD-84B8-4E9E-98E3-47ACBA01D91F@oracle.com>
<5AC4D555.9040800@oracle.com>
<80295FD9-254E-4670-AB47-E2A4B36C4143@oracle.com>
<b6cdaf49-4715-7193-51ff-c3c19581d497@oracle.com>
<3a0f68a9-7eee-c8c2-d3bf-288af3bfcfca@oracle.com>
<5ACDCDF6.3000804@oracle.com>
Message-ID: <9b622ca3-967d-f475-a380-1693f3448d00@redhat.com>
Hi Erik,
> I have no plans to update the wrappers calling BarrierSetAssembler on
> PPC, S390 and AArch64 code.
>
> 1) I simply can't check if my changes work or not on those platforms.
> 2) This is an interface between the platform specific code and the GC.
> So I feel like the chosen wrapper to call into BarrierSetAssembler is up
> to the maintainers of those platforms, and it feels like it is not my
> call to tell other maintainers what wrapper functions they should use.
>
> So basically, since I can't test on those platforms, I think it is up to
> Martin Doerr and Roman Kennke to adopt the wrapper function if they like
> it. And I think that is easiest to do as separate RFEs.
This sounds reasonable.
Thanks, Roman
>
> Thanks,
> /Erik
>
>
> On 2018-04-11 00:49, coleen.phillimore at oracle.com wrote:
>>
>>
>> On 4/9/18 4:05 PM, Erik ?sterlund wrote:
>>> Hi Kim,
>>>
>>> Thank you for looking at this. Since this was well received, I went
>>> ahead and implemented something similar on SPARC as well. Also added
>>> support for storing roots (rather than asserting that stores are in
>>> the heap only), just in case we need it in the future.
>>
>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.02/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp.udiff.html
>>
>>
>> :( you're not going to do all of them since you changed this code
>> too??? It would make it easier for us to pattern match for changes to
>> other platforms if you did, since we have no way of testing these
>> platforms.
>>
>> The sparc changes look reasonable too.
>>
>> Coleen
>>
>>>
>>> Full webrev:
>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.02/
>>>
>>> Incremental webrev:
>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01_02/
>>>
>>> On 2018-04-06 01:38, Kim Barrett wrote:
>>>>> On Apr 4, 2018, at 9:38 AM, Erik ?sterlund
>>>>> <erik.osterlund at oracle.com> wrote:
>>>>>
>>>>> Hi Kim,
>>>>>
>>>>> Thank you for reviewing this.
>>>>>
>>>>> I have made a new webrev with proposed changes to the x86/x64 code
>>>>> reflecting the concerns you and Coleen have.
>>>>> I thought we should settle for something we like in the x86/x64
>>>>> code before going ahead and changing the other platforms too much
>>>>> (I don't want to bug Martin and Roman too much before).
>>>>>
>>>>> New full webrev:
>>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01/
>>>>>
>>>>> Incremental:
>>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.00_01/
>>>> This looks better, and you've mostly answered the issues I've raised
>>>> so far.? Some further discussion inline below.
>>>
>>> I'm glad to hear that.
>>>
>>>> Other things have come up and I'm not going to be able to properly get
>>>> back to this soon; don't hold up on my account, just drop me as a
>>>> reviewer.
>>>>
>>>>> On 2018-04-01 05:12, Kim Barrett wrote:
>>>>>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>>>>>> 364 #ifndef _LP64
>>>>>> 365?? InterpreterMacroAssembler *imasm =
>>>>>> static_cast<InterpreterMacroAssembler*>(masm);
>>>>>> 366 #endif
>>>>>>
>>>>>> In the old code, the function received an InterpreterMacroAssembler*.
>>>>>>
>>>>>> What is there about this context that lets us know the downcast is
>>>>>> safe here?? Is oop_store_at only ever called with an IMA*? If so,
>>>>>> then why isn't that the parameter type.? If not, then what?
>>>>> Yes, this is indeed only used by the InterpreterMacroAssembler. But
>>>>> I wanted the interface to use MacroAssembler. Why?
>>>>>
>>>>> 1) It's only 32 bit x86 that relies on this property, and I hope it
>>>>> will go away soon, and the save bcp hack with it.
>>>>> 2) previous load_heap_oop is used not only in the
>>>>> InterpreterMacroAssembler, and I wanted the same assembler in
>>>>> load_at and store_at.
>>>>>
>>>>> So for now it is only used in InterpreterMacroAssembler, and I
>>>>> doubt that will change any time soon. I am hoping 32 bit support
>>>>> will be dropped before that, and the hack will go away. For now, I
>>>>> have added a virtual is_interpreter_masm() call that I use in an
>>>>> assert to make sure this is not accidentally used in the wrong
>>>>> context until 32 bit support is gone.
>>>> The comment plus the new assert satisfies my complaint.
>>>
>>> Thanks.
>>>
>>>>>> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>>>>>> 698 address
>>>>>> TemplateInterpreterGenerator::generate_Reference_get_entry(void) {
>>>>>>
>>>>>> Almost all the code here (and much of the commentary) was/is specific
>>>>>> to G1 (or SATB collectors).? Shouldn't it all be in the barrier_set's
>>>>>> load_at?? As it is now, if (say) we're using Parallel GC then I think
>>>>>> there's a bunch of additional code being generated and executed here
>>>>>> that wasn't present before.
>>>>> It is true that interpreter Reference.get() intrinsics with
>>>>> Parallel/CMS/Serial currently run a few instructions more than they
>>>>> need to pay for the abstraction. There is no doubt in my mind that
>>>>> this abstraction is worth the cost. Reference.get in the
>>>>> interpreter is not a hot path, and does not need to optimize every
>>>>> cycle.
>>>>>
>>>>> I changed the G1 comments to more general comments instead.
>>>> Good point on this not being a hot path.
>>>>
>>>> "Preserve the sender sp in case the pre-barrier
>>>> calls the runtime"
>>>>
>>>> s/the pre-barrier/a load barrier/
>>>
>>> Fixed.
>>>
>>>>>> src/hotspot/cpu/x86/gc/shared/modRefBarrierSetAssembler_x86.cpp
>>>>>> 86 void ModRefBarrierSetAssembler::store_at(MacroAssembler* masm,
>>>>>> DecoratorSet decorators, BasicType type,
>>>>>> 87??????????????????????????????????????? Address dst, Register
>>>>>> val, Register tmp1, Register tmp2) {
>>>>>> 88?? if (type == T_OBJECT || type == T_ARRAY) {
>>>>>> 89???? oop_store_at(masm, decorators, type, dst, val, tmp1, tmp2);
>>>>>> 90?? } else {
>>>>>> 91???? BarrierSetAssembler::store_at(masm, decorators, type, dst,
>>>>>> val, tmp1, tmp2);
>>>>>> 92?? }
>>>>>> 93 }
>>>>>>
>>>>>> Doesn't the conditional conversion from store_at to oop_store_at
>>>>>> actually indicate a bug in the caller? That is, calling store_at with
>>>>>> a oop (T_OBJECT or T_ARRAY) value seems like a bug, and should be
>>>>>> asserted against, rather than translating.
>>>>>>
>>>>>> And oop_store_at should assert that the value *is* an oop value.
>>>>>>
>>>>>> And should there be any verification that the decorators and the type
>>>>>> are consistent?
>>>>>>
>>>>>> But maybe I'm not understanding the protocol around oop_store_at?
>>>>>> There being no documentation, it seems entirely possible that I've
>>>>>> misunderstood something here.? Maybe I'm being confused by
>>>>>> similarities in naming with Access:: that don't hold?
>>>>> The confusion roots in that Access and BarrierSetAssembler are not
>>>>> structured exactly the same.
>>>>>
>>>>> Access provides store_at and oop_store_at. The reason for providing
>>>>> both of these, is that I could not safely infer whether the passed
>>>>> in parameters were oops or not without changing oop and narrowOop
>>>>> to always be value objects, which I did not dare to do as the
>>>>> generated code was worse.
>>>>>
>>>>> In BarrierSetAssembler, there is no such restriction. The type for
>>>>> the access is always passed in to store_at/load_at as BasicType. It
>>>>> is the responsibility of ModRefBarrierSetAssembler to filter away
>>>>> non-oop references, and call oop_store_at for relevant accesses for
>>>>> ModRef. This follows the same pattern that the arraycopy stubs
>>>>> used. This allows, e.g. CardTableModRef to only override
>>>>> oop_store_at. This is similar to how
>>>>> ModRefBarrierSet::AccessBarrier<decorators,
>>>>> BarrierSetT>::oop_store_in_heap calls the concrete barriersets for
>>>>> help generating that access. I hope this helps understanding the
>>>>> structuring.
>>>>>
>>>>> This is also the reason why G1BarrierSetAssembler::load_at checks
>>>>> whether it is an oop that is loaded or not, because loads are not
>>>>> riding on the ModRef layer, which only knows about oop stores.
>>>> I see. The naming congurence, along with my having glazed over the
>>>> fact that oop_store_at is protected rather than public, led me astray.
>>>> I don't have any better suggestions for naming.? I would have found
>>>> some comments describing the protocols helpful.
>>>
>>> I added some comments describing the idea behind ModRef.
>>>
>>>> Shouldn't ModRef::oop_store_at be pure virtual?? That would have
>>>> helped my understanding too.
>>>
>>> Sure. Fixed.
>>>
>>> Thanks,
>>> /Erik
>>
>
From david.holmes at oracle.com Wed Apr 11 09:26:16 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Apr 2018 19:26:16 +1000
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <84D1CF4E-B765-4FF5-9D6A-79703947FCE8@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<37e87dfc-1f1e-254b-a03e-8d8c1d4b0cef@oracle.com>
<84D1CF4E-B765-4FF5-9D6A-79703947FCE8@oracle.com>
Message-ID: <f82775fd-8b01-813a-b471-285b3323bbcb@oracle.com>
On 11/04/2018 6:01 PM, Kim Barrett wrote:
>> On Apr 10, 2018, at 9:34 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Robin,
>>
>> On 10/04/2018 10:18 PM, Robbin Ehn wrote:
>>> Hi all,
>>> We have moved the global-counter to a separate change-set. The global-counter
>>> uses a counter to determine current generation. Any reader needs to have a local
>>> counter for which generation is currently read. By increment the global-counter
>>> and scan for threads reading an old generation and wait for them to complete, we
>>> know when an old generation is not visible (no pre-existing reader). In RCU
>>> terms, this creates a grace-period. Making this mechanism suitable for a read-mostly scenario. In this initial change-set we scan JavaThreads and the VMThread.
>>
>> Sorry but I don't understand how this works. If a reader calls:
>>
>> 31 inline void GlobalCounter::critical_section_begin(Thread *thread) {
>> 32 assert(thread == Thread::current(), "must be current thread");
>> 33 assert(thread->is_VM_thread() || thread->is_Java_thread(), "must be VMThread or JavaThread");
>> 34 assert((*thread->get_rcu_counter() & COUNTER_ACTIVE) == 0x0, "nestled critical sections, not supported yet");
>> 35 volatile uintx gbl_cnt = OrderAccess::load_acquire(&_global_counter._counter);
>> 36 OrderAccess::release_store_fence(thread->get_rcu_counter(), gbl_cnt + 1);
>> 37 }
>>
>> and is preempted before the store at line 36, the writer will not see it and can go ahead and free the data used in the critical section. The reader does no validation of the counter value and so continues in to the critical section. Surely there has to be a handshake between the reader and writer, where the reader signals their intention to enter a critical section for generation X, then re-reads the generation count to check it has not changed. ??
>
> A writer updates its protected shared state and then waits for any
> readers that might see the previous value of that shared state. That
> is, any reader that is in the critical section (has the active bit set
> in its local counter) *and* entered before the shared state was
> updated. The latter is conservatively approximated by actually
> checking whether the reader entered the critical section before the
> wait started, with the wait ordered after the shared state update.
>
> The wait check implements the latter condition via a range test. If
> the reader entered before the wait, then it's local counter is "less
> than" the writer's updated counter. This is implementated by an
> unsigned subtract and checking for a large result. (With this
> implementation there is a limit on just how stale the reader can be; a
> reader must complete a critical section before max_uintx/4 writers
> wait.)
>
> When a writer updates protected shared state, increments the global
> counter, and then checks / waits for readers,
>
> (1) If a reader obtained a global counter value before that increment,
> but has not yet set its local state to indicate it is active, then the
> writer will not wait for it. But that's okay, because when the reader
> gets around to entering the critical region and examining the
> protected shared state, it is guaranteed not to see the old value of
> the protected shared state.
>
> (2) If a reader obtained a global counter value before that increment
> and marked itself active, then the writer will wait until the reader
> exits the critical section. The reader might see the old value of the
> protected shared state while in the critical region.
>
> (3) If a reader obtained a global counter value after that increment,
> then it is guaranteed not to see the old value of the protected shared
> state.
Sorry Kim but I can't quite follow all that. What is the "shared state"
you are referring to?
If a reader executes line 35 to read the current global counter and then
is preempted before storing that into thread->get_rcu_counter(), then
there is nothing for the writer to see - it has no knowledge of this
about-to-be reader.
David
>
From boris.ulasevich at bell-sw.com Wed Apr 11 09:40:13 2018
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Wed, 11 Apr 2018 12:40:13 +0300
Subject: RFR (S) 8201370: Minimal VM build fail
In-Reply-To: <d82ef3d3-2450-fc9c-bc16-63a036f6ac2a@oracle.com>
References: <ae347b5b-0d19-c9da-ff69-ed9f621643c2@bell-sw.com>
<d82ef3d3-2450-fc9c-bc16-63a036f6ac2a@oracle.com>
Message-ID: <b2087917-c2de-5dbd-4e02-a63acfd9705c@bell-sw.com>
Hi Stefan,
Yes, please sponsor my patch!
Thanks,
Boris
On 11.04.2018 11:07, Stefan Karlsson wrote:
> Hi again,
>
> I tried to compile the Minimal VM on my machine and had to apply the
> following patch to get it to work:
> http://cr.openjdk.java.net/~stefank/8201370/webrev.01/
>
> There's a few more changes, but nothing that seems non-trivial, so
> should be enough to get one Reviewer to review this.
>
> Do you want me to sponsor your patch and include the changes in my webrev?
>
> Thanks,
> StefanK
>
> On 2018-04-10 18:56, Boris Ulasevich wrote:
>> Hi all,
>>
>> Please review this patch to fix Minimal VM build fail caused by recent
>> GC headers updating.
>>
>> ??https://bugs.openjdk.java.net/browse/JDK-8201370
>> ??http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8201370/webrev.00/
>>
>> I will post separate review on arm32-specific changes.
>>
>> Thanks,
>> Boris
From per.liden at oracle.com Wed Apr 11 09:54:44 2018
From: per.liden at oracle.com (Per Liden)
Date: Wed, 11 Apr 2018 11:54:44 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <6b382992-af7a-fd67-1494-ad9301c110db@redhat.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<6b382992-af7a-fd67-1494-ad9301c110db@redhat.com>
Message-ID: <79ed21cd-ca37-f320-2207-b0e141c353ac@oracle.com>
Hi Aleksey,
On 04/10/2018 05:04 PM, Aleksey Shipilev wrote:
> On 04/10/2018 02:51 PM, Per Liden wrote:
>> A couple of commits were pushed, which causes conflicts with this change, so here's a rebased version:
>>
>> http://cr.openjdk.java.net/~pliden/8201318/webrev.1
>
> *) I wonder if we can make the special accessors for the composite offsets? E.g. instead of
>
>
> Address in_progress(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_offset() +
> SATBMarkQueue::byte_offset_of_active()));
> Address queue_index(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_offset() +
> SATBMarkQueue::byte_offset_of_index()));
> Address buffer(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_offset() +
> SATBMarkQueue::byte_offset_of_buf()));
>
> ...do:
>
> Address in_progress(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_active_offset()));
> Address queue_index(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_index_offset()));
> Address buffer(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_buf_offset()));
>
> That probably eliminates the header dependency on SATBMarkQueue/DirtyCardQueue from
> compiler/assembler stubs?
Done.
>
> *) Should these new methods accept JavaThread*? I.e. we are expecting the GC thread-local data only
> for JavaThreads, like attach/detach does?
>
> virtual void on_thread_create(Thread* thread);
> virtual void on_thread_destroy(Thread* thread);
> virtual void on_thread_attach(JavaThread* thread);
> virtual void on_thread_detach(JavaThread* thread);
The intention is that on_thread_create/destroy is called for all
threads, where as on_thread_attach/detach is only called for JavaThreads
(i.e. threads that are added to the "threads list"). There's been
discussions about treating all threads in the same way, i.e. they would
all be on the threads list and they would all receive attach/detach
calls. It's not clear yet if that is a good idea, but if that change is
made in the future, then we might want to revisit this interface.
>
> *) Wait, why do we call JVMCI members JavaThread_*?
>
> 64 static int JavaThread_satb_mark_queue_offset;
> 65 static int JavaThread_dirty_card_queue_offset;
Good catch! I switched to using the declare_constant_with_value()
construct, so these members are now gone.
>
> *) I would probably add assert(UseG1GC) to G1ThreadLocalData accessor methods
Done. Note however that we can't add asserts to the *_offset()
functions, as those will be called by Graal regardless of weather G1 is
enabled or not.
As discussed else where in this thread, the reason for keeping the
GCThreadLocalData member early in Thread is to allow GC barriers to
generate compact code. As Erik indicates, this may not matter that much
in the end, but I also don't think it hurts to let it sit there.
Also, I've shrunk GCThreadLocalData to 112 bytes, which is what G1
currently needs. ZGC currently uses 156 bytes (IIRC), but that's a
change that should stay the ZGC repo for now.
Updated webrev here:
Diff: http://cr.openjdk.java.net/~pliden/8201318/webrev.1vs2/
Full: http://cr.openjdk.java.net/~pliden/8201318/webrev.2/
Thanks for reviewing.
/Per
>
> Thanks,
> -Aleksey
>
From robbin.ehn at oracle.com Wed Apr 11 10:02:03 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Wed, 11 Apr 2018 12:02:03 +0200
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <f82775fd-8b01-813a-b471-285b3323bbcb@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<37e87dfc-1f1e-254b-a03e-8d8c1d4b0cef@oracle.com>
<84D1CF4E-B765-4FF5-9D6A-79703947FCE8@oracle.com>
<f82775fd-8b01-813a-b471-285b3323bbcb@oracle.com>
Message-ID: <0024711f-f8a4-5b72-6dae-5186952c4afe@oracle.com>
On 04/11/2018 11:26 AM, David Holmes wrote:
> On 11/04/2018 6:01 PM, Kim Barrett wrote:
>>> On Apr 10, 2018, at 9:34 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>
>>> Hi Robin,
>>>
>>> On 10/04/2018 10:18 PM, Robbin Ehn wrote:
>>>> Hi all,
>>>> We have moved the global-counter to a separate change-set. The global-counter
>>>> uses a counter to determine current generation. Any reader needs to have a
>>>> local
>>>> counter for which generation is currently read. By increment the global-counter
>>>> and scan for threads reading an old generation and wait for them to
>>>> complete, we
>>>> know when an old generation is not visible (no pre-existing reader). In RCU
>>>> terms, this creates a grace-period. Making this mechanism suitable for a
>>>> read-mostly scenario. In this initial change-set we scan JavaThreads and the
>>>> VMThread.
>>>
>>> Sorry but I don't understand how this works. If a reader calls:
>>>
>>> ? 31 inline void GlobalCounter::critical_section_begin(Thread *thread) {
>>> ? 32?? assert(thread == Thread::current(), "must be current thread");
>>> ? 33?? assert(thread->is_VM_thread() || thread->is_Java_thread(), "must be
>>> VMThread or JavaThread");
>>> ? 34?? assert((*thread->get_rcu_counter() & COUNTER_ACTIVE) == 0x0, "nestled
>>> critical sections, not supported yet");
>>> ? 35?? volatile uintx gbl_cnt =
>>> OrderAccess::load_acquire(&_global_counter._counter);
>>> ? 36?? OrderAccess::release_store_fence(thread->get_rcu_counter(), gbl_cnt + 1);
>>> ? 37 }
>>>
>>> and is preempted before the store at line 36, the writer will not see it and
>>> can go ahead and free the data used in the critical section. The reader does
>>> no validation of the counter value and so continues in to the critical
>>> section. Surely there has to be a handshake between the reader and writer,
>>> where the reader signals their intention to enter a critical section for
>>> generation X, then re-reads the generation count to check it has not changed. ??
>>
>> A writer updates its protected shared state and then waits for any
>> readers that might see the previous value of that shared state.? That
>> is, any reader that is in the critical section (has the active bit set
>> in its local counter) *and* entered before the shared state was
>> updated.? The latter is conservatively approximated by actually
>> checking whether the reader entered the critical section before the
>> wait started, with the wait ordered after the shared state update.
>>
>> The wait check implements the latter condition via a range test.? If
>> the reader entered before the wait, then it's local counter is "less
>> than" the writer's updated counter.? This is implementated by an
>> unsigned subtract and checking for a large result.? (With this
>> implementation there is a limit on just how stale the reader can be; a
>> reader must complete a critical section before max_uintx/4 writers
>> wait.)
>>
>> When a writer updates protected shared state, increments the global
>> counter, and then checks / waits for readers,
>>
>> (1) If a reader obtained a global counter value before that increment,
>> but has not yet set its local state to indicate it is active, then the
>> writer will not wait for it.? But that's okay, because when the reader
>> gets around to entering the critical region and examining the
>> protected shared state, it is guaranteed not to see the old value of
>> the protected shared state.
>>
>> (2) If a reader obtained a global counter value before that increment
>> and marked itself active, then the writer will wait until the reader
>> exits the critical section.? The reader might see the old value of the
>> protected shared state while in the critical region.
>>
>> (3) If a reader obtained a global counter value after that increment,
>> then it is guaranteed not to see the old value of the protected shared
>> state.
>
> Sorry Kim but I can't quite follow all that. What is the "shared state" you are
> referring to?
>
> If a reader executes line 35 to read the current global counter and then is
> preempted before storing that into thread->get_rcu_counter(), then there is
> nothing for the writer to see - it has no knowledge of this about-to-be reader.
Hi,
Thanks Kim for the explanation.
A generation X for reader A don't have to be identical with generation X for
reader B. We do not guarantee that a reader will see generation X, it might see
a newer one. But it will be 'stable'. In your context switch case the reader of
generation X might see generation X+(2*n_generation). The write-side do not know
what the reader actually sees, but it knows it _might_ see the memory for which
an ABA problem exists, therefore needs to wait with the reclamation.
In summary generation X is oldest possible visible generation for a reader.
If that helps David?
/Robbin
>
> David
>
>>
From robbin.ehn at oracle.com Wed Apr 11 10:07:50 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Wed, 11 Apr 2018 12:07:50 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <79ed21cd-ca37-f320-2207-b0e141c353ac@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<6b382992-af7a-fd67-1494-ad9301c110db@redhat.com>
<79ed21cd-ca37-f320-2207-b0e141c353ac@oracle.com>
Message-ID: <27e40ede-a919-b384-1fba-a346061265d2@oracle.com>
On 04/11/2018 11:54 AM, Per Liden wrote:
>
> Also, I've shrunk GCThreadLocalData to 112 bytes, which is what G1 currently
> needs. ZGC currently uses 156 bytes (IIRC), but that's a change that should stay
> the ZGC repo for now.
>
> Updated webrev here:
>
> Diff: http://cr.openjdk.java.net/~pliden/8201318/webrev.1vs2/
> Full: http://cr.openjdk.java.net/~pliden/8201318/webrev.2/
Looks good, reviewed.
Thanks, Robbin
>
> Thanks for reviewing.
>
> /Per
From shade at redhat.com Wed Apr 11 10:13:55 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 11 Apr 2018 12:13:55 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <79ed21cd-ca37-f320-2207-b0e141c353ac@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<6b382992-af7a-fd67-1494-ad9301c110db@redhat.com>
<79ed21cd-ca37-f320-2207-b0e141c353ac@oracle.com>
Message-ID: <8d84f53f-5587-79a1-4eae-5891efe71520@redhat.com>
On 04/11/2018 11:54 AM, Per Liden wrote:
>> *) Should these new methods accept JavaThread*? I.e. we are expecting the GC thread-local data only
>> for JavaThreads, like attach/detach does?
>>
>> ??? virtual void on_thread_create(Thread* thread);
>> ??? virtual void on_thread_destroy(Thread* thread);
>> ??? virtual void on_thread_attach(JavaThread* thread);
>> ??? virtual void on_thread_detach(JavaThread* thread);
>
> The intention is that on_thread_create/destroy is called for all threads, where as
> on_thread_attach/detach is only called for JavaThreads (i.e. threads that are added to the "threads
> list"). There's been discussions about treating all threads in the same way, i.e. they would all be
> on the threads list and they would all receive attach/detach calls. It's not clear yet if that is a
> good idea, but if that change is made in the future, then we might want to revisit this interface.
Ah, I understand. After sending the reply yesterday I realized they might be legit use cases where
you want to have GCTLD available e.g. for GC threads.
> As discussed else where in this thread, the reason for keeping the GCThreadLocalData member early in
> Thread is to allow GC barriers to generate compact code. As Erik indicates, this may not matter that
> much in the end, but I also don't think it hurts to let it sit there.
>
> Also, I've shrunk GCThreadLocalData to 112 bytes, which is what G1 currently needs. ZGC currently
> uses 156 bytes (IIRC), but that's a change that should stay the ZGC repo for now.
Oh. Haven't expected we need that much. This makes me think if we should implement some sort of
STATIC_ASSERT-based overflow checks? Not necessarily in this RFE.
> Updated webrev here:
>
> Diff: http://cr.openjdk.java.net/~pliden/8201318/webrev.1vs2/
> Full: http://cr.openjdk.java.net/~pliden/8201318/webrev.2/
Looks good!
Minor nits (no need to re-review):
*) I'll probably do another sweep and do a tad better indenting work. Compare:
2178 Address in_progress(Rthread, in_bytes(G1ThreadLocalData::satb_mark_queue_active_offset()));
2179 Address index(Rthread, in_bytes(G1ThreadLocalData::satb_mark_queue_index_offset()));
2180 Address buffer(Rthread, in_bytes(G1ThreadLocalData::satb_mark_queue_buffer_offset()));
vs.
2178 Address in_progress(Rthread, in_bytes(G1ThreadLocalData::satb_mark_queue_active_offset()));
2179 Address index(Rthread, in_bytes(G1ThreadLocalData::satb_mark_queue_index_offset()));
2180 Address buffer(Rthread, in_bytes(G1ThreadLocalData::satb_mark_queue_buffer_offset()));
*) Typos: "provied" -> "provided", "over head" -> "overhead".
// Thread local data area for GC-specific information. Each GC
// is free to decide the internal structure and contents of this
// area. It is represented as a 64-bit aligned opaque blob to
// avoid circular dependencies between Thread and all GCs. For
// the same reason, the size of the data area is hard coded to
// provied enough space for all current GCs. Adjust the size if
// needed, but avoid making it excessively large as it adds to
// the memory over head of creating a thread
*) Also mention the choice of <128 bytes? Like this:
// The size of GCTLD is kept under 128 bytes to let compilers encode
// accesses to GCTLD members with short offsets from the Thread.
-Aleksey
From martin.doerr at sap.com Wed Apr 11 10:28:01 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Wed, 11 Apr 2018 10:28:01 +0000
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <79ed21cd-ca37-f320-2207-b0e141c353ac@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<6b382992-af7a-fd67-1494-ad9301c110db@redhat.com>
<79ed21cd-ca37-f320-2207-b0e141c353ac@oracle.com>
Message-ID: <012f478eb667426db7a5103da3816eca@sap.com>
Hi Per,
thanks for simplifying the platform code. I just verified that it still builds on PPC64 and s390.
Best regards,
Martin
-----Original Message-----
From: Per Liden [mailto:per.liden at oracle.com]
Sent: Mittwoch, 11. April 2018 11:55
To: Aleksey Shipilev <shade at redhat.com>; Roman Kennke <rkennke at redhat.com>; Doerr, Martin <martin.doerr at sap.com>; hotspot-dev at openjdk.java.net; Robbin Ehn <robbin.ehn at oracle.com>; OSTERLUND,ERIK <erik.osterlund at oracle.com>
Subject: Re: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific data belonging to a thread
Hi Aleksey,
On 04/10/2018 05:04 PM, Aleksey Shipilev wrote:
> On 04/10/2018 02:51 PM, Per Liden wrote:
>> A couple of commits were pushed, which causes conflicts with this change, so here's a rebased version:
>>
>> http://cr.openjdk.java.net/~pliden/8201318/webrev.1
>
> *) I wonder if we can make the special accessors for the composite offsets? E.g. instead of
>
>
> Address in_progress(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_offset() +
> SATBMarkQueue::byte_offset_of_active()));
> Address queue_index(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_offset() +
> SATBMarkQueue::byte_offset_of_index()));
> Address buffer(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_offset() +
> SATBMarkQueue::byte_offset_of_buf()));
>
> ...do:
>
> Address in_progress(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_active_offset()));
> Address queue_index(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_index_offset()));
> Address buffer(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_buf_offset()));
>
> That probably eliminates the header dependency on SATBMarkQueue/DirtyCardQueue from
> compiler/assembler stubs?
Done.
>
> *) Should these new methods accept JavaThread*? I.e. we are expecting the GC thread-local data only
> for JavaThreads, like attach/detach does?
>
> virtual void on_thread_create(Thread* thread);
> virtual void on_thread_destroy(Thread* thread);
> virtual void on_thread_attach(JavaThread* thread);
> virtual void on_thread_detach(JavaThread* thread);
The intention is that on_thread_create/destroy is called for all
threads, where as on_thread_attach/detach is only called for JavaThreads
(i.e. threads that are added to the "threads list"). There's been
discussions about treating all threads in the same way, i.e. they would
all be on the threads list and they would all receive attach/detach
calls. It's not clear yet if that is a good idea, but if that change is
made in the future, then we might want to revisit this interface.
>
> *) Wait, why do we call JVMCI members JavaThread_*?
>
> 64 static int JavaThread_satb_mark_queue_offset;
> 65 static int JavaThread_dirty_card_queue_offset;
Good catch! I switched to using the declare_constant_with_value()
construct, so these members are now gone.
>
> *) I would probably add assert(UseG1GC) to G1ThreadLocalData accessor methods
Done. Note however that we can't add asserts to the *_offset()
functions, as those will be called by Graal regardless of weather G1 is
enabled or not.
As discussed else where in this thread, the reason for keeping the
GCThreadLocalData member early in Thread is to allow GC barriers to
generate compact code. As Erik indicates, this may not matter that much
in the end, but I also don't think it hurts to let it sit there.
Also, I've shrunk GCThreadLocalData to 112 bytes, which is what G1
currently needs. ZGC currently uses 156 bytes (IIRC), but that's a
change that should stay the ZGC repo for now.
Updated webrev here:
Diff: http://cr.openjdk.java.net/~pliden/8201318/webrev.1vs2/
Full: http://cr.openjdk.java.net/~pliden/8201318/webrev.2/
Thanks for reviewing.
/Per
>
> Thanks,
> -Aleksey
>
From david.holmes at oracle.com Wed Apr 11 10:57:15 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Apr 2018 20:57:15 +1000
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <0024711f-f8a4-5b72-6dae-5186952c4afe@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<37e87dfc-1f1e-254b-a03e-8d8c1d4b0cef@oracle.com>
<84D1CF4E-B765-4FF5-9D6A-79703947FCE8@oracle.com>
<f82775fd-8b01-813a-b471-285b3323bbcb@oracle.com>
<0024711f-f8a4-5b72-6dae-5186952c4afe@oracle.com>
Message-ID: <faad6465-6d76-a23d-be06-b55d9bef37c5@oracle.com>
Hi Robbin,
On 11/04/2018 8:02 PM, Robbin Ehn wrote:
> On 04/11/2018 11:26 AM, David Holmes wrote:
>> On 11/04/2018 6:01 PM, Kim Barrett wrote:
>>>> On Apr 10, 2018, at 9:34 PM, David Holmes <david.holmes at oracle.com>
>>>> wrote:
>>>>
>>>> Hi Robin,
>>>>
>>>> On 10/04/2018 10:18 PM, Robbin Ehn wrote:
>>>>> Hi all,
>>>>> We have moved the global-counter to a separate change-set. The
>>>>> global-counter
>>>>> uses a counter to determine current generation. Any reader needs to
>>>>> have a local
>>>>> counter for which generation is currently read. By increment the
>>>>> global-counter
>>>>> and scan for threads reading an old generation and wait for them to
>>>>> complete, we
>>>>> know when an old generation is not visible (no pre-existing
>>>>> reader). In RCU
>>>>> terms, this creates a grace-period. Making this mechanism suitable
>>>>> for a read-mostly scenario. In this initial change-set we scan
>>>>> JavaThreads and the VMThread.
>>>>
>>>> Sorry but I don't understand how this works. If a reader calls:
>>>>
>>>> ? 31 inline void GlobalCounter::critical_section_begin(Thread
>>>> *thread) {
>>>> ? 32?? assert(thread == Thread::current(), "must be current thread");
>>>> ? 33?? assert(thread->is_VM_thread() || thread->is_Java_thread(),
>>>> "must be VMThread or JavaThread");
>>>> ? 34?? assert((*thread->get_rcu_counter() & COUNTER_ACTIVE) == 0x0,
>>>> "nestled critical sections, not supported yet");
>>>> ? 35?? volatile uintx gbl_cnt =
>>>> OrderAccess::load_acquire(&_global_counter._counter);
>>>> ? 36?? OrderAccess::release_store_fence(thread->get_rcu_counter(),
>>>> gbl_cnt + 1);
>>>> ? 37 }
>>>>
>>>> and is preempted before the store at line 36, the writer will not
>>>> see it and can go ahead and free the data used in the critical
>>>> section. The reader does no validation of the counter value and so
>>>> continues in to the critical section. Surely there has to be a
>>>> handshake between the reader and writer, where the reader signals
>>>> their intention to enter a critical section for generation X, then
>>>> re-reads the generation count to check it has not changed. ??
>>>
>>> A writer updates its protected shared state and then waits for any
>>> readers that might see the previous value of that shared state.? That
>>> is, any reader that is in the critical section (has the active bit set
>>> in its local counter) *and* entered before the shared state was
>>> updated.? The latter is conservatively approximated by actually
>>> checking whether the reader entered the critical section before the
>>> wait started, with the wait ordered after the shared state update.
>>>
>>> The wait check implements the latter condition via a range test.? If
>>> the reader entered before the wait, then it's local counter is "less
>>> than" the writer's updated counter.? This is implementated by an
>>> unsigned subtract and checking for a large result.? (With this
>>> implementation there is a limit on just how stale the reader can be; a
>>> reader must complete a critical section before max_uintx/4 writers
>>> wait.)
>>>
>>> When a writer updates protected shared state, increments the global
>>> counter, and then checks / waits for readers,
>>>
>>> (1) If a reader obtained a global counter value before that increment,
>>> but has not yet set its local state to indicate it is active, then the
>>> writer will not wait for it.? But that's okay, because when the reader
>>> gets around to entering the critical region and examining the
>>> protected shared state, it is guaranteed not to see the old value of
>>> the protected shared state.
>>>
>>> (2) If a reader obtained a global counter value before that increment
>>> and marked itself active, then the writer will wait until the reader
>>> exits the critical section.? The reader might see the old value of the
>>> protected shared state while in the critical region.
>>>
>>> (3) If a reader obtained a global counter value after that increment,
>>> then it is guaranteed not to see the old value of the protected shared
>>> state.
>>
>> Sorry Kim but I can't quite follow all that. What is the "shared
>> state" you are referring to?
>>
>> If a reader executes line 35 to read the current global counter and
>> then is preempted before storing that into thread->get_rcu_counter(),
>> then there is nothing for the writer to see - it has no knowledge of
>> this about-to-be reader.
>
> Hi,
>
> Thanks Kim for the explanation.
>
> A generation X for reader A don't have to be identical with generation X
> for reader B. We do not guarantee that a reader will see generation X,
> it might see a newer one. But it will be 'stable'. In your context
> switch case the reader of generation X might see generation
> X+(2*n_generation). The write-side do not know what the reader actually
> sees, but it knows it _might_ see the memory for which an ABA problem
> exists, therefore needs to wait with the reclamation.
>
> In summary generation X is oldest possible visible generation for a reader.
>
> If that helps David?
Sorry no, I don't understand what this counter is doing at all. I feel I
need to see what is between the begin/end critical section for this to
make any sense to me. And to see what the writer actually does.
David
-----
> /Robbin
>
>>
>> David
>>
>>>
From robbin.ehn at oracle.com Wed Apr 11 11:38:19 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Wed, 11 Apr 2018 13:38:19 +0200
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <faad6465-6d76-a23d-be06-b55d9bef37c5@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<37e87dfc-1f1e-254b-a03e-8d8c1d4b0cef@oracle.com>
<84D1CF4E-B765-4FF5-9D6A-79703947FCE8@oracle.com>
<f82775fd-8b01-813a-b471-285b3323bbcb@oracle.com>
<0024711f-f8a4-5b72-6dae-5186952c4afe@oracle.com>
<faad6465-6d76-a23d-be06-b55d9bef37c5@oracle.com>
Message-ID: <7a26ff66-b9be-48aa-0956-29adeef87628@oracle.com>
Hi,
On 04/11/2018 12:57 PM, David Holmes wrote:
>
> Sorry no, I don't understand what this counter is doing at all. I feel I need to
> see what is between the begin/end critical section for this to make any sense to
> me. And to see what the writer actually does.
From gtest:
Read side do:
49 GlobalCounter::critical_section_begin(this);
50 volatile TestData* test = OrderAccess::load_acquire(_test);
51 long value = OrderAccess::load_acquire(&test->test_value);
52 ASSERT_EQ(value, GOOD);
53 GlobalCounter::critical_section_end(this);
Write side do:
101 volatile TestData* free_tmp = test;
102 tmp = new TestData();
103 tmp->test_value = GOOD;
104 OrderAccess::release_store(&test, tmp);
105 GlobalCounter::write_synchronize();
106 free_tmp->test_value = BAD;
107 delete free_tmp;
If a reader is context switch between line 50 and 51, it will have a cached
value of the pointer "_test", thus no one should free it.
Before freeing the writer calls write_synchronize which guarantees that no
reader can see the old pointer and can then free it.
If the reader is context switch inside critical_section_begin this does not
matter since the fence in critical_section_begin prohibits the load of test
pointer from floating up. If write_synchronize is done before this reader gets
back on CPU it will see the new value but have an counter of an old generation.
If it gets back on CPU before write_synchronize I will see the old pointer.
If we call the pointer values TEST_gen_1, TEST_gen_2, ...
test_pointer starts equal to TEST_gen_1 and generation starts at 1.
Writer: tmp_pointer = test_pointer
Writer: test_pointer = TEST_gen_2
Reader: load global counter (fetches 1)
Reader: context switched out
Writer: write_synchronized generation = 2, and do not see the reader.
Reader: store local counter to 1 // critical section begin
Reader: load test_pointer (TEST_gen_2) // This load will always happen *after*
the store to local counter
Writer: free tmp_pointer (TEST_gen_1) // ABA safe
Writer: tmp_pointer = test_pointer
Writer: test_pointer = TEST_gen_3
Writer: write_synchronized generation = 3, and _sees_ on old reader => wait.
Reader: store local counter OFF // critical section end
Writer: write_synchronized now finishes.
Writer: free tmp_pointer (TEST_gen_2) // ABA safe
/Robbin
>
> David
> -----
From coleen.phillimore at oracle.com Wed Apr 11 11:51:17 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 11 Apr 2018 07:51:17 -0400
Subject: RFR: 8199417: Modularize interpreter GC barriers
In-Reply-To: <9b622ca3-967d-f475-a380-1693f3448d00@redhat.com>
References: <5AB8BDF9.4050106@oracle.com>
<3FFD79AD-84B8-4E9E-98E3-47ACBA01D91F@oracle.com>
<5AC4D555.9040800@oracle.com>
<80295FD9-254E-4670-AB47-E2A4B36C4143@oracle.com>
<b6cdaf49-4715-7193-51ff-c3c19581d497@oracle.com>
<3a0f68a9-7eee-c8c2-d3bf-288af3bfcfca@oracle.com>
<5ACDCDF6.3000804@oracle.com>
<9b622ca3-967d-f475-a380-1693f3448d00@redhat.com>
Message-ID: <63cff997-ad87-7b90-1d88-90e00ba20c69@oracle.com>
On 4/11/18 5:05 AM, Roman Kennke wrote:
> Hi Erik,
>> I have no plans to update the wrappers calling BarrierSetAssembler on
>> PPC, S390 and AArch64 code.
>>
>> 1) I simply can't check if my changes work or not on those platforms.
>> 2) This is an interface between the platform specific code and the GC.
>> So I feel like the chosen wrapper to call into BarrierSetAssembler is up
>> to the maintainers of those platforms, and it feels like it is not my
>> call to tell other maintainers what wrapper functions they should use.
>>
>> So basically, since I can't test on those platforms, I think it is up to
>> Martin Doerr and Roman Kennke to adopt the wrapper function if they like
>> it. And I think that is easiest to do as separate RFEs.
> This sounds reasonable.
Okay, I agree.? That sounds reasonable.? I've reviewed the interpreter
pieces.
Coleen
>
> Thanks, Roman
>
>
>> Thanks,
>> /Erik
>>
>>
>> On 2018-04-11 00:49, coleen.phillimore at oracle.com wrote:
>>>
>>> On 4/9/18 4:05 PM, Erik ?sterlund wrote:
>>>> Hi Kim,
>>>>
>>>> Thank you for looking at this. Since this was well received, I went
>>>> ahead and implemented something similar on SPARC as well. Also added
>>>> support for storing roots (rather than asserting that stores are in
>>>> the heap only), just in case we need it in the future.
>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.02/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp.udiff.html
>>>
>>>
>>> :( you're not going to do all of them since you changed this code
>>> too??? It would make it easier for us to pattern match for changes to
>>> other platforms if you did, since we have no way of testing these
>>> platforms.
>>>
>>> The sparc changes look reasonable too.
>>>
>>> Coleen
>>>
>>>> Full webrev:
>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.02/
>>>>
>>>> Incremental webrev:
>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01_02/
>>>>
>>>> On 2018-04-06 01:38, Kim Barrett wrote:
>>>>>> On Apr 4, 2018, at 9:38 AM, Erik ?sterlund
>>>>>> <erik.osterlund at oracle.com> wrote:
>>>>>>
>>>>>> Hi Kim,
>>>>>>
>>>>>> Thank you for reviewing this.
>>>>>>
>>>>>> I have made a new webrev with proposed changes to the x86/x64 code
>>>>>> reflecting the concerns you and Coleen have.
>>>>>> I thought we should settle for something we like in the x86/x64
>>>>>> code before going ahead and changing the other platforms too much
>>>>>> (I don't want to bug Martin and Roman too much before).
>>>>>>
>>>>>> New full webrev:
>>>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01/
>>>>>>
>>>>>> Incremental:
>>>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.00_01/
>>>>> This looks better, and you've mostly answered the issues I've raised
>>>>> so far.? Some further discussion inline below.
>>>> I'm glad to hear that.
>>>>
>>>>> Other things have come up and I'm not going to be able to properly get
>>>>> back to this soon; don't hold up on my account, just drop me as a
>>>>> reviewer.
>>>>>
>>>>>> On 2018-04-01 05:12, Kim Barrett wrote:
>>>>>>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>>>>>>> 364 #ifndef _LP64
>>>>>>> 365?? InterpreterMacroAssembler *imasm =
>>>>>>> static_cast<InterpreterMacroAssembler*>(masm);
>>>>>>> 366 #endif
>>>>>>>
>>>>>>> In the old code, the function received an InterpreterMacroAssembler*.
>>>>>>>
>>>>>>> What is there about this context that lets us know the downcast is
>>>>>>> safe here?? Is oop_store_at only ever called with an IMA*? If so,
>>>>>>> then why isn't that the parameter type.? If not, then what?
>>>>>> Yes, this is indeed only used by the InterpreterMacroAssembler. But
>>>>>> I wanted the interface to use MacroAssembler. Why?
>>>>>>
>>>>>> 1) It's only 32 bit x86 that relies on this property, and I hope it
>>>>>> will go away soon, and the save bcp hack with it.
>>>>>> 2) previous load_heap_oop is used not only in the
>>>>>> InterpreterMacroAssembler, and I wanted the same assembler in
>>>>>> load_at and store_at.
>>>>>>
>>>>>> So for now it is only used in InterpreterMacroAssembler, and I
>>>>>> doubt that will change any time soon. I am hoping 32 bit support
>>>>>> will be dropped before that, and the hack will go away. For now, I
>>>>>> have added a virtual is_interpreter_masm() call that I use in an
>>>>>> assert to make sure this is not accidentally used in the wrong
>>>>>> context until 32 bit support is gone.
>>>>> The comment plus the new assert satisfies my complaint.
>>>> Thanks.
>>>>
>>>>>>> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>>>>>>> 698 address
>>>>>>> TemplateInterpreterGenerator::generate_Reference_get_entry(void) {
>>>>>>>
>>>>>>> Almost all the code here (and much of the commentary) was/is specific
>>>>>>> to G1 (or SATB collectors).? Shouldn't it all be in the barrier_set's
>>>>>>> load_at?? As it is now, if (say) we're using Parallel GC then I think
>>>>>>> there's a bunch of additional code being generated and executed here
>>>>>>> that wasn't present before.
>>>>>> It is true that interpreter Reference.get() intrinsics with
>>>>>> Parallel/CMS/Serial currently run a few instructions more than they
>>>>>> need to pay for the abstraction. There is no doubt in my mind that
>>>>>> this abstraction is worth the cost. Reference.get in the
>>>>>> interpreter is not a hot path, and does not need to optimize every
>>>>>> cycle.
>>>>>>
>>>>>> I changed the G1 comments to more general comments instead.
>>>>> Good point on this not being a hot path.
>>>>>
>>>>> "Preserve the sender sp in case the pre-barrier
>>>>> calls the runtime"
>>>>>
>>>>> s/the pre-barrier/a load barrier/
>>>> Fixed.
>>>>
>>>>>>> src/hotspot/cpu/x86/gc/shared/modRefBarrierSetAssembler_x86.cpp
>>>>>>> 86 void ModRefBarrierSetAssembler::store_at(MacroAssembler* masm,
>>>>>>> DecoratorSet decorators, BasicType type,
>>>>>>> 87??????????????????????????????????????? Address dst, Register
>>>>>>> val, Register tmp1, Register tmp2) {
>>>>>>> 88?? if (type == T_OBJECT || type == T_ARRAY) {
>>>>>>> 89???? oop_store_at(masm, decorators, type, dst, val, tmp1, tmp2);
>>>>>>> 90?? } else {
>>>>>>> 91???? BarrierSetAssembler::store_at(masm, decorators, type, dst,
>>>>>>> val, tmp1, tmp2);
>>>>>>> 92?? }
>>>>>>> 93 }
>>>>>>>
>>>>>>> Doesn't the conditional conversion from store_at to oop_store_at
>>>>>>> actually indicate a bug in the caller? That is, calling store_at with
>>>>>>> a oop (T_OBJECT or T_ARRAY) value seems like a bug, and should be
>>>>>>> asserted against, rather than translating.
>>>>>>>
>>>>>>> And oop_store_at should assert that the value *is* an oop value.
>>>>>>>
>>>>>>> And should there be any verification that the decorators and the type
>>>>>>> are consistent?
>>>>>>>
>>>>>>> But maybe I'm not understanding the protocol around oop_store_at?
>>>>>>> There being no documentation, it seems entirely possible that I've
>>>>>>> misunderstood something here.? Maybe I'm being confused by
>>>>>>> similarities in naming with Access:: that don't hold?
>>>>>> The confusion roots in that Access and BarrierSetAssembler are not
>>>>>> structured exactly the same.
>>>>>>
>>>>>> Access provides store_at and oop_store_at. The reason for providing
>>>>>> both of these, is that I could not safely infer whether the passed
>>>>>> in parameters were oops or not without changing oop and narrowOop
>>>>>> to always be value objects, which I did not dare to do as the
>>>>>> generated code was worse.
>>>>>>
>>>>>> In BarrierSetAssembler, there is no such restriction. The type for
>>>>>> the access is always passed in to store_at/load_at as BasicType. It
>>>>>> is the responsibility of ModRefBarrierSetAssembler to filter away
>>>>>> non-oop references, and call oop_store_at for relevant accesses for
>>>>>> ModRef. This follows the same pattern that the arraycopy stubs
>>>>>> used. This allows, e.g. CardTableModRef to only override
>>>>>> oop_store_at. This is similar to how
>>>>>> ModRefBarrierSet::AccessBarrier<decorators,
>>>>>> BarrierSetT>::oop_store_in_heap calls the concrete barriersets for
>>>>>> help generating that access. I hope this helps understanding the
>>>>>> structuring.
>>>>>>
>>>>>> This is also the reason why G1BarrierSetAssembler::load_at checks
>>>>>> whether it is an oop that is loaded or not, because loads are not
>>>>>> riding on the ModRef layer, which only knows about oop stores.
>>>>> I see. The naming congurence, along with my having glazed over the
>>>>> fact that oop_store_at is protected rather than public, led me astray.
>>>>> I don't have any better suggestions for naming.? I would have found
>>>>> some comments describing the protocols helpful.
>>>> I added some comments describing the idea behind ModRef.
>>>>
>>>>> Shouldn't ModRef::oop_store_at be pure virtual?? That would have
>>>>> helped my understanding too.
>>>> Sure. Fixed.
>>>>
>>>> Thanks,
>>>> /Erik
>
From erik.osterlund at oracle.com Wed Apr 11 11:56:45 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Wed, 11 Apr 2018 13:56:45 +0200
Subject: RFR: 8199417: Modularize interpreter GC barriers
In-Reply-To: <63cff997-ad87-7b90-1d88-90e00ba20c69@oracle.com>
References: <5AB8BDF9.4050106@oracle.com>
<3FFD79AD-84B8-4E9E-98E3-47ACBA01D91F@oracle.com>
<5AC4D555.9040800@oracle.com>
<80295FD9-254E-4670-AB47-E2A4B36C4143@oracle.com>
<b6cdaf49-4715-7193-51ff-c3c19581d497@oracle.com>
<3a0f68a9-7eee-c8c2-d3bf-288af3bfcfca@oracle.com>
<5ACDCDF6.3000804@oracle.com>
<9b622ca3-967d-f475-a380-1693f3448d00@redhat.com>
<63cff997-ad87-7b90-1d88-90e00ba20c69@oracle.com>
Message-ID: <5ACDF7FD.8060302@oracle.com>
Hi Coleen,
Thanks for the review.
/Erik
On 2018-04-11 13:51, coleen.phillimore at oracle.com wrote:
>
>
> On 4/11/18 5:05 AM, Roman Kennke wrote:
>> Hi Erik,
>>> I have no plans to update the wrappers calling BarrierSetAssembler on
>>> PPC, S390 and AArch64 code.
>>>
>>> 1) I simply can't check if my changes work or not on those platforms.
>>> 2) This is an interface between the platform specific code and the GC.
>>> So I feel like the chosen wrapper to call into BarrierSetAssembler
>>> is up
>>> to the maintainers of those platforms, and it feels like it is not my
>>> call to tell other maintainers what wrapper functions they should use.
>>>
>>> So basically, since I can't test on those platforms, I think it is
>>> up to
>>> Martin Doerr and Roman Kennke to adopt the wrapper function if they
>>> like
>>> it. And I think that is easiest to do as separate RFEs.
>> This sounds reasonable.
>
> Okay, I agree. That sounds reasonable. I've reviewed the interpreter
> pieces.
> Coleen
>
>>
>> Thanks, Roman
>>
>>
>>> Thanks,
>>> /Erik
>>>
>>>
>>> On 2018-04-11 00:49, coleen.phillimore at oracle.com wrote:
>>>>
>>>> On 4/9/18 4:05 PM, Erik ?sterlund wrote:
>>>>> Hi Kim,
>>>>>
>>>>> Thank you for looking at this. Since this was well received, I went
>>>>> ahead and implemented something similar on SPARC as well. Also added
>>>>> support for storing roots (rather than asserting that stores are in
>>>>> the heap only), just in case we need it in the future.
>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.02/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp.udiff.html
>>>>
>>>>
>>>>
>>>> :( you're not going to do all of them since you changed this code
>>>> too? It would make it easier for us to pattern match for changes to
>>>> other platforms if you did, since we have no way of testing these
>>>> platforms.
>>>>
>>>> The sparc changes look reasonable too.
>>>>
>>>> Coleen
>>>>
>>>>> Full webrev:
>>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.02/
>>>>>
>>>>> Incremental webrev:
>>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01_02/
>>>>>
>>>>> On 2018-04-06 01:38, Kim Barrett wrote:
>>>>>>> On Apr 4, 2018, at 9:38 AM, Erik ?sterlund
>>>>>>> <erik.osterlund at oracle.com> wrote:
>>>>>>>
>>>>>>> Hi Kim,
>>>>>>>
>>>>>>> Thank you for reviewing this.
>>>>>>>
>>>>>>> I have made a new webrev with proposed changes to the x86/x64 code
>>>>>>> reflecting the concerns you and Coleen have.
>>>>>>> I thought we should settle for something we like in the x86/x64
>>>>>>> code before going ahead and changing the other platforms too much
>>>>>>> (I don't want to bug Martin and Roman too much before).
>>>>>>>
>>>>>>> New full webrev:
>>>>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01/
>>>>>>>
>>>>>>> Incremental:
>>>>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.00_01/
>>>>>> This looks better, and you've mostly answered the issues I've raised
>>>>>> so far. Some further discussion inline below.
>>>>> I'm glad to hear that.
>>>>>
>>>>>> Other things have come up and I'm not going to be able to
>>>>>> properly get
>>>>>> back to this soon; don't hold up on my account, just drop me as a
>>>>>> reviewer.
>>>>>>
>>>>>>> On 2018-04-01 05:12, Kim Barrett wrote:
>>>>>>>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>>>>>>>> 364 #ifndef _LP64
>>>>>>>> 365 InterpreterMacroAssembler *imasm =
>>>>>>>> static_cast<InterpreterMacroAssembler*>(masm);
>>>>>>>> 366 #endif
>>>>>>>>
>>>>>>>> In the old code, the function received an
>>>>>>>> InterpreterMacroAssembler*.
>>>>>>>>
>>>>>>>> What is there about this context that lets us know the downcast is
>>>>>>>> safe here? Is oop_store_at only ever called with an IMA*? If so,
>>>>>>>> then why isn't that the parameter type. If not, then what?
>>>>>>> Yes, this is indeed only used by the InterpreterMacroAssembler. But
>>>>>>> I wanted the interface to use MacroAssembler. Why?
>>>>>>>
>>>>>>> 1) It's only 32 bit x86 that relies on this property, and I hope it
>>>>>>> will go away soon, and the save bcp hack with it.
>>>>>>> 2) previous load_heap_oop is used not only in the
>>>>>>> InterpreterMacroAssembler, and I wanted the same assembler in
>>>>>>> load_at and store_at.
>>>>>>>
>>>>>>> So for now it is only used in InterpreterMacroAssembler, and I
>>>>>>> doubt that will change any time soon. I am hoping 32 bit support
>>>>>>> will be dropped before that, and the hack will go away. For now, I
>>>>>>> have added a virtual is_interpreter_masm() call that I use in an
>>>>>>> assert to make sure this is not accidentally used in the wrong
>>>>>>> context until 32 bit support is gone.
>>>>>> The comment plus the new assert satisfies my complaint.
>>>>> Thanks.
>>>>>
>>>>>>>> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>>>>>>>> 698 address
>>>>>>>> TemplateInterpreterGenerator::generate_Reference_get_entry(void) {
>>>>>>>>
>>>>>>>> Almost all the code here (and much of the commentary) was/is
>>>>>>>> specific
>>>>>>>> to G1 (or SATB collectors). Shouldn't it all be in the
>>>>>>>> barrier_set's
>>>>>>>> load_at? As it is now, if (say) we're using Parallel GC then I
>>>>>>>> think
>>>>>>>> there's a bunch of additional code being generated and executed
>>>>>>>> here
>>>>>>>> that wasn't present before.
>>>>>>> It is true that interpreter Reference.get() intrinsics with
>>>>>>> Parallel/CMS/Serial currently run a few instructions more than they
>>>>>>> need to pay for the abstraction. There is no doubt in my mind that
>>>>>>> this abstraction is worth the cost. Reference.get in the
>>>>>>> interpreter is not a hot path, and does not need to optimize every
>>>>>>> cycle.
>>>>>>>
>>>>>>> I changed the G1 comments to more general comments instead.
>>>>>> Good point on this not being a hot path.
>>>>>>
>>>>>> "Preserve the sender sp in case the pre-barrier
>>>>>> calls the runtime"
>>>>>>
>>>>>> s/the pre-barrier/a load barrier/
>>>>> Fixed.
>>>>>
>>>>>>>> src/hotspot/cpu/x86/gc/shared/modRefBarrierSetAssembler_x86.cpp
>>>>>>>> 86 void ModRefBarrierSetAssembler::store_at(MacroAssembler* masm,
>>>>>>>> DecoratorSet decorators, BasicType type,
>>>>>>>> 87 Address dst, Register
>>>>>>>> val, Register tmp1, Register tmp2) {
>>>>>>>> 88 if (type == T_OBJECT || type == T_ARRAY) {
>>>>>>>> 89 oop_store_at(masm, decorators, type, dst, val, tmp1, tmp2);
>>>>>>>> 90 } else {
>>>>>>>> 91 BarrierSetAssembler::store_at(masm, decorators, type, dst,
>>>>>>>> val, tmp1, tmp2);
>>>>>>>> 92 }
>>>>>>>> 93 }
>>>>>>>>
>>>>>>>> Doesn't the conditional conversion from store_at to oop_store_at
>>>>>>>> actually indicate a bug in the caller? That is, calling
>>>>>>>> store_at with
>>>>>>>> a oop (T_OBJECT or T_ARRAY) value seems like a bug, and should be
>>>>>>>> asserted against, rather than translating.
>>>>>>>>
>>>>>>>> And oop_store_at should assert that the value *is* an oop value.
>>>>>>>>
>>>>>>>> And should there be any verification that the decorators and
>>>>>>>> the type
>>>>>>>> are consistent?
>>>>>>>>
>>>>>>>> But maybe I'm not understanding the protocol around oop_store_at?
>>>>>>>> There being no documentation, it seems entirely possible that I've
>>>>>>>> misunderstood something here. Maybe I'm being confused by
>>>>>>>> similarities in naming with Access:: that don't hold?
>>>>>>> The confusion roots in that Access and BarrierSetAssembler are not
>>>>>>> structured exactly the same.
>>>>>>>
>>>>>>> Access provides store_at and oop_store_at. The reason for providing
>>>>>>> both of these, is that I could not safely infer whether the passed
>>>>>>> in parameters were oops or not without changing oop and narrowOop
>>>>>>> to always be value objects, which I did not dare to do as the
>>>>>>> generated code was worse.
>>>>>>>
>>>>>>> In BarrierSetAssembler, there is no such restriction. The type for
>>>>>>> the access is always passed in to store_at/load_at as BasicType. It
>>>>>>> is the responsibility of ModRefBarrierSetAssembler to filter away
>>>>>>> non-oop references, and call oop_store_at for relevant accesses for
>>>>>>> ModRef. This follows the same pattern that the arraycopy stubs
>>>>>>> used. This allows, e.g. CardTableModRef to only override
>>>>>>> oop_store_at. This is similar to how
>>>>>>> ModRefBarrierSet::AccessBarrier<decorators,
>>>>>>> BarrierSetT>::oop_store_in_heap calls the concrete barriersets for
>>>>>>> help generating that access. I hope this helps understanding the
>>>>>>> structuring.
>>>>>>>
>>>>>>> This is also the reason why G1BarrierSetAssembler::load_at checks
>>>>>>> whether it is an oop that is loaded or not, because loads are not
>>>>>>> riding on the ModRef layer, which only knows about oop stores.
>>>>>> I see. The naming congurence, along with my having glazed over the
>>>>>> fact that oop_store_at is protected rather than public, led me
>>>>>> astray.
>>>>>> I don't have any better suggestions for naming. I would have found
>>>>>> some comments describing the protocols helpful.
>>>>> I added some comments describing the idea behind ModRef.
>>>>>
>>>>>> Shouldn't ModRef::oop_store_at be pure virtual? That would have
>>>>>> helped my understanding too.
>>>>> Sure. Fixed.
>>>>>
>>>>> Thanks,
>>>>> /Erik
>>
>
From david.holmes at oracle.com Wed Apr 11 12:03:01 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Apr 2018 22:03:01 +1000
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <7a26ff66-b9be-48aa-0956-29adeef87628@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<37e87dfc-1f1e-254b-a03e-8d8c1d4b0cef@oracle.com>
<84D1CF4E-B765-4FF5-9D6A-79703947FCE8@oracle.com>
<f82775fd-8b01-813a-b471-285b3323bbcb@oracle.com>
<0024711f-f8a4-5b72-6dae-5186952c4afe@oracle.com>
<faad6465-6d76-a23d-be06-b55d9bef37c5@oracle.com>
<7a26ff66-b9be-48aa-0956-29adeef87628@oracle.com>
Message-ID: <134d9c17-0c54-5cf1-e80b-e64b9a15dfb8@oracle.com>
On 11/04/2018 9:38 PM, Robbin Ehn wrote:
> Hi,
>
> On 04/11/2018 12:57 PM, David Holmes wrote:
>>
>> Sorry no, I don't understand what this counter is doing at all. I feel
>> I need to see what is between the begin/end critical section for this
>> to make any sense to me. And to see what the writer actually does.
>
> From gtest:
Thanks for that. Okay I have a better sense of how the access to the
data completes the handshake.
Does the naming/terminology come from some existing mechanism? I find it
somewhat odd and not really descriptive of the operation..
Thanks,
David
> Read side do:
> ? 49?????? GlobalCounter::critical_section_begin(this);
> ? 50?????? volatile TestData* test = OrderAccess::load_acquire(_test);
> ? 51?????? long value = OrderAccess::load_acquire(&test->test_value);
> ? 52?????? ASSERT_EQ(value, GOOD);
> ? 53?????? GlobalCounter::critical_section_end(this);
> Write side do:
> ?101???????? volatile TestData* free_tmp = test;
> ?102???????? tmp = new TestData();
> ?103???????? tmp->test_value = GOOD;
> ?104???????? OrderAccess::release_store(&test, tmp);
> ?105???????? GlobalCounter::write_synchronize();
> ?106???????? free_tmp->test_value = BAD;
> ?107???????? delete free_tmp;
>
> If a reader is context switch between line 50 and 51, it will have a
> cached value of the pointer "_test", thus no one should free it.
>
> Before freeing the writer calls write_synchronize which guarantees that
> no reader can see the old pointer and can then free it.
>
> If the reader is context switch inside critical_section_begin this does
> not matter since the fence in critical_section_begin prohibits the load
> of test pointer from floating up. If write_synchronize is done before
> this reader gets back on CPU it will see the new value but have an
> counter of an old generation.
> If it gets back on CPU before write_synchronize I will see the old pointer.
>
> If we call the pointer values TEST_gen_1, TEST_gen_2, ...
> test_pointer starts equal to TEST_gen_1 and generation starts at 1.
>
> Writer: tmp_pointer = test_pointer
> Writer: test_pointer = TEST_gen_2
> Reader: load global counter (fetches 1)
> Reader: context switched out
> Writer: write_synchronized generation = 2, and do not see the reader.
> Reader: store local counter to 1 // critical section begin
> Reader: load test_pointer (TEST_gen_2) // This load will always happen
> *after* the store to local counter
> Writer: free tmp_pointer (TEST_gen_1) // ABA safe
>
> Writer: tmp_pointer = test_pointer
> Writer: test_pointer = TEST_gen_3
> Writer: write_synchronized generation = 3, and _sees_ on old reader =>
> wait.
> Reader: store local counter OFF // critical section end
> Writer: write_synchronized now finishes.
> Writer: free tmp_pointer (TEST_gen_2) // ABA safe
>
> /Robbin
>
>>
>> David
>> -----
From stefan.karlsson at oracle.com Wed Apr 11 12:21:21 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 11 Apr 2018 14:21:21 +0200
Subject: RFR (S) 8201370: Minimal VM build fail
In-Reply-To: <b2087917-c2de-5dbd-4e02-a63acfd9705c@bell-sw.com>
References: <ae347b5b-0d19-c9da-ff69-ed9f621643c2@bell-sw.com>
<d82ef3d3-2450-fc9c-bc16-63a036f6ac2a@oracle.com>
<b2087917-c2de-5dbd-4e02-a63acfd9705c@bell-sw.com>
Message-ID: <6c5998a1-f92b-fd2c-a9ac-8e5767166a31@oracle.com>
On 2018-04-11 11:40, Boris Ulasevich wrote:
> Hi Stefan,
>
> ? Yes, please sponsor my patch!
I've pushed your change here:
http://hg.openjdk.java.net/jdk/hs/rev/e3e66c178518
I took the liberty of sorting the moved includes and updating the bug
report title to better reflect the RFE.
This is the follow-up change to fix Minimal VM builds on my Linux x64
machine:
http://hg.openjdk.java.net/jdk/hs/rev/b17256b5c047
Cheers,
StefanK
>
> Thanks,
> Boris
>
> On 11.04.2018 11:07, Stefan Karlsson wrote:
>> Hi again,
>>
>> I tried to compile the Minimal VM on my machine and had to apply the
>> following patch to get it to work:
>> http://cr.openjdk.java.net/~stefank/8201370/webrev.01/
>>
>> There's a few more changes, but nothing that seems non-trivial, so
>> should be enough to get one Reviewer to review this.
>>
>> Do you want me to sponsor your patch and include the changes in my
>> webrev?
>>
>> Thanks,
>> StefanK
>>
>> On 2018-04-10 18:56, Boris Ulasevich wrote:
>>> Hi all,
>>>
>>> Please review this patch to fix Minimal VM build fail caused by
>>> recent GC headers updating.
>>>
>>> ??https://bugs.openjdk.java.net/browse/JDK-8201370
>>> ??http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8201370/webrev.00/
>>>
>>> I will post separate review on arm32-specific changes.
>>>
>>> Thanks,
>>> Boris
From erik.osterlund at oracle.com Wed Apr 11 12:30:55 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Wed, 11 Apr 2018 14:30:55 +0200
Subject: RFR: 8199417: Modularize interpreter GC barriers
In-Reply-To: <63cff997-ad87-7b90-1d88-90e00ba20c69@oracle.com>
References: <5AB8BDF9.4050106@oracle.com>
<3FFD79AD-84B8-4E9E-98E3-47ACBA01D91F@oracle.com>
<5AC4D555.9040800@oracle.com>
<80295FD9-254E-4670-AB47-E2A4B36C4143@oracle.com>
<b6cdaf49-4715-7193-51ff-c3c19581d497@oracle.com>
<3a0f68a9-7eee-c8c2-d3bf-288af3bfcfca@oracle.com>
<5ACDCDF6.3000804@oracle.com>
<9b622ca3-967d-f475-a380-1693f3448d00@redhat.com>
<63cff997-ad87-7b90-1d88-90e00ba20c69@oracle.com>
Message-ID: <5ACDFFFF.5010002@oracle.com>
Hi,
After rebasing, I found that I needed to add one line to suppress a
false positive warning since the new compiler upgrades:
ifeq ($(TOOLCHAIN_TYPE), gcc)
...
+ BUILD_LIBJVM_cardTableBarrierSetAssembler_x86.cpp_CXXFLAGS :=
-Wno-maybe-uninitialized
...
endif
in make/hotspot/lib/JvmOverrideFiles.gmk to deal with the following
false positive warning:
In file included from
/home/eosterlu/oracle/jdk/jdk-hs.git/open/src/hotspot/share/asm/assembler.hpp:446:0,
from
/home/eosterlu/oracle/jdk/jdk-hs.git/open/src/hotspot/share/asm/macroAssembler.hpp:28,
from
/home/eosterlu/oracle/jdk/jdk-hs.git/open/src/hotspot/share/asm/macroAssembler.inline.hpp:28,
from
/home/eosterlu/oracle/jdk/jdk-hs.git/open/src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp:26:
/home/eosterlu/oracle/jdk/jdk-hs.git/open/src/hotspot/cpu/x86/assembler_x86.hpp:435:78:
warning: 'index.Address::_rspec.RelocationHolder::_relocbuf[3]' may be
used uninitialized in this function [-Wmaybe-uninitial
ized]
ArrayAddress(AddressLiteral base, Address index): _base(base),
_index(index) {};
^
/home/eosterlu/oracle/jdk/jdk-hs.git/open/src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp:115:13:
note: 'index.Address::_rspec.RelocationHolder::_relocbuf[3]' was
declared here
Address index(noreg, obj, Address::times_1);
^~~~~
This is a known false positive compiler warning about the relocation
holder not being initialized where the solution of choice we have picked
is to suppress the warning in each file where it complains about it.
I hope that it is okay that I push that trivial change without another
webrev.
Thanks,
/Erik
On 2018-04-11 13:51, coleen.phillimore at oracle.com wrote:
>
>
> On 4/11/18 5:05 AM, Roman Kennke wrote:
>> Hi Erik,
>>> I have no plans to update the wrappers calling BarrierSetAssembler on
>>> PPC, S390 and AArch64 code.
>>>
>>> 1) I simply can't check if my changes work or not on those platforms.
>>> 2) This is an interface between the platform specific code and the GC.
>>> So I feel like the chosen wrapper to call into BarrierSetAssembler
>>> is up
>>> to the maintainers of those platforms, and it feels like it is not my
>>> call to tell other maintainers what wrapper functions they should use.
>>>
>>> So basically, since I can't test on those platforms, I think it is
>>> up to
>>> Martin Doerr and Roman Kennke to adopt the wrapper function if they
>>> like
>>> it. And I think that is easiest to do as separate RFEs.
>> This sounds reasonable.
>
> Okay, I agree. That sounds reasonable. I've reviewed the interpreter
> pieces.
> Coleen
>
>>
>> Thanks, Roman
>>
>>
>>> Thanks,
>>> /Erik
>>>
>>>
>>> On 2018-04-11 00:49, coleen.phillimore at oracle.com wrote:
>>>>
>>>> On 4/9/18 4:05 PM, Erik ?sterlund wrote:
>>>>> Hi Kim,
>>>>>
>>>>> Thank you for looking at this. Since this was well received, I went
>>>>> ahead and implemented something similar on SPARC as well. Also added
>>>>> support for storing roots (rather than asserting that stores are in
>>>>> the heap only), just in case we need it in the future.
>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.02/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp.udiff.html
>>>>
>>>>
>>>>
>>>> :( you're not going to do all of them since you changed this code
>>>> too? It would make it easier for us to pattern match for changes to
>>>> other platforms if you did, since we have no way of testing these
>>>> platforms.
>>>>
>>>> The sparc changes look reasonable too.
>>>>
>>>> Coleen
>>>>
>>>>> Full webrev:
>>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.02/
>>>>>
>>>>> Incremental webrev:
>>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01_02/
>>>>>
>>>>> On 2018-04-06 01:38, Kim Barrett wrote:
>>>>>>> On Apr 4, 2018, at 9:38 AM, Erik ?sterlund
>>>>>>> <erik.osterlund at oracle.com> wrote:
>>>>>>>
>>>>>>> Hi Kim,
>>>>>>>
>>>>>>> Thank you for reviewing this.
>>>>>>>
>>>>>>> I have made a new webrev with proposed changes to the x86/x64 code
>>>>>>> reflecting the concerns you and Coleen have.
>>>>>>> I thought we should settle for something we like in the x86/x64
>>>>>>> code before going ahead and changing the other platforms too much
>>>>>>> (I don't want to bug Martin and Roman too much before).
>>>>>>>
>>>>>>> New full webrev:
>>>>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.01/
>>>>>>>
>>>>>>> Incremental:
>>>>>>> http://cr.openjdk.java.net/~eosterlund/8199417/webrev.00_01/
>>>>>> This looks better, and you've mostly answered the issues I've raised
>>>>>> so far. Some further discussion inline below.
>>>>> I'm glad to hear that.
>>>>>
>>>>>> Other things have come up and I'm not going to be able to
>>>>>> properly get
>>>>>> back to this soon; don't hold up on my account, just drop me as a
>>>>>> reviewer.
>>>>>>
>>>>>>> On 2018-04-01 05:12, Kim Barrett wrote:
>>>>>>>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>>>>>>>> 364 #ifndef _LP64
>>>>>>>> 365 InterpreterMacroAssembler *imasm =
>>>>>>>> static_cast<InterpreterMacroAssembler*>(masm);
>>>>>>>> 366 #endif
>>>>>>>>
>>>>>>>> In the old code, the function received an
>>>>>>>> InterpreterMacroAssembler*.
>>>>>>>>
>>>>>>>> What is there about this context that lets us know the downcast is
>>>>>>>> safe here? Is oop_store_at only ever called with an IMA*? If so,
>>>>>>>> then why isn't that the parameter type. If not, then what?
>>>>>>> Yes, this is indeed only used by the InterpreterMacroAssembler. But
>>>>>>> I wanted the interface to use MacroAssembler. Why?
>>>>>>>
>>>>>>> 1) It's only 32 bit x86 that relies on this property, and I hope it
>>>>>>> will go away soon, and the save bcp hack with it.
>>>>>>> 2) previous load_heap_oop is used not only in the
>>>>>>> InterpreterMacroAssembler, and I wanted the same assembler in
>>>>>>> load_at and store_at.
>>>>>>>
>>>>>>> So for now it is only used in InterpreterMacroAssembler, and I
>>>>>>> doubt that will change any time soon. I am hoping 32 bit support
>>>>>>> will be dropped before that, and the hack will go away. For now, I
>>>>>>> have added a virtual is_interpreter_masm() call that I use in an
>>>>>>> assert to make sure this is not accidentally used in the wrong
>>>>>>> context until 32 bit support is gone.
>>>>>> The comment plus the new assert satisfies my complaint.
>>>>> Thanks.
>>>>>
>>>>>>>> src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>>>>>>>> 698 address
>>>>>>>> TemplateInterpreterGenerator::generate_Reference_get_entry(void) {
>>>>>>>>
>>>>>>>> Almost all the code here (and much of the commentary) was/is
>>>>>>>> specific
>>>>>>>> to G1 (or SATB collectors). Shouldn't it all be in the
>>>>>>>> barrier_set's
>>>>>>>> load_at? As it is now, if (say) we're using Parallel GC then I
>>>>>>>> think
>>>>>>>> there's a bunch of additional code being generated and executed
>>>>>>>> here
>>>>>>>> that wasn't present before.
>>>>>>> It is true that interpreter Reference.get() intrinsics with
>>>>>>> Parallel/CMS/Serial currently run a few instructions more than they
>>>>>>> need to pay for the abstraction. There is no doubt in my mind that
>>>>>>> this abstraction is worth the cost. Reference.get in the
>>>>>>> interpreter is not a hot path, and does not need to optimize every
>>>>>>> cycle.
>>>>>>>
>>>>>>> I changed the G1 comments to more general comments instead.
>>>>>> Good point on this not being a hot path.
>>>>>>
>>>>>> "Preserve the sender sp in case the pre-barrier
>>>>>> calls the runtime"
>>>>>>
>>>>>> s/the pre-barrier/a load barrier/
>>>>> Fixed.
>>>>>
>>>>>>>> src/hotspot/cpu/x86/gc/shared/modRefBarrierSetAssembler_x86.cpp
>>>>>>>> 86 void ModRefBarrierSetAssembler::store_at(MacroAssembler* masm,
>>>>>>>> DecoratorSet decorators, BasicType type,
>>>>>>>> 87 Address dst, Register
>>>>>>>> val, Register tmp1, Register tmp2) {
>>>>>>>> 88 if (type == T_OBJECT || type == T_ARRAY) {
>>>>>>>> 89 oop_store_at(masm, decorators, type, dst, val, tmp1, tmp2);
>>>>>>>> 90 } else {
>>>>>>>> 91 BarrierSetAssembler::store_at(masm, decorators, type, dst,
>>>>>>>> val, tmp1, tmp2);
>>>>>>>> 92 }
>>>>>>>> 93 }
>>>>>>>>
>>>>>>>> Doesn't the conditional conversion from store_at to oop_store_at
>>>>>>>> actually indicate a bug in the caller? That is, calling
>>>>>>>> store_at with
>>>>>>>> a oop (T_OBJECT or T_ARRAY) value seems like a bug, and should be
>>>>>>>> asserted against, rather than translating.
>>>>>>>>
>>>>>>>> And oop_store_at should assert that the value *is* an oop value.
>>>>>>>>
>>>>>>>> And should there be any verification that the decorators and
>>>>>>>> the type
>>>>>>>> are consistent?
>>>>>>>>
>>>>>>>> But maybe I'm not understanding the protocol around oop_store_at?
>>>>>>>> There being no documentation, it seems entirely possible that I've
>>>>>>>> misunderstood something here. Maybe I'm being confused by
>>>>>>>> similarities in naming with Access:: that don't hold?
>>>>>>> The confusion roots in that Access and BarrierSetAssembler are not
>>>>>>> structured exactly the same.
>>>>>>>
>>>>>>> Access provides store_at and oop_store_at. The reason for providing
>>>>>>> both of these, is that I could not safely infer whether the passed
>>>>>>> in parameters were oops or not without changing oop and narrowOop
>>>>>>> to always be value objects, which I did not dare to do as the
>>>>>>> generated code was worse.
>>>>>>>
>>>>>>> In BarrierSetAssembler, there is no such restriction. The type for
>>>>>>> the access is always passed in to store_at/load_at as BasicType. It
>>>>>>> is the responsibility of ModRefBarrierSetAssembler to filter away
>>>>>>> non-oop references, and call oop_store_at for relevant accesses for
>>>>>>> ModRef. This follows the same pattern that the arraycopy stubs
>>>>>>> used. This allows, e.g. CardTableModRef to only override
>>>>>>> oop_store_at. This is similar to how
>>>>>>> ModRefBarrierSet::AccessBarrier<decorators,
>>>>>>> BarrierSetT>::oop_store_in_heap calls the concrete barriersets for
>>>>>>> help generating that access. I hope this helps understanding the
>>>>>>> structuring.
>>>>>>>
>>>>>>> This is also the reason why G1BarrierSetAssembler::load_at checks
>>>>>>> whether it is an oop that is loaded or not, because loads are not
>>>>>>> riding on the ModRef layer, which only knows about oop stores.
>>>>>> I see. The naming congurence, along with my having glazed over the
>>>>>> fact that oop_store_at is protected rather than public, led me
>>>>>> astray.
>>>>>> I don't have any better suggestions for naming. I would have found
>>>>>> some comments describing the protocols helpful.
>>>>> I added some comments describing the idea behind ModRef.
>>>>>
>>>>>> Shouldn't ModRef::oop_store_at be pure virtual? That would have
>>>>>> helped my understanding too.
>>>>> Sure. Fixed.
>>>>>
>>>>> Thanks,
>>>>> /Erik
>>
>
From robbin.ehn at oracle.com Wed Apr 11 12:35:16 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Wed, 11 Apr 2018 14:35:16 +0200
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <134d9c17-0c54-5cf1-e80b-e64b9a15dfb8@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<37e87dfc-1f1e-254b-a03e-8d8c1d4b0cef@oracle.com>
<84D1CF4E-B765-4FF5-9D6A-79703947FCE8@oracle.com>
<f82775fd-8b01-813a-b471-285b3323bbcb@oracle.com>
<0024711f-f8a4-5b72-6dae-5186952c4afe@oracle.com>
<faad6465-6d76-a23d-be06-b55d9bef37c5@oracle.com>
<7a26ff66-b9be-48aa-0956-29adeef87628@oracle.com>
<134d9c17-0c54-5cf1-e80b-e64b9a15dfb8@oracle.com>
Message-ID: <20dcafef-f93a-267c-284d-9b33849376f9@oracle.com>
On 04/11/2018 02:03 PM, David Holmes wrote:
> On 11/04/2018 9:38 PM, Robbin Ehn wrote:
>> Hi,
>>
>> On 04/11/2018 12:57 PM, David Holmes wrote:
>>>
>>> Sorry no, I don't understand what this counter is doing at all. I feel I need
>>> to see what is between the begin/end critical section for this to make any
>>> sense to me. And to see what the writer actually does.
>>
>> ?From gtest:
>
> Thanks for that. Okay I have a better sense of how the access to the data
> completes the handshake.
>
Great!
> Does the naming/terminology come from some existing mechanism? I find it
> somewhat odd and not really descriptive of the operation..
There several of different versions but they follow the same naming scheme.
E.g. such as smr_begin, smr_end, synchronize
Thanks, Robbin
>
> Thanks,
> David
>
>> Read side do:
>> ?? 49?????? GlobalCounter::critical_section_begin(this);
>> ?? 50?????? volatile TestData* test = OrderAccess::load_acquire(_test);
>> ?? 51?????? long value = OrderAccess::load_acquire(&test->test_value);
>> ?? 52?????? ASSERT_EQ(value, GOOD);
>> ?? 53?????? GlobalCounter::critical_section_end(this);
>> Write side do:
>> ??101???????? volatile TestData* free_tmp = test;
>> ??102???????? tmp = new TestData();
>> ??103???????? tmp->test_value = GOOD;
>> ??104???????? OrderAccess::release_store(&test, tmp);
>> ??105???????? GlobalCounter::write_synchronize();
>> ??106???????? free_tmp->test_value = BAD;
>> ??107???????? delete free_tmp;
>>
>> If a reader is context switch between line 50 and 51, it will have a cached
>> value of the pointer "_test", thus no one should free it.
>>
>> Before freeing the writer calls write_synchronize which guarantees that no
>> reader can see the old pointer and can then free it.
>>
>> If the reader is context switch inside critical_section_begin this does not
>> matter since the fence in critical_section_begin prohibits the load of test
>> pointer from floating up. If write_synchronize is done before this reader gets
>> back on CPU it will see the new value but have an counter of an old generation.
>> If it gets back on CPU before write_synchronize I will see the old pointer.
>>
>> If we call the pointer values TEST_gen_1, TEST_gen_2, ...
>> test_pointer starts equal to TEST_gen_1 and generation starts at 1.
>>
>> Writer: tmp_pointer = test_pointer
>> Writer: test_pointer = TEST_gen_2
>> Reader: load global counter (fetches 1)
>> Reader: context switched out
>> Writer: write_synchronized generation = 2, and do not see the reader.
>> Reader: store local counter to 1 // critical section begin
>> Reader: load test_pointer (TEST_gen_2) // This load will always happen *after*
>> the store to local counter
>> Writer: free tmp_pointer (TEST_gen_1) // ABA safe
>>
>> Writer: tmp_pointer = test_pointer
>> Writer: test_pointer = TEST_gen_3
>> Writer: write_synchronized generation = 3, and _sees_ on old reader => wait.
>> Reader: store local counter OFF // critical section end
>> Writer: write_synchronized now finishes.
>> Writer: free tmp_pointer (TEST_gen_2) // ABA safe
>>
>> /Robbin
>>
>>>
>>> David
>>> -----
From per.liden at oracle.com Wed Apr 11 12:37:38 2018
From: per.liden at oracle.com (Per Liden)
Date: Wed, 11 Apr 2018 14:37:38 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <8d84f53f-5587-79a1-4eae-5891efe71520@redhat.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<6b382992-af7a-fd67-1494-ad9301c110db@redhat.com>
<79ed21cd-ca37-f320-2207-b0e141c353ac@oracle.com>
<8d84f53f-5587-79a1-4eae-5891efe71520@redhat.com>
Message-ID: <2aa1c687-07b3-eba8-94b4-4e2abe80c8fa@oracle.com>
Hi Aleksey,
On 04/11/2018 12:13 PM, Aleksey Shipilev wrote:
> On 04/11/2018 11:54 AM, Per Liden wrote:
>>> *) Should these new methods accept JavaThread*? I.e. we are expecting the GC thread-local data only
>>> for JavaThreads, like attach/detach does?
>>>
>>> ??? virtual void on_thread_create(Thread* thread);
>>> ??? virtual void on_thread_destroy(Thread* thread);
>>> ??? virtual void on_thread_attach(JavaThread* thread);
>>> ??? virtual void on_thread_detach(JavaThread* thread);
>>
>> The intention is that on_thread_create/destroy is called for all threads, where as
>> on_thread_attach/detach is only called for JavaThreads (i.e. threads that are added to the "threads
>> list"). There's been discussions about treating all threads in the same way, i.e. they would all be
>> on the threads list and they would all receive attach/detach calls. It's not clear yet if that is a
>> good idea, but if that change is made in the future, then we might want to revisit this interface.
>
> Ah, I understand. After sending the reply yesterday I realized they might be legit use cases where
> you want to have GCTLD available e.g. for GC threads.
>
>> As discussed else where in this thread, the reason for keeping the GCThreadLocalData member early in
>> Thread is to allow GC barriers to generate compact code. As Erik indicates, this may not matter that
>> much in the end, but I also don't think it hurts to let it sit there.
>>
>> Also, I've shrunk GCThreadLocalData to 112 bytes, which is what G1 currently needs. ZGC currently
>> uses 156 bytes (IIRC), but that's a change that should stay the ZGC repo for now.
>
> Oh. Haven't expected we need that much. This makes me think if we should implement some sort of
> STATIC_ASSERT-based overflow checks? Not necessarily in this RFE.
Actually, it's already there, in Thread::gc_data().
>
>> Updated webrev here:
>>
>> Diff: http://cr.openjdk.java.net/~pliden/8201318/webrev.1vs2/
>> Full: http://cr.openjdk.java.net/~pliden/8201318/webrev.2/
>
> Looks good!
>
> Minor nits (no need to re-review):
>
> *) I'll probably do another sweep and do a tad better indenting work. Compare:
>
> 2178 Address in_progress(Rthread, in_bytes(G1ThreadLocalData::satb_mark_queue_active_offset()));
> 2179 Address index(Rthread, in_bytes(G1ThreadLocalData::satb_mark_queue_index_offset()));
> 2180 Address buffer(Rthread, in_bytes(G1ThreadLocalData::satb_mark_queue_buffer_offset()));
>
> vs.
>
> 2178 Address in_progress(Rthread, in_bytes(G1ThreadLocalData::satb_mark_queue_active_offset()));
> 2179 Address index(Rthread, in_bytes(G1ThreadLocalData::satb_mark_queue_index_offset()));
> 2180 Address buffer(Rthread, in_bytes(G1ThreadLocalData::satb_mark_queue_buffer_offset()));
>
> *) Typos: "provied" -> "provided", "over head" -> "overhead".
>
> // Thread local data area for GC-specific information. Each GC
> // is free to decide the internal structure and contents of this
> // area. It is represented as a 64-bit aligned opaque blob to
> // avoid circular dependencies between Thread and all GCs. For
> // the same reason, the size of the data area is hard coded to
> // provied enough space for all current GCs. Adjust the size if
> // needed, but avoid making it excessively large as it adds to
> // the memory over head of creating a thread
Oops! Will fix.
>
> *) Also mention the choice of <128 bytes? Like this:
>
> // The size of GCTLD is kept under 128 bytes to let compilers encode
> // accesses to GCTLD members with short offsets from the Thread.
Hmm, I don't quite think this captures the crux of this. To optimize for
code compactness, you just need to make sure that the data referenced by
generated barriers is kept within a 127 byte offset. For example, in ZGC
we only ever reference the first word of the GCTLD in the generated
barriers (i.e. well below 127). The rest of the data is used when we hit
the slow path, and then we're executing in the VM and don't care about
the offset. So, from this point of view, the GCTLD could have any size
and it wouldn't matter for code compactness. Same it true for G1 and
Shenandoah, i.e. their generated barriers would be unaffected by an
increase in GCTLD size.
Thanks!
/Per
>
>
> -Aleksey
>
From per.liden at oracle.com Wed Apr 11 12:38:02 2018
From: per.liden at oracle.com (Per Liden)
Date: Wed, 11 Apr 2018 14:38:02 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <012f478eb667426db7a5103da3816eca@sap.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<6b382992-af7a-fd67-1494-ad9301c110db@redhat.com>
<79ed21cd-ca37-f320-2207-b0e141c353ac@oracle.com>
<012f478eb667426db7a5103da3816eca@sap.com>
Message-ID: <587e5b0c-27d3-92d5-aaa9-9a7588139c49@oracle.com>
Thanks Martin!
/Per
On 04/11/2018 12:28 PM, Doerr, Martin wrote:
> Hi Per,
>
> thanks for simplifying the platform code. I just verified that it still builds on PPC64 and s390.
>
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: Per Liden [mailto:per.liden at oracle.com]
> Sent: Mittwoch, 11. April 2018 11:55
> To: Aleksey Shipilev <shade at redhat.com>; Roman Kennke <rkennke at redhat.com>; Doerr, Martin <martin.doerr at sap.com>; hotspot-dev at openjdk.java.net; Robbin Ehn <robbin.ehn at oracle.com>; OSTERLUND,ERIK <erik.osterlund at oracle.com>
> Subject: Re: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific data belonging to a thread
>
> Hi Aleksey,
>
> On 04/10/2018 05:04 PM, Aleksey Shipilev wrote:
>> On 04/10/2018 02:51 PM, Per Liden wrote:
>>> A couple of commits were pushed, which causes conflicts with this change, so here's a rebased version:
>>>
>>> http://cr.openjdk.java.net/~pliden/8201318/webrev.1
>>
>> *) I wonder if we can make the special accessors for the composite offsets? E.g. instead of
>>
>>
>> Address in_progress(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_offset() +
>> SATBMarkQueue::byte_offset_of_active()));
>> Address queue_index(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_offset() +
>> SATBMarkQueue::byte_offset_of_index()));
>> Address buffer(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_offset() +
>> SATBMarkQueue::byte_offset_of_buf()));
>>
>> ...do:
>>
>> Address in_progress(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_active_offset()));
>> Address queue_index(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_index_offset()));
>> Address buffer(thread, in_bytes(G1ThreadLocalData::satb_mark_queue_buf_offset()));
>>
>> That probably eliminates the header dependency on SATBMarkQueue/DirtyCardQueue from
>> compiler/assembler stubs?
>
> Done.
>
>>
>> *) Should these new methods accept JavaThread*? I.e. we are expecting the GC thread-local data only
>> for JavaThreads, like attach/detach does?
>>
>> virtual void on_thread_create(Thread* thread);
>> virtual void on_thread_destroy(Thread* thread);
>> virtual void on_thread_attach(JavaThread* thread);
>> virtual void on_thread_detach(JavaThread* thread);
>
> The intention is that on_thread_create/destroy is called for all
> threads, where as on_thread_attach/detach is only called for JavaThreads
> (i.e. threads that are added to the "threads list"). There's been
> discussions about treating all threads in the same way, i.e. they would
> all be on the threads list and they would all receive attach/detach
> calls. It's not clear yet if that is a good idea, but if that change is
> made in the future, then we might want to revisit this interface.
>
>>
>> *) Wait, why do we call JVMCI members JavaThread_*?
>>
>> 64 static int JavaThread_satb_mark_queue_offset;
>> 65 static int JavaThread_dirty_card_queue_offset;
>
> Good catch! I switched to using the declare_constant_with_value()
> construct, so these members are now gone.
>
>>
>> *) I would probably add assert(UseG1GC) to G1ThreadLocalData accessor methods
>
> Done. Note however that we can't add asserts to the *_offset()
> functions, as those will be called by Graal regardless of weather G1 is
> enabled or not.
>
> As discussed else where in this thread, the reason for keeping the
> GCThreadLocalData member early in Thread is to allow GC barriers to
> generate compact code. As Erik indicates, this may not matter that much
> in the end, but I also don't think it hurts to let it sit there.
>
> Also, I've shrunk GCThreadLocalData to 112 bytes, which is what G1
> currently needs. ZGC currently uses 156 bytes (IIRC), but that's a
> change that should stay the ZGC repo for now.
>
> Updated webrev here:
>
> Diff: http://cr.openjdk.java.net/~pliden/8201318/webrev.1vs2/
> Full: http://cr.openjdk.java.net/~pliden/8201318/webrev.2/
>
> Thanks for reviewing.
>
> /Per
>
>>
>> Thanks,
>> -Aleksey
>>
From per.liden at oracle.com Wed Apr 11 12:39:17 2018
From: per.liden at oracle.com (Per Liden)
Date: Wed, 11 Apr 2018 14:39:17 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <27e40ede-a919-b384-1fba-a346061265d2@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<6b382992-af7a-fd67-1494-ad9301c110db@redhat.com>
<79ed21cd-ca37-f320-2207-b0e141c353ac@oracle.com>
<27e40ede-a919-b384-1fba-a346061265d2@oracle.com>
Message-ID: <268e73a0-f09f-fe94-dd39-4302fe11bf47@oracle.com>
Thanks Robbin!
/Per
On 04/11/2018 12:07 PM, Robbin Ehn wrote:
> On 04/11/2018 11:54 AM, Per Liden wrote:
>>
>> Also, I've shrunk GCThreadLocalData to 112 bytes, which is what G1
>> currently needs. ZGC currently uses 156 bytes (IIRC), but that's a
>> change that should stay the ZGC repo for now.
>>
>> Updated webrev here:
>>
>> Diff: http://cr.openjdk.java.net/~pliden/8201318/webrev.1vs2/
>> Full: http://cr.openjdk.java.net/~pliden/8201318/webrev.2/
>
> Looks good, reviewed.
>
> Thanks, Robbin
>
>>
>> Thanks for reviewing.
>>
>> /Per
From shade at redhat.com Wed Apr 11 12:59:06 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 11 Apr 2018 14:59:06 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <2aa1c687-07b3-eba8-94b4-4e2abe80c8fa@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<6b382992-af7a-fd67-1494-ad9301c110db@redhat.com>
<79ed21cd-ca37-f320-2207-b0e141c353ac@oracle.com>
<8d84f53f-5587-79a1-4eae-5891efe71520@redhat.com>
<2aa1c687-07b3-eba8-94b4-4e2abe80c8fa@oracle.com>
Message-ID: <f13b8b38-1a9f-015d-7d69-5a17dc84bf1e@redhat.com>
On 04/11/2018 02:37 PM, Per Liden wrote:
>>> Also, I've shrunk GCThreadLocalData to 112 bytes, which is what G1 currently needs. ZGC currently
>>> uses 156 bytes (IIRC), but that's a change that should stay the ZGC repo for now.
>>
>> Oh. Haven't expected we need that much. This makes me think if we should implement some sort of
>> STATIC_ASSERT-based overflow checks? Not necessarily in this RFE.
>
> Actually, it's already there, in Thread::gc_data().
Right on!
>> *) Also mention the choice of <128 bytes? Like this:
>>
>> ? // The size of GCTLD is kept under 128 bytes to let compilers encode
>> ? // accesses to GCTLD members with short offsets from the Thread.
>
> Hmm, I don't quite think this captures the crux of this. To optimize for code compactness, you just
> need to make sure that the data referenced by generated barriers is kept within a 127 byte offset.
> For example, in ZGC we only ever reference the first word of the GCTLD in the generated barriers
> (i.e. well below 127). The rest of the data is used when we hit the slow path, and then we're
> executing in the VM and don't care about the offset. So, from this point of view, the GCTLD could
> have any size and it wouldn't matter for code compactness. Same it true for G1 and Shenandoah, i.e.
> their generated barriers would be unaffected by an increase in GCTLD size.
That's right. My point was to make the stronger and simpler statement about all fields in GCTLD: if
you put the field in current GCTLD, the access to it from the generated code would likely to be
optimal. I guess "slow parts" of ZGC's GCTLD is a good counter-example. Nevertheless, I find it
better to capture the salient points about performance in the implementation notes near the code:
// The current size of GCTLD is kept under 128 bytes to let compilers encode
// accesses to all GCTLD members with short offsets from the Thread. This is not
// a hard requirement: we can have fields past 128+ bytes, but low-offset fields would
// be more efficient to access. Therefore, consider putting more frequently used
// fields first in GCTLD, in case GCTLD size is extended in future and/or moved
// within the Thread.
Thanks,
-Aleksey
From robbin.ehn at oracle.com Wed Apr 11 13:09:13 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Wed, 11 Apr 2018 15:09:13 +0200
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <F5A643B9-CBD4-416C-B200-205363665719@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<da8fea92-e08e-5801-544b-1e4b6200d6b2@oracle.com>
<31e3f7cc-7df2-5bfe-cb56-9d7064d12fd7@oracle.com>
<F5A643B9-CBD4-416C-B200-205363665719@oracle.com>
Message-ID: <9d2c9101-90eb-f959-c30b-f7089da6aa49@oracle.com>
Hi Kim,
On 04/10/2018 05:53 PM, Kim Barrett wrote:
>> On Apr 10, 2018, at 10:42 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>>
>> Full: http://cr.openjdk.java.net/~rehn/8195099/v2/webrev/
>> Inc : http://cr.openjdk.java.net/~rehn/8195099/v2/inc/webrev/
>
> ------------------------------------------------------------------------------
>
> GlobalCounter describes its implementation, but is not the least bit
> evocative of its purpose. I don't have a good name suggestion though.
I totally agree. But since I don't either have a good name, except for RCU,
since this implements a very small part of a traditional RCU interface. I think
such name might be confusing in hotspot context. Secondly when/if we change the
underlying implementation we can easily reactor this into an interface. This
also why I in earlier versions had the GlobalCounter on heap, so it potentially
would be choose-able at runtime. And third I like to avoid premature abstraction
and instead do the refactoring when need.
>
> ------------------------------------------------------------------------------
>
> This is being put in utilities. Similarly we put SpinYield in
> utilities. But I'm not sure either of those are properly placed
> there. These are synchronization building blocks, and all other
> synchronization stuff is in runtime.
I have no strong opinion here.
>
> ------------------------------------------------------------------------------
> src/hotspot/share/utilities/globalCounter.hpp
>
> Consider just forward declaring Thread (at namespace scope).
>
> Consider just forward declaring CounterThreadCheck at class scope,
> with the definition in the .cpp file.
>
> With those changes, don't need to #include thread.hpp in this header.
> Although globalCounter.inline.hpp still needs to #include thread.hpp,
> so maybe this doesn't matter so much?
Good suggestion fixed!
>
> ------------------------------------------------------------------------------
> src/hotspot/share/utilities/globalCounter.hpp
>
> Although CriticalSection is fully defined in this header, I think it
> can't be instantiated without including globalCounter.inline.hpp.
> Consider just forward declaring in the GlobalCounter definition, with
> the definition in the .inline.hpp.
Fixed !
>
> ------------------------------------------------------------------------------
> src/hotspot/share/utilities/globalCounter.inline.hpp
>
> Missing #include globalCounter.hpp.
Fixed!
>
> ------------------------------------------------------------------------------
> src/hotspot/share/utilities/globalCounter.inline.hpp
> 36 OrderAccess::release_store_fence(thread->get_rcu_counter(), gbl_cnt + 1);
>
> "gbl_cnt + 1" => "gbl_cnt | COUNTER_ACTIVE".
Fixed!
>
> ------------------------------------------------------------------------------
> src/hotspot/share/utilities/globalCounter.hpp
>
> 74 // Must be called after finished accessing the data.
> 75 // Do not provide fence, allows load/stores moving into the critical section.
> 76 static void critical_section_end(Thread *thread);
>
> Both begin and end should have descriptions of their ordering
> behavior. I'm thinking something similar to the descriptions we have
> for Atomic operations.
I had a hard time finding a good way to do this since they also have
dependencies to each other. I skipped this for now.
I'll post new revision to RFR mail.
Thanks, Robbin
>
> ------------------------------------------------------------------------------
>
From robbin.ehn at oracle.com Wed Apr 11 13:10:40 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Wed, 11 Apr 2018 15:10:40 +0200
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <37e87dfc-1f1e-254b-a03e-8d8c1d4b0cef@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<37e87dfc-1f1e-254b-a03e-8d8c1d4b0cef@oracle.com>
Message-ID: <e1521069-dacc-38a3-1972-1a9c87a06946@oracle.com>
Hi David,
On 04/11/2018 03:34 AM, David Holmes wrote:
>
> src/hotspot/share/utilities/globalCounter.hpp
>
> ?30 // The GlobalCounter provides a synchronization mechanism threads which can be
>
> The comment does not read correctly.
Fixed, I'll re-post new version on RFR mail.
Thanks, Robbin
>
> Thanks,
> David
From robbin.ehn at oracle.com Wed Apr 11 13:17:46 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Wed, 11 Apr 2018 15:17:46 +0200
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
Message-ID: <f2f9d586-fa23-e474-8e39-fae80483bf5a@oracle.com>
Thanks for reviews, here is an updated version:
Inc:
http://cr.openjdk.java.net/~rehn/8195099/v3/inc/webrev/
(if you missed v2 it's here: http://cr.openjdk.java.net/~rehn/8195099/v2/)
Full:
http://cr.openjdk.java.net/~rehn/8195099/v3/webrev/
Thanks, Robbin
On 04/10/2018 02:18 PM, Robbin Ehn wrote:
> Hi all,
>
> We have moved the global-counter to a separate change-set. The global-counter
> uses a counter to determine current generation. Any reader needs to have a local
> counter for which generation is currently read. By increment the global-counter
> and scan for threads reading an old generation and wait for them to complete, we
> know when an old generation is not visible (no pre-existing reader). In RCU
> terms, this creates a grace-period. Making this mechanism suitable for a
> read-mostly scenario. In this initial change-set we scan JavaThreads and the
> VMThread.
>
> A couple of enhancement to the global-counter will be looked into:
> - Quiescent state RCU semantic by using the natural state of JavaThreads in the VM.
> - Asynchronous write synchronize, where reclamation, if there are per-existing
> reader, is done by the last reader leaving that generation.
> - Register/deregister threads.
>
> The current usage is the upcoming hash-table which uses the global-counter to
> reclaim memory and to concurrently grow. We have also potential use-cases in
> other work-in-progress code.
>
> The new gtest passes on our platforms. For now you can look at the gtest if you
> think you have a use-case for this as an example.
>
> Code: http://cr.openjdk.java.net/~rehn/8195099/v1/webrev/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8195099
>
> Thanks, Robbin
From boris.ulasevich at bell-sw.com Wed Apr 11 13:37:21 2018
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Wed, 11 Apr 2018 16:37:21 +0300
Subject: RFR (S) 8201370: Minimal VM build fail
In-Reply-To: <6c5998a1-f92b-fd2c-a9ac-8e5767166a31@oracle.com>
References: <ae347b5b-0d19-c9da-ff69-ed9f621643c2@bell-sw.com>
<d82ef3d3-2450-fc9c-bc16-63a036f6ac2a@oracle.com>
<b2087917-c2de-5dbd-4e02-a63acfd9705c@bell-sw.com>
<6c5998a1-f92b-fd2c-a9ac-8e5767166a31@oracle.com>
Message-ID: <9644766d-7a2c-06bc-a525-c60607ce1c6a@bell-sw.com>
Thank you!
Boris
On 11.04.2018 15:21, Stefan Karlsson wrote:
> On 2018-04-11 11:40, Boris Ulasevich wrote:
>> Hi Stefan,
>>
>> ?? Yes, please sponsor my patch!
>
> I've pushed your change here:
> http://hg.openjdk.java.net/jdk/hs/rev/e3e66c178518
>
> I took the liberty of sorting the moved includes and updating the bug
> report title to better reflect the RFE.
>
> This is the follow-up change to fix Minimal VM builds on my Linux x64
> machine:
> http://hg.openjdk.java.net/jdk/hs/rev/b17256b5c047
>
> Cheers,
> StefanK
>
>>
>> Thanks,
>> Boris
>>
>> On 11.04.2018 11:07, Stefan Karlsson wrote:
>>> Hi again,
>>>
>>> I tried to compile the Minimal VM on my machine and had to apply the
>>> following patch to get it to work:
>>> http://cr.openjdk.java.net/~stefank/8201370/webrev.01/
>>>
>>> There's a few more changes, but nothing that seems non-trivial, so
>>> should be enough to get one Reviewer to review this.
>>>
>>> Do you want me to sponsor your patch and include the changes in my
>>> webrev?
>>>
>>> Thanks,
>>> StefanK
>>>
>>> On 2018-04-10 18:56, Boris Ulasevich wrote:
>>>> Hi all,
>>>>
>>>> Please review this patch to fix Minimal VM build fail caused by
>>>> recent GC headers updating.
>>>>
>>>> ??https://bugs.openjdk.java.net/browse/JDK-8201370
>>>> ??http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8201370/webrev.00/
>>>>
>>>>
>>>> I will post separate review on arm32-specific changes.
>>>>
>>>> Thanks,
>>>> Boris
From thomas.stuefe at gmail.com Wed Apr 11 14:14:17 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 11 Apr 2018 16:14:17 +0200
Subject: RFR (XL) 8081519 Split globals.hpp to factor out the Flag class
In-Reply-To: <8009E1D8-0493-48FC-97C3-3BBDFE76A13F@oracle.com>
References: <D6E4A4E8-8356-4694-BD9C-03AB5FA5BC65@oracle.com>
<6656E162-56BE-4E75-8343-7567715F30C7@oracle.com>
<8009E1D8-0493-48FC-97C3-3BBDFE76A13F@oracle.com>
Message-ID: <CAA-vtUy2sk7b_dyiAMKedBBM7dD6nFxchvjm3ENSF8HpT+w2=A@mail.gmail.com>
Hi Gerard,
I attempted to test-build your fix on AIX but it fails to apply (on jdk-hs):
- .../source $ hg qpush
applying webrev.patch
patching file src/hotspot/share/runtime/arguments.cpp
Hunk #24 succeeded at 2749 with fuzz 1 (offset -30 lines).
patching file src/hotspot/share/runtime/globals.cpp
Hunk #2 FAILED at 87
1 out of 2 hunks FAILED -- saving rejects to file
src/hotspot/share/runtime/globals.cpp.rej
patching file src/hotspot/share/runtime/vmStructs.cpp
Hunk #2 FAILED at 232
1 out of 7 hunks FAILED -- saving rejects to file
src/hotspot/share/runtime/vmStructs.cpp.rej
patching file src/hotspot/share/runtime/commandLineFlagConstraintList.cpp
Hunk #1 FAILED at 0
1 out of 1 hunks FAILED -- saving rejects to file
src/hotspot/share/runtime/commandLineFlagConstraintList.cpp.rej
unable to find 'src/hotspot/share/runtime/commandLineFlagConstraintsGC.cpp'
for patching
1 out of 1 hunks FAILED -- saving rejects to file
src/hotspot/share/runtime/commandLineFlagConstraintsGC.cpp.rej
unable to find 'src/hotspot/share/runtime/commandLineFlagConstraintsGC.hpp'
for patching
1 out of 1 hunks FAILED -- saving rejects to file
src/hotspot/share/runtime/commandLineFlagConstraintsGC.hpp.rej
patching file src/hotspot/share/runtime/commandLineFlagRangeList.cpp
Hunk #1 FAILED at 0
1 out of 1 hunks FAILED -- saving rejects to file
src/hotspot/share/runtime/commandLineFlagRangeList.cpp.rej
patching file src/hotspot/share/runtime/commandLineFlagWriteableList.cpp
Hunk #1 FAILED at 0
1 out of 1 hunks FAILED -- saving rejects to file
src/hotspot/share/runtime/commandLineFlagWriteableList.cpp.rej
patch failed, unable to continue (try -v)
patch failed, rejects left in working dir
errors during apply, please fix and refresh webrev.patch
Could you please provide an updated version? Thank you!
Thomas
On Mon, Apr 9, 2018 at 8:35 PM, Gerard Ziemski <gerard.ziemski at oracle.com>
wrote:
> Hi all,
>
> Here is http://cr.openjdk.java.net/~gziemski/8081519_rev3 with the
> addition requested by Coleen to include jvmFlag.hpp directly anywhere
> jvmFlag is used.
>
> Tested locally with open/closed, debug/product, precompiled header/no
> precompiled header build variations.
>
>
> cheers
>
> > On Apr 5, 2018, at 12:46 PM, Gerard Ziemski <gerard.ziemski at oracle.com>
> wrote:
> >
> > Hi all,
> >
> > Here is webrev 2 with the following additions:
> >
> > #1 Factor FlagSetting class out of "runtime/flags/jvmFlag.hpp" and into
> its own "runtime/flags/flagSetting.hpp", so that FlagSetting class can
> extend from ?public StackObj? (thanks Coleen)
> >
> > #2 change the hierarchy from ?runtime/jvmFlag/? to "runtime/flags/?
> (thanks David)
> >
> > #3 Fix the header files, so that both closed and open repository build
> with and without precompiled headers
> >
> > #4 Add ?runtime/flags/*.hpp? headers to ?precompiled.hpp?
> >
> > The number of touched files got even longer - sorry about that and big
> thank you for taking your time to review!
> >
> > Running final Mach5 hs_tier1-5 tests? (it passed earlier iterations).
> Passes local builds (on Mac OS X) with and without precompiled headers for
> both closed and open repos and both debug and product versions (should I
> try any other build varations?)
> >
> > http://cr.openjdk.java.net/~gziemski/8081519_rev2
> >
> >
> > cheers
> >
> >> On Mar 29, 2018, at 2:01 PM, Gerard Ziemski <gerard.ziemski at oracle.com>
> wrote:
> >>
> >> Hi all,
> >>
> >> Please review this large and tedious (sorry), but simple fix that
> accomplishes the following:
> >>
> >> #1 factor out the command option flag related APIs out of
> globals.hpp/.cpp into its own dedicated files, i.e. jvmFlag.hpp/.cpp
> >> #2 merge Flag (too generic name) and CommandLineFlag classes and rename
> them as JVMFlag
> >> #3 cleanup globals.hpp includes originally added by the JEP-245
> >>
> >> Note: the renamed file retain their history, but one needs to add
> ?follow? flag, ex. ?hg log -f file?
> >>
> >> https://bugs.openjdk.java.net/browse/JDK-8081519
> >> http://cr.openjdk.java.net/~gziemski/8081519_rev1
> >>
> >> Passes Mach5 hs_tier1-tier5, jtreg/runtime/CommandLine/
> OptionsValidation/TestOptionsWithRanges tests.
> >>
> >>
> >> cheers
> >
>
>
From gerard.ziemski at oracle.com Wed Apr 11 14:19:34 2018
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Wed, 11 Apr 2018 09:19:34 -0500
Subject: RFR (XL) 8081519 Split globals.hpp to factor out the Flag class
In-Reply-To: <CAA-vtUy2sk7b_dyiAMKedBBM7dD6nFxchvjm3ENSF8HpT+w2=A@mail.gmail.com>
References: <D6E4A4E8-8356-4694-BD9C-03AB5FA5BC65@oracle.com>
<6656E162-56BE-4E75-8343-7567715F30C7@oracle.com>
<8009E1D8-0493-48FC-97C3-3BBDFE76A13F@oracle.com>
<CAA-vtUy2sk7b_dyiAMKedBBM7dD6nFxchvjm3ENSF8HpT+w2=A@mail.gmail.com>
Message-ID: <85502A38-A61F-422D-B5EF-5ECDC68D6316@oracle.com>
Hi Thomas,
Yes, I?m working on it?
cheers
> On Apr 11, 2018, at 9:14 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>
> Hi Gerard,
>
> I attempted to test-build your fix on AIX but it fails to apply (on jdk-hs):
>
> - .../source $ hg qpush
> applying webrev.patch
> patching file src/hotspot/share/runtime/arguments.cpp
> Hunk #24 succeeded at 2749 with fuzz 1 (offset -30 lines).
> patching file src/hotspot/share/runtime/globals.cpp
> Hunk #2 FAILED at 87
> 1 out of 2 hunks FAILED -- saving rejects to file src/hotspot/share/runtime/globals.cpp.rej
> patching file src/hotspot/share/runtime/vmStructs.cpp
> Hunk #2 FAILED at 232
> 1 out of 7 hunks FAILED -- saving rejects to file src/hotspot/share/runtime/vmStructs.cpp.rej
> patching file src/hotspot/share/runtime/commandLineFlagConstraintList.cpp
> Hunk #1 FAILED at 0
> 1 out of 1 hunks FAILED -- saving rejects to file src/hotspot/share/runtime/commandLineFlagConstraintList.cpp.rej
> unable to find 'src/hotspot/share/runtime/commandLineFlagConstraintsGC.cpp' for patching
> 1 out of 1 hunks FAILED -- saving rejects to file src/hotspot/share/runtime/commandLineFlagConstraintsGC.cpp.rej
> unable to find 'src/hotspot/share/runtime/commandLineFlagConstraintsGC.hpp' for patching
> 1 out of 1 hunks FAILED -- saving rejects to file src/hotspot/share/runtime/commandLineFlagConstraintsGC.hpp.rej
> patching file src/hotspot/share/runtime/commandLineFlagRangeList.cpp
> Hunk #1 FAILED at 0
> 1 out of 1 hunks FAILED -- saving rejects to file src/hotspot/share/runtime/commandLineFlagRangeList.cpp.rej
> patching file src/hotspot/share/runtime/commandLineFlagWriteableList.cpp
> Hunk #1 FAILED at 0
> 1 out of 1 hunks FAILED -- saving rejects to file src/hotspot/share/runtime/commandLineFlagWriteableList.cpp.rej
> patch failed, unable to continue (try -v)
> patch failed, rejects left in working dir
> errors during apply, please fix and refresh webrev.patch
>
> Could you please provide an updated version? Thank you!
>
> Thomas
>
>
> On Mon, Apr 9, 2018 at 8:35 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
> Hi all,
>
> Here is http://cr.openjdk.java.net/~gziemski/8081519_rev3 with the addition requested by Coleen to include jvmFlag.hpp directly anywhere jvmFlag is used.
>
> Tested locally with open/closed, debug/product, precompiled header/no precompiled header build variations.
>
>
> cheers
>
> > On Apr 5, 2018, at 12:46 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
> >
> > Hi all,
> >
> > Here is webrev 2 with the following additions:
> >
> > #1 Factor FlagSetting class out of "runtime/flags/jvmFlag.hpp" and into its own "runtime/flags/flagSetting.hpp", so that FlagSetting class can extend from ?public StackObj? (thanks Coleen)
> >
> > #2 change the hierarchy from ?runtime/jvmFlag/? to "runtime/flags/? (thanks David)
> >
> > #3 Fix the header files, so that both closed and open repository build with and without precompiled headers
> >
> > #4 Add ?runtime/flags/*.hpp? headers to ?precompiled.hpp?
> >
> > The number of touched files got even longer - sorry about that and big thank you for taking your time to review!
> >
> > Running final Mach5 hs_tier1-5 tests? (it passed earlier iterations). Passes local builds (on Mac OS X) with and without precompiled headers for both closed and open repos and both debug and product versions (should I try any other build varations?)
> >
> > http://cr.openjdk.java.net/~gziemski/8081519_rev2
> >
> >
> > cheers
> >
> >> On Mar 29, 2018, at 2:01 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
> >>
> >> Hi all,
> >>
> >> Please review this large and tedious (sorry), but simple fix that accomplishes the following:
> >>
> >> #1 factor out the command option flag related APIs out of globals.hpp/.cpp into its own dedicated files, i.e. jvmFlag.hpp/.cpp
> >> #2 merge Flag (too generic name) and CommandLineFlag classes and rename them as JVMFlag
> >> #3 cleanup globals.hpp includes originally added by the JEP-245
> >>
> >> Note: the renamed file retain their history, but one needs to add ?follow? flag, ex. ?hg log -f file?
> >>
> >> https://bugs.openjdk.java.net/browse/JDK-8081519
> >> http://cr.openjdk.java.net/~gziemski/8081519_rev1
> >>
> >> Passes Mach5 hs_tier1-tier5, jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges tests.
> >>
> >>
> >> cheers
> >
>
>
From per.liden at oracle.com Wed Apr 11 15:56:03 2018
From: per.liden at oracle.com (Per Liden)
Date: Wed, 11 Apr 2018 17:56:03 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <f13b8b38-1a9f-015d-7d69-5a17dc84bf1e@redhat.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<6b382992-af7a-fd67-1494-ad9301c110db@redhat.com>
<79ed21cd-ca37-f320-2207-b0e141c353ac@oracle.com>
<8d84f53f-5587-79a1-4eae-5891efe71520@redhat.com>
<2aa1c687-07b3-eba8-94b4-4e2abe80c8fa@oracle.com>
<f13b8b38-1a9f-015d-7d69-5a17dc84bf1e@redhat.com>
Message-ID: <86d4ddb7-2682-0ba1-c738-b03b20993ee8@oracle.com>
On 04/11/2018 02:59 PM, Aleksey Shipilev wrote:
> On 04/11/2018 02:37 PM, Per Liden wrote:
>>>> Also, I've shrunk GCThreadLocalData to 112 bytes, which is what G1 currently needs. ZGC currently
>>>> uses 156 bytes (IIRC), but that's a change that should stay the ZGC repo for now.
>>>
>>> Oh. Haven't expected we need that much. This makes me think if we should implement some sort of
>>> STATIC_ASSERT-based overflow checks? Not necessarily in this RFE.
>>
>> Actually, it's already there, in Thread::gc_data().
>
> Right on!
>
>>> *) Also mention the choice of <128 bytes? Like this:
>>>
>>> ? // The size of GCTLD is kept under 128 bytes to let compilers encode
>>> ? // accesses to GCTLD members with short offsets from the Thread.
>>
>> Hmm, I don't quite think this captures the crux of this. To optimize for code compactness, you just
>> need to make sure that the data referenced by generated barriers is kept within a 127 byte offset.
>> For example, in ZGC we only ever reference the first word of the GCTLD in the generated barriers
>> (i.e. well below 127). The rest of the data is used when we hit the slow path, and then we're
>> executing in the VM and don't care about the offset. So, from this point of view, the GCTLD could
>> have any size and it wouldn't matter for code compactness. Same it true for G1 and Shenandoah, i.e.
>> their generated barriers would be unaffected by an increase in GCTLD size.
>
> That's right. My point was to make the stronger and simpler statement about all fields in GCTLD: if
> you put the field in current GCTLD, the access to it from the generated code would likely to be
> optimal. I guess "slow parts" of ZGC's GCTLD is a good counter-example. Nevertheless, I find it
> better to capture the salient points about performance in the implementation notes near the code:
>
> // The current size of GCTLD is kept under 128 bytes to let compilers encode
> // accesses to all GCTLD members with short offsets from the Thread. This is not
> // a hard requirement: we can have fields past 128+ bytes, but low-offset fields would
> // be more efficient to access. Therefore, consider putting more frequently used
> // fields first in GCTLD, in case GCTLD size is extended in future and/or moved
> // within the Thread.
I have the feeling we mean the same thing, but maybe we're coming at
this slightly from different points of view. To me, talking about the
size of GCTLD risks misleading the reader. We're not really keeping the
size under 128 bytes today to because of instruction encoding. We keep
it at 112 because that's enough to cover our current space needs.
However, I think the last part of your proposal captures the main point,
i.e. placing frequently accessed fields first is generally a good idea
to optimize instruction encoding. So, to keep things simple, how about this:
...
// Use Thread::gc_data<T>() to access the data, where T is the
// GC-specific type describing the structure of the data. GCs
// should consider placing frequently accessed fields first in
// T, so that field offsets relative to Thread are small, which
// often allows for a more compact instruction encoding.
...
I'm intentionally not stating a specific offset limit here, since that's
is architecture dependent.
Reasonable?
cheers,
Per
>
> Thanks,
> -Aleksey
>
From shade at redhat.com Wed Apr 11 16:03:14 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 11 Apr 2018 18:03:14 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <86d4ddb7-2682-0ba1-c738-b03b20993ee8@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<6b382992-af7a-fd67-1494-ad9301c110db@redhat.com>
<79ed21cd-ca37-f320-2207-b0e141c353ac@oracle.com>
<8d84f53f-5587-79a1-4eae-5891efe71520@redhat.com>
<2aa1c687-07b3-eba8-94b4-4e2abe80c8fa@oracle.com>
<f13b8b38-1a9f-015d-7d69-5a17dc84bf1e@redhat.com>
<86d4ddb7-2682-0ba1-c738-b03b20993ee8@oracle.com>
Message-ID: <1bb2fef4-fd1e-c9a7-e3fd-09bad1b561af@redhat.com>
On 04/11/2018 05:56 PM, Per Liden wrote:
>> ??? // The current size of GCTLD is kept under 128 bytes to let compilers encode
>> ??? // accesses to all GCTLD members with short offsets from the Thread. This is not
>> ??? // a hard requirement: we can have fields past 128+ bytes, but low-offset fields would
>> ??? // be more efficient to access. Therefore, consider putting more frequently used
>> ??? // fields first in GCTLD, in case GCTLD size is extended in future and/or moved
>> ??? // within the Thread.
>
> I have the feeling we mean the same thing, but maybe we're coming at this slightly from different
> points of view. To me, talking about the size of GCTLD risks misleading the reader. We're not really
> keeping the size under 128 bytes today to because of instruction encoding. We keep it at 112 because
> that's enough to cover our current space needs. However, I think the last part of your proposal
> captures the main point, i.e. placing frequently accessed fields first is generally a good idea to
> optimize instruction encoding. So, to keep things simple, how about this:
>
> ...
> // Use Thread::gc_data<T>() to access the data, where T is the
> // GC-specific type describing the structure of the data. GCs
> // should consider placing frequently accessed fields first in
> // T, so that field offsets relative to Thread are small, which
> // often allows for a more compact instruction encoding.
> ...
>
> I'm intentionally not stating a specific offset limit here, since that's is architecture dependent.
>
> Reasonable?
Yup, thanks!
-Aleksey
From kim.barrett at oracle.com Wed Apr 11 16:12:56 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 11 Apr 2018 12:12:56 -0400
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <f2f9d586-fa23-e474-8e39-fae80483bf5a@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<f2f9d586-fa23-e474-8e39-fae80483bf5a@oracle.com>
Message-ID: <A07CDBC1-C7B6-427F-A906-0D57DB001F32@oracle.com>
> On Apr 11, 2018, at 9:17 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>
> Thanks for reviews, here is an updated version:
>
> Inc:
> http://cr.openjdk.java.net/~rehn/8195099/v3/inc/webrev/
>
> (if you missed v2 it's here: http://cr.openjdk.java.net/~rehn/8195099/v2/)
>
> Full:
> http://cr.openjdk.java.net/~rehn/8195099/v3/webrev/
Looks good.
From rohitarulraj at gmail.com Thu Apr 12 02:25:36 2018
From: rohitarulraj at gmail.com (Rohit Arul Raj)
Date: Thu, 12 Apr 2018 07:55:36 +0530
Subject: RFC: C2 Object Initialization - Using XMM/YMM registers
In-Reply-To: <f21029be-c4a7-8104-6d4b-e6bbd13525b9@oracle.com>
References: <CAPVMLfVcpTXpaTeMwo0Gg=NgDpkz+Z2cD+FP7mw6iHJH5R-+nw@mail.gmail.com>
<f21029be-c4a7-8104-6d4b-e6bbd13525b9@oracle.com>
Message-ID: <CAPVMLfUfCOhRYH0XiY+jx6VewqFYFmKuOZPq8xrUBVGt7RqeVg@mail.gmail.com>
>> When I use XMM0 as a temporary register, the micro-benchmark crashes.
>> Saving and Restoring the XMM0 register before and after use works
>> fine.
>>
>> Looking at the "hotspot/src/cpu/x86/vm/x86.ad" file, XMM0 as with
>> other XMM registers has been mentioned as Save-On-Call registers and
>> on Linux ABI, no register is preserved across function calls though
>> XMM0-XMM7 might hold parameters. So I assumed using XMM0 without
>> saving/restoring should be fine.
>>
>> Is it incorrect use XMM* registers without saving/restoring them?
>> Using XMM10 register as temporary register works fine without having
>> to save and restore it.
Any comments/suggestions on the usage of XMM* registers?
Thanks,
Rohit
On Thu, Apr 5, 2018 at 11:38 PM, Vladimir Kozlov
<vladimir.kozlov at oracle.com> wrote:
> Good suggestion, Rohit
>
> I created new RFE. Please add you suggestion and performance data there:
>
> https://bugs.openjdk.java.net/browse/JDK-8201193
>
> Thanks,
> Vladimir
>
>
> On 4/5/18 12:19 AM, Rohit Arul Raj wrote:
>>
>> Hi All,
>>
>> I was going through the C2 object initialization (zeroing) code based
>> on the below bug entry:
>> https://bugs.openjdk.java.net/browse/JDK-8146801
>>
>> Right now, for longer lengths we use "rep stos" instructions on x86. I
>> was experimenting with using XMM/YMM registers (on AMD EPYC processor)
>> and found that they do improve performance for certain lengths:
>>
>> For lengths > 64 bytes - 512 bytes : improvement is in the range of 8% to
>> 44%
>> For lengths > 512bytes : some lengths show slight
>> improvement in the range of 2% to 7%, others almost same as "rep stos"
>> numbers.
>>
>> I have attached the complete performance data (data.txt) for reference .
>> Can we add this as an user option similar to UseXMMForArrayCopy?
>>
>> I have used the same test case as in
>> (http://cr.openjdk.java.net/~shade/8146801/benchmarks.jar) with
>> additional sizes.
>>
>> Initial Patch:
>> I haven't added the check for 32-bit mode as I need some help with the
>> code (description given below the patch).
>> The code is similar to the one used in array copy stubs
>> (copy_bytes_forward).
>>
>> diff --git a/src/hotspot/cpu/x86/globals_x86.hpp
>> b/src/hotspot/cpu/x86/globals_x86.hpp
>> --- a/src/hotspot/cpu/x86/globals_x86.hpp
>> +++ b/src/hotspot/cpu/x86/globals_x86.hpp
>> @@ -150,6 +150,9 @@
>> product(bool, UseUnalignedLoadStores, false,
>> \
>> "Use SSE2 MOVDQU instruction for Arraycopy")
>> \
>>
>> \
>> + product(bool, UseXMMForObjInit, false,
>> \
>> + "Use XMM/YMM MOVDQU instruction for Object Initialization")
>> \
>> +
>> \
>> product(bool, UseFastStosb, false,
>> \
>> "Use fast-string operation for zeroing: rep stosb")
>> \
>>
>> \
>> diff --git a/src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> b/src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> --- a/src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> +++ b/src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> @@ -7106,6 +7106,56 @@
>> if (UseFastStosb) {
>> shlptr(cnt, 3); // convert to number of bytes
>> rep_stosb();
>> + } else if (UseXMMForObjInit && UseUnalignedLoadStores) {
>> + Label L_loop, L_sloop, L_check, L_tail, L_end;
>> + push(base);
>> + if (UseAVX >= 2)
>> + vpxor(xmm10, xmm10, xmm10, AVX_256bit);
>> + else
>> + vpxor(xmm10, xmm10, xmm10, AVX_128bit);
>> +
>> + jmp(L_check);
>> +
>> + BIND(L_loop);
>> + if (UseAVX >= 2) {
>> + vmovdqu(Address(base, 0), xmm10);
>> + vmovdqu(Address(base, 32), xmm10);
>> + } else {
>> + movdqu(Address(base, 0), xmm10);
>> + movdqu(Address(base, 16), xmm10);
>> + movdqu(Address(base, 32), xmm10);
>> + movdqu(Address(base, 48), xmm10);
>> + }
>> + addptr(base, 64);
>> +
>> + BIND(L_check);
>> + subptr(cnt, 8);
>> + jccb(Assembler::greaterEqual, L_loop);
>> + addptr(cnt, 4);
>> + jccb(Assembler::less, L_tail);
>> + // Copy trailing 32 bytes
>> + if (UseAVX >= 2) {
>> + vmovdqu(Address(base, 0), xmm10);
>> + } else {
>> + movdqu(Address(base, 0), xmm10);
>> + movdqu(Address(base, 16), xmm10);
>> + }
>> + addptr(base, 32);
>> + subptr(cnt, 4);
>> +
>> + BIND(L_tail);
>> + addptr(cnt, 4);
>> + jccb(Assembler::lessEqual, L_end);
>> + decrement(cnt);
>> +
>> + BIND(L_sloop);
>> + movptr(Address(base, 0), tmp);
>> + addptr(base, 8);
>> + decrement(cnt);
>> + jccb(Assembler::greaterEqual, L_sloop);
>> +
>> + BIND(L_end);
>> + pop(base);
>> } else {
>> NOT_LP64(shlptr(cnt, 1);) // convert to number of 32-bit words
>> for 32-bit VM
>> rep_stos();
>>
>>
>> When I use XMM0 as a temporary register, the micro-benchmark crashes.
>> Saving and Restoring the XMM0 register before and after use works
>> fine.
>>
>> Looking at the "hotspot/src/cpu/x86/vm/x86.ad" file, XMM0 as with
>> other XMM registers has been mentioned as Save-On-Call registers and
>> on Linux ABI, no register is preserved across function calls though
>> XMM0-XMM7 might hold parameters. So I assumed using XMM0 without
>> saving/restoring should be fine.
>>
>> Is it incorrect use XMM* registers without saving/restoring them?
>> Using XMM10 register as temporary register works fine without having
>> to save and restore it.
>>
>> Please let me know your comments.
>>
>> Regards,
>> Rohit
>>
>
From robbin.ehn at oracle.com Thu Apr 12 04:59:46 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Thu, 12 Apr 2018 06:59:46 +0200
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <A07CDBC1-C7B6-427F-A906-0D57DB001F32@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<f2f9d586-fa23-e474-8e39-fae80483bf5a@oracle.com>
<A07CDBC1-C7B6-427F-A906-0D57DB001F32@oracle.com>
Message-ID: <b8cb4758-8ac7-b659-4a4f-f9fd277067cc@oracle.com>
On 2018-04-11 18:12, Kim Barrett wrote:
>> On Apr 11, 2018, at 9:17 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>>
>> Thanks for reviews, here is an updated version:
>>
>> Inc:
>> http://cr.openjdk.java.net/~rehn/8195099/v3/inc/webrev/
>>
>> (if you missed v2 it's here: http://cr.openjdk.java.net/~rehn/8195099/v2/)
>>
>> Full:
>> http://cr.openjdk.java.net/~rehn/8195099/v3/webrev/
>
> Looks good.
>
Thanks, Kim!
/Robbin
From thomas.stuefe at gmail.com Thu Apr 12 05:36:54 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 12 Apr 2018 07:36:54 +0200
Subject: RFR(xxs, trivial): 8201475: 8199417 breaks AIX and non-pch on s390
(and presumably aarch64)
Message-ID: <CAA-vtUw7PtnRQBm_xQgW_zEuBwJmj36wcWN8jKTf3mXyqgH_xg@mail.gmail.com>
Hi all,
may I have reviews for this small trivial build fix.
https://bugs.openjdk.java.net/browse/JDK-8201475
http://cr.openjdk.java.net/~stuefe/webrevs/8201475-buildfix/webrev.00/webrev/
sharedRuntime.hpp was missing from the cpu specific files.
aarch64 looked broken too so I fixed it blindly, the fix seemed simple
enough. Could aarch64 folks eye this over please?
Thank you, Thomas
From erik.osterlund at oracle.com Thu Apr 12 06:13:24 2018
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Thu, 12 Apr 2018 08:13:24 +0200
Subject: RFR(xxs,
trivial): 8201475: 8199417 breaks AIX and non-pch on s390 (and
presumably aarch64)
In-Reply-To: <CAA-vtUw7PtnRQBm_xQgW_zEuBwJmj36wcWN8jKTf3mXyqgH_xg@mail.gmail.com>
References: <CAA-vtUw7PtnRQBm_xQgW_zEuBwJmj36wcWN8jKTf3mXyqgH_xg@mail.gmail.com>
Message-ID: <D9D3F729-D6C4-4D28-AE13-E5D820374B95@oracle.com>
Hi Thomas,
Looks good.
Thanks,
/Erik
> On 12 Apr 2018, at 07:36, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>
> Hi all,
>
> may I have reviews for this small trivial build fix.
>
> https://bugs.openjdk.java.net/browse/JDK-8201475
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8201475-buildfix/webrev.00/webrev/
>
> sharedRuntime.hpp was missing from the cpu specific files.
>
> aarch64 looked broken too so I fixed it blindly, the fix seemed simple
> enough. Could aarch64 folks eye this over please?
>
> Thank you, Thomas
From shade at redhat.com Thu Apr 12 07:57:09 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 12 Apr 2018 09:57:09 +0200
Subject: RFR(xxs, trivial): 8201475: 8199417 breaks AIX and non-pch on
s390 (and presumably aarch64)
In-Reply-To: <CAA-vtUw7PtnRQBm_xQgW_zEuBwJmj36wcWN8jKTf3mXyqgH_xg@mail.gmail.com>
References: <CAA-vtUw7PtnRQBm_xQgW_zEuBwJmj36wcWN8jKTf3mXyqgH_xg@mail.gmail.com>
Message-ID: <a5341bb0-42d4-8e7e-c61e-968e3298b212@redhat.com>
On 04/12/2018 07:36 AM, Thomas St?fe wrote:
> http://cr.openjdk.java.net/~stuefe/webrevs/8201475-buildfix/webrev.00/webrev/
>
> sharedRuntime.hpp was missing from the cpu specific files.
>
> aarch64 looked broken too so I fixed it blindly, the fix seemed simple
> enough. Could aarch64 folks eye this over please?
Indeed, aarch64 is broken. Unfortunately, this fix is not enough:
/home/shade/jdk-hs/src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp: In member function ?void
InterpreterMacroAssembler::load_resolved_reference_at_index(Register, Register)?:
/home/shade/jdk-hs/src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp:281:29: error: incomplete type
?BarrierSet? used in nested name specifier
BarrierSetAssembler *bs = BarrierSet::barrier_set()->barrier_set_assembler();
We need to add:
diff -r bdcfe8154201 src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
--- a/src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp Wed Mar 28 22:03:57 2018 +0200
+++ b/src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp Thu Apr 12 09:56:18 2018 +0200
@@ -24,6 +24,7 @@
*/
#include "precompiled.hpp"
+#include "gc/shared/barrierSet.hpp"
#include "gc/shared/barrierSetAssembler.hpp"
#include "interp_masm_aarch64.hpp"
#include "interpreter/interpreter.hpp"
Thanks!
-Aleksey
From martin.doerr at sap.com Thu Apr 12 08:23:02 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 12 Apr 2018 08:23:02 +0000
Subject: RFR(xxs, trivial): 8201475: 8199417 breaks AIX and non-pch on
s390 (and presumably aarch64)
In-Reply-To: <CAA-vtUw7PtnRQBm_xQgW_zEuBwJmj36wcWN8jKTf3mXyqgH_xg@mail.gmail.com>
References: <CAA-vtUw7PtnRQBm_xQgW_zEuBwJmj36wcWN8jKTf3mXyqgH_xg@mail.gmail.com>
Message-ID: <ee7b463ce9c3405fac0d5903a9eeb5d9@sap.com>
Hi Thomas,
thanks for fixing. Looks good. I think it should get pushed today before jdk/hs gets closed.
Best regards,
Martin
-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Thomas St?fe
Sent: Donnerstag, 12. April 2018 07:37
To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
Subject: RFR(xxs, trivial): 8201475: 8199417 breaks AIX and non-pch on s390 (and presumably aarch64)
Hi all,
may I have reviews for this small trivial build fix.
https://bugs.openjdk.java.net/browse/JDK-8201475
http://cr.openjdk.java.net/~stuefe/webrevs/8201475-buildfix/webrev.00/webrev/
sharedRuntime.hpp was missing from the cpu specific files.
aarch64 looked broken too so I fixed it blindly, the fix seemed simple
enough. Could aarch64 folks eye this over please?
Thank you, Thomas
From thomas.stuefe at gmail.com Thu Apr 12 08:39:07 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 12 Apr 2018 08:39:07 +0000
Subject: RFR(xxs, trivial): 8201475: 8199417 breaks AIX and non-pch on
s390 (and presumably aarch64)
In-Reply-To: <ee7b463ce9c3405fac0d5903a9eeb5d9@sap.com>
References: <CAA-vtUw7PtnRQBm_xQgW_zEuBwJmj36wcWN8jKTf3mXyqgH_xg@mail.gmail.com>
<ee7b463ce9c3405fac0d5903a9eeb5d9@sap.com>
Message-ID: <CAA-vtUx26YVzCKnzGMJSRUUosSRpS-5cLdtCvAuiZ2N3hFYxJg@mail.gmail.com>
Will do that.
On Thu, Apr 12, 2018, 10:23 Doerr, Martin <martin.doerr at sap.com> wrote:
> Hi Thomas,
>
> thanks for fixing. Looks good. I think it should get pushed today before
> jdk/hs gets closed.
>
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf
> Of Thomas St?fe
> Sent: Donnerstag, 12. April 2018 07:37
> To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
> Subject: RFR(xxs, trivial): 8201475: 8199417 breaks AIX and non-pch on
> s390 (and presumably aarch64)
>
> Hi all,
>
> may I have reviews for this small trivial build fix.
>
> https://bugs.openjdk.java.net/browse/JDK-8201475
>
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8201475-buildfix/webrev.00/webrev/
>
> sharedRuntime.hpp was missing from the cpu specific files.
>
> aarch64 looked broken too so I fixed it blindly, the fix seemed simple
> enough. Could aarch64 folks eye this over please?
>
> Thank you, Thomas
>
From glaubitz at physik.fu-berlin.de Thu Apr 12 08:43:30 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Thu, 12 Apr 2018 10:43:30 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <a4eb0183-d9b9-35d8-c7c6-9c2e132a3264@oracle.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
<6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
<7f4d51d2-be2f-0984-946b-efa557a7ecc8@oracle.com>
<b89bee8c-c885-dab7-7fb9-07a91d481b70@physik.fu-berlin.de>
<a4eb0183-d9b9-35d8-c7c6-9c2e132a3264@oracle.com>
Message-ID: <8ee55143-ccf2-004b-e096-5b8ec569a6bf@physik.fu-berlin.de>
On 04/10/2018 11:45 PM, David Holmes wrote:
>> diff -r 00805b129186 src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp
>> --- a/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp Tue Apr 10 11:43:40 2018 -0700
>> +++ b/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp Tue Apr 10 22:38:12 2018 +0300
>> @@ -48,7 +48,7 @@
>> ????????? if (vstr != NULL) {
>> ??????????? // We have a matching line and a valid starting point to the value of
>> ??????????? // the field, copy the string for keeps.
>> -????????? _string = strdup(vstr);
>> +????????? _string = os::strdup(vstr, mtInternal);
>> ??????????? break;
>> ????????? }
>> ??????? }
I will get this change merged first. This definitely fixes one crash
on linux-sparc.
> The only reference to that message I can find is from HashMap/HashSet where the load factor defines how full the collection becomes before it resizes. I would have to guess some kind of floating-point issue here - a very small number rather than 0 perhaps?
Then try to track down this issue using hg bisect.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From thomas.stuefe at gmail.com Thu Apr 12 08:56:46 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 12 Apr 2018 10:56:46 +0200
Subject: RFR(xxs, trivial): 8201475: 8199417 breaks AIX and non-pch on
s390 (and presumably aarch64)
In-Reply-To: <CAA-vtUx26YVzCKnzGMJSRUUosSRpS-5cLdtCvAuiZ2N3hFYxJg@mail.gmail.com>
References: <CAA-vtUw7PtnRQBm_xQgW_zEuBwJmj36wcWN8jKTf3mXyqgH_xg@mail.gmail.com>
<ee7b463ce9c3405fac0d5903a9eeb5d9@sap.com>
<CAA-vtUx26YVzCKnzGMJSRUUosSRpS-5cLdtCvAuiZ2N3hFYxJg@mail.gmail.com>
Message-ID: <CAA-vtUxb_PJYFGDo2kR7yHLdQAoxOq_v27MrtEMEfGHY+cLoLA@mail.gmail.com>
rebased and with Alexeys addition:
http://cr.openjdk.java.net/~stuefe/webrevs/8201475-buildfix/webrev.01/webrev/
still good? I like to push this before I need to rebase again...
On Thu, Apr 12, 2018 at 10:39 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> Will do that.
>
> On Thu, Apr 12, 2018, 10:23 Doerr, Martin <martin.doerr at sap.com> wrote:
>>
>> Hi Thomas,
>>
>> thanks for fixing. Looks good. I think it should get pushed today before
>> jdk/hs gets closed.
>>
>> Best regards,
>> Martin
>>
>>
>> -----Original Message-----
>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf
>> Of Thomas St?fe
>> Sent: Donnerstag, 12. April 2018 07:37
>> To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
>> Subject: RFR(xxs, trivial): 8201475: 8199417 breaks AIX and non-pch on
>> s390 (and presumably aarch64)
>>
>> Hi all,
>>
>> may I have reviews for this small trivial build fix.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8201475
>>
>>
>> http://cr.openjdk.java.net/~stuefe/webrevs/8201475-buildfix/webrev.00/webrev/
>>
>> sharedRuntime.hpp was missing from the cpu specific files.
>>
>> aarch64 looked broken too so I fixed it blindly, the fix seemed simple
>> enough. Could aarch64 folks eye this over please?
>>
>> Thank you, Thomas
From shade at redhat.com Thu Apr 12 09:00:01 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 12 Apr 2018 11:00:01 +0200
Subject: RFR(xxs, trivial): 8201475: 8199417 breaks AIX and non-pch on
s390 (and presumably aarch64)
In-Reply-To: <CAA-vtUxb_PJYFGDo2kR7yHLdQAoxOq_v27MrtEMEfGHY+cLoLA@mail.gmail.com>
References: <CAA-vtUw7PtnRQBm_xQgW_zEuBwJmj36wcWN8jKTf3mXyqgH_xg@mail.gmail.com>
<ee7b463ce9c3405fac0d5903a9eeb5d9@sap.com>
<CAA-vtUx26YVzCKnzGMJSRUUosSRpS-5cLdtCvAuiZ2N3hFYxJg@mail.gmail.com>
<CAA-vtUxb_PJYFGDo2kR7yHLdQAoxOq_v27MrtEMEfGHY+cLoLA@mail.gmail.com>
Message-ID: <1e925cbf-abd5-0e96-29a7-c5615ed67a9e@redhat.com>
On 04/12/2018 10:56 AM, Thomas St?fe wrote:
> rebased and with Alexeys addition:
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8201475-buildfix/webrev.01/webrev/
>
> still good? I like to push this before I need to rebase again...
Still good. The changeset synopsis may be changed to [definitely" "breaks aarch64" :)
-Aleksey
From erik.osterlund at oracle.com Thu Apr 12 09:04:57 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Thu, 12 Apr 2018 11:04:57 +0200
Subject: RFR(xxs, trivial): 8201475: 8199417 breaks AIX and non-pch on
s390 (and presumably aarch64)
In-Reply-To: <CAA-vtUxb_PJYFGDo2kR7yHLdQAoxOq_v27MrtEMEfGHY+cLoLA@mail.gmail.com>
References: <CAA-vtUw7PtnRQBm_xQgW_zEuBwJmj36wcWN8jKTf3mXyqgH_xg@mail.gmail.com>
<ee7b463ce9c3405fac0d5903a9eeb5d9@sap.com>
<CAA-vtUx26YVzCKnzGMJSRUUosSRpS-5cLdtCvAuiZ2N3hFYxJg@mail.gmail.com>
<CAA-vtUxb_PJYFGDo2kR7yHLdQAoxOq_v27MrtEMEfGHY+cLoLA@mail.gmail.com>
Message-ID: <5ACF2139.9040902@oracle.com>
Hi,
Still good. Ship it.
Thanks,
/Erik
On 2018-04-12 10:56, Thomas St?fe wrote:
> rebased and with Alexeys addition:
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8201475-buildfix/webrev.01/webrev/
>
> still good? I like to push this before I need to rebase again...
>
> On Thu, Apr 12, 2018 at 10:39 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>> Will do that.
>>
>> On Thu, Apr 12, 2018, 10:23 Doerr, Martin <martin.doerr at sap.com> wrote:
>>> Hi Thomas,
>>>
>>> thanks for fixing. Looks good. I think it should get pushed today before
>>> jdk/hs gets closed.
>>>
>>> Best regards,
>>> Martin
>>>
>>>
>>> -----Original Message-----
>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf
>>> Of Thomas St?fe
>>> Sent: Donnerstag, 12. April 2018 07:37
>>> To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
>>> Subject: RFR(xxs, trivial): 8201475: 8199417 breaks AIX and non-pch on
>>> s390 (and presumably aarch64)
>>>
>>> Hi all,
>>>
>>> may I have reviews for this small trivial build fix.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8201475
>>>
>>>
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8201475-buildfix/webrev.00/webrev/
>>>
>>> sharedRuntime.hpp was missing from the cpu specific files.
>>>
>>> aarch64 looked broken too so I fixed it blindly, the fix seemed simple
>>> enough. Could aarch64 folks eye this over please?
>>>
>>> Thank you, Thomas
From thomas.stuefe at gmail.com Thu Apr 12 09:13:54 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 12 Apr 2018 11:13:54 +0200
Subject: RFR(xxs, trivial): 8201475: 8199417 breaks AIX and non-pch on
s390 (and presumably aarch64)
In-Reply-To: <1e925cbf-abd5-0e96-29a7-c5615ed67a9e@redhat.com>
References: <CAA-vtUw7PtnRQBm_xQgW_zEuBwJmj36wcWN8jKTf3mXyqgH_xg@mail.gmail.com>
<ee7b463ce9c3405fac0d5903a9eeb5d9@sap.com>
<CAA-vtUx26YVzCKnzGMJSRUUosSRpS-5cLdtCvAuiZ2N3hFYxJg@mail.gmail.com>
<CAA-vtUxb_PJYFGDo2kR7yHLdQAoxOq_v27MrtEMEfGHY+cLoLA@mail.gmail.com>
<1e925cbf-abd5-0e96-29a7-c5615ed67a9e@redhat.com>
Message-ID: <CAA-vtUyKdS336BC7MrquN2-a0YTNTAgRXQ5LSc=UOz1N_zxu0Q@mail.gmail.com>
On Thu, Apr 12, 2018 at 11:00 AM, Aleksey Shipilev <shade at redhat.com> wrote:
> On 04/12/2018 10:56 AM, Thomas St?fe wrote:
>> rebased and with Alexeys addition:
>>
>> http://cr.openjdk.java.net/~stuefe/webrevs/8201475-buildfix/webrev.01/webrev/
>>
>> still good? I like to push this before I need to rebase again...
>
> Still good. The changeset synopsis may be changed to [definitely" "breaks aarch64" :)
>
Tried to change it but jbs is down :)
> -Aleksey
From thomas.stuefe at gmail.com Thu Apr 12 09:14:30 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 12 Apr 2018 11:14:30 +0200
Subject: RFR(xxs, trivial): 8201475: 8199417 breaks AIX and non-pch on
s390 (and presumably aarch64)
In-Reply-To: <CAA-vtUxb_PJYFGDo2kR7yHLdQAoxOq_v27MrtEMEfGHY+cLoLA@mail.gmail.com>
References: <CAA-vtUw7PtnRQBm_xQgW_zEuBwJmj36wcWN8jKTf3mXyqgH_xg@mail.gmail.com>
<ee7b463ce9c3405fac0d5903a9eeb5d9@sap.com>
<CAA-vtUx26YVzCKnzGMJSRUUosSRpS-5cLdtCvAuiZ2N3hFYxJg@mail.gmail.com>
<CAA-vtUxb_PJYFGDo2kR7yHLdQAoxOq_v27MrtEMEfGHY+cLoLA@mail.gmail.com>
Message-ID: <CAA-vtUy=cFWZJofYS6zfn4dtjsP0L1hSO+aQzzKo4soq9wSZhw@mail.gmail.com>
Thanks guys, I pushed.
On Thu, Apr 12, 2018 at 10:56 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> rebased and with Alexeys addition:
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8201475-buildfix/webrev.01/webrev/
>
> still good? I like to push this before I need to rebase again...
>
> On Thu, Apr 12, 2018 at 10:39 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>> Will do that.
>>
>> On Thu, Apr 12, 2018, 10:23 Doerr, Martin <martin.doerr at sap.com> wrote:
>>>
>>> Hi Thomas,
>>>
>>> thanks for fixing. Looks good. I think it should get pushed today before
>>> jdk/hs gets closed.
>>>
>>> Best regards,
>>> Martin
>>>
>>>
>>> -----Original Message-----
>>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf
>>> Of Thomas St?fe
>>> Sent: Donnerstag, 12. April 2018 07:37
>>> To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
>>> Subject: RFR(xxs, trivial): 8201475: 8199417 breaks AIX and non-pch on
>>> s390 (and presumably aarch64)
>>>
>>> Hi all,
>>>
>>> may I have reviews for this small trivial build fix.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8201475
>>>
>>>
>>> http://cr.openjdk.java.net/~stuefe/webrevs/8201475-buildfix/webrev.00/webrev/
>>>
>>> sharedRuntime.hpp was missing from the cpu specific files.
>>>
>>> aarch64 looked broken too so I fixed it blindly, the fix seemed simple
>>> enough. Could aarch64 folks eye this over please?
>>>
>>> Thank you, Thomas
From david.holmes at oracle.com Thu Apr 12 09:31:27 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Apr 2018 19:31:27 +1000
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <8ee55143-ccf2-004b-e096-5b8ec569a6bf@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
<6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
<7f4d51d2-be2f-0984-946b-efa557a7ecc8@oracle.com>
<b89bee8c-c885-dab7-7fb9-07a91d481b70@physik.fu-berlin.de>
<a4eb0183-d9b9-35d8-c7c6-9c2e132a3264@oracle.com>
<8ee55143-ccf2-004b-e096-5b8ec569a6bf@physik.fu-berlin.de>
Message-ID: <ff4fdd99-337c-d358-c737-ba0b792c1b9e@oracle.com>
On 12/04/2018 6:43 PM, John Paul Adrian Glaubitz wrote:
> On 04/10/2018 11:45 PM, David Holmes wrote:
>>> diff -r 00805b129186
>>> src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp
>>> --- a/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp Tue
>>> Apr 10 11:43:40 2018 -0700
>>> +++ b/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp Tue
>>> Apr 10 22:38:12 2018 +0300
>>> @@ -48,7 +48,7 @@
>>> ????????? if (vstr != NULL) {
>>> ??????????? // We have a matching line and a valid starting point to
>>> the value of
>>> ??????????? // the field, copy the string for keeps.
>>> -????????? _string = strdup(vstr);
>>> +????????? _string = os::strdup(vstr, mtInternal);
>>> ??????????? break;
>>> ????????? }
>>> ??????? }
>
> I will get this change merged first. This definitely fixes one crash
> on linux-sparc.
I still think the safest fix is to change os::free to ::free, not
::strdup to os::strdup. There are too many codepaths through the os::
code that lead to places where we expect to have an attached thread -
even if they are error paths.
David
-----
>> The only reference to that message I can find is from HashMap/HashSet
>> where the load factor defines how full the collection becomes before
>> it resizes. I would have to guess some kind of floating-point issue
>> here - a very small number rather than 0 perhaps?
>
> Then try to track down this issue using hg bisect.
>
> Adrian
>
From glaubitz at physik.fu-berlin.de Thu Apr 12 09:36:07 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Thu, 12 Apr 2018 11:36:07 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <ff4fdd99-337c-d358-c737-ba0b792c1b9e@oracle.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
<6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
<7f4d51d2-be2f-0984-946b-efa557a7ecc8@oracle.com>
<b89bee8c-c885-dab7-7fb9-07a91d481b70@physik.fu-berlin.de>
<a4eb0183-d9b9-35d8-c7c6-9c2e132a3264@oracle.com>
<8ee55143-ccf2-004b-e096-5b8ec569a6bf@physik.fu-berlin.de>
<ff4fdd99-337c-d358-c737-ba0b792c1b9e@oracle.com>
Message-ID: <3ba27084-5af8-77e9-012e-7a99cc58e48d@physik.fu-berlin.de>
On 04/12/2018 11:31 AM, David Holmes wrote:
>> I will get this change merged first. This definitely fixes one crash
>> on linux-sparc.
>
> I still think the safest fix is to change os::free to ::free, not ::strdup to os::strdup. There are too many codepaths through the os:: code that lead to places where we expect to have an attached thread - even if they are error paths.
Ok, let me test that alternative patch.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From glaubitz at physik.fu-berlin.de Thu Apr 12 09:53:21 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Thu, 12 Apr 2018 11:53:21 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <3ba27084-5af8-77e9-012e-7a99cc58e48d@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
<6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
<7f4d51d2-be2f-0984-946b-efa557a7ecc8@oracle.com>
<b89bee8c-c885-dab7-7fb9-07a91d481b70@physik.fu-berlin.de>
<a4eb0183-d9b9-35d8-c7c6-9c2e132a3264@oracle.com>
<8ee55143-ccf2-004b-e096-5b8ec569a6bf@physik.fu-berlin.de>
<ff4fdd99-337c-d358-c737-ba0b792c1b9e@oracle.com>
<3ba27084-5af8-77e9-012e-7a99cc58e48d@physik.fu-berlin.de>
Message-ID: <ac3390de-e207-f937-0e77-82a6fca3959b@physik.fu-berlin.de>
On 04/12/2018 11:36 AM, John Paul Adrian Glaubitz wrote:
>> I still think the safest fix is to change os::free to ::free, not ::strdup to os::strdup. There are too many codepaths through the os:: code that lead to places where we expect to have an attached thread - even if they are error paths.
>
> Ok, let me test that alternative patch.
Ok, that works as well in the sense that it exposes the "Illegal Load Factor" crash again:
glaubitz at deb4g:/srv/glaubitz/hs$ hg diff
diff -r 46f2dc7c4c39 src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp
--- a/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp Thu Apr 12 11:05:42 2018 +0200
+++ b/src/hotspot/os_cpu/linux_sparc/vm_version_linux_sparc.cpp Thu Apr 12 12:52:00 2018 +0300
@@ -56,7 +56,7 @@
}
}
- ~CPUinfo() { os::free((void*)_string); }
+ ~CPUinfo() { free((void*)_string); }
const char* value() const { return _string; }
glaubitz at deb4g:/srv/glaubitz/hs$ ./build/linux-sparcv9-normal-server-fastdebug/jdk/bin/java --version
Error occurred during initialization of boot layer
java.lang.module.FindException: Error reading module: /srv/glaubitz/hs/build/linux-sparcv9-normal-server-fastdebug/jdk/modules/java.desktop
Caused by: java.lang.module.InvalidModuleDescriptorException: Illegal load factor: -1.2197928E-12
glaubitz at deb4g:/srv/glaubitz/hs$
I'll send a CR with your version.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From glaubitz at physik.fu-berlin.de Thu Apr 12 10:13:06 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Thu, 12 Apr 2018 12:13:06 +0200
Subject: RFR: 8201480: ISA/CPU feature detection code crashes on linux-sparc
Message-ID: <1be0b4cc-9b98-237f-fe62-e1830e901c2b@physik.fu-berlin.de>
Hi!
Please review this small change which fixes a crash on linux-sparc
in the ISA/CPU feature detection code [1].
The change can be found in [2] and affects Hotspot on linux-sparc
only as the change is specific to this target. It does not affect
Zero.
Thanks,
Adrian
> [1] https://bugs.openjdk.java.net/browse/JDK-8201480
> [2] http://cr.openjdk.java.net/~glaubitz/8201480/webrev.01/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From shade at redhat.com Thu Apr 12 10:55:36 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 12 Apr 2018 12:55:36 +0200
Subject: RFR: 8201480: ISA/CPU feature detection code crashes on
linux-sparc
In-Reply-To: <1be0b4cc-9b98-237f-fe62-e1830e901c2b@physik.fu-berlin.de>
References: <1be0b4cc-9b98-237f-fe62-e1830e901c2b@physik.fu-berlin.de>
Message-ID: <1b4998f6-8d6d-323b-11f4-8cb5f6962922@redhat.com>
On 04/12/2018 12:13 PM, John Paul Adrian Glaubitz wrote:
> Please review this small change which fixes a crash on linux-sparc
> in the ISA/CPU feature detection code [1].
>
> The change can be found in [2] and affects Hotspot on linux-sparc
> only as the change is specific to this target. It does not affect
> Zero.
>
> Thanks,
> Adrian
>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8201480
>> [2] http://cr.openjdk.java.net/~glaubitz/8201480/webrev.01/
This looks good to me.
-Aleksey
From david.holmes at oracle.com Thu Apr 12 11:02:29 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Apr 2018 21:02:29 +1000
Subject: RFR: 8201480: ISA/CPU feature detection code crashes on
linux-sparc
In-Reply-To: <1be0b4cc-9b98-237f-fe62-e1830e901c2b@physik.fu-berlin.de>
References: <1be0b4cc-9b98-237f-fe62-e1830e901c2b@physik.fu-berlin.de>
Message-ID: <54a11820-cbd7-0220-da25-c072220cbfa0@oracle.com>
Looks fine to me.
Please update copyright year before pushing.
Thanks,
David
On 12/04/2018 8:13 PM, John Paul Adrian Glaubitz wrote:
> Hi!
>
> Please review this small change which fixes a crash on linux-sparc
> in the ISA/CPU feature detection code [1].
>
> The change can be found in [2] and affects Hotspot on linux-sparc
> only as the change is specific to this target. It does not affect
> Zero.
>
> Thanks,
> Adrian
>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8201480
>> [2] http://cr.openjdk.java.net/~glaubitz/8201480/webrev.01/
>
From thomas.stuefe at gmail.com Thu Apr 12 11:03:00 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 12 Apr 2018 13:03:00 +0200
Subject: RFR: 8201480: ISA/CPU feature detection code crashes on
linux-sparc
In-Reply-To: <1be0b4cc-9b98-237f-fe62-e1830e901c2b@physik.fu-berlin.de>
References: <1be0b4cc-9b98-237f-fe62-e1830e901c2b@physik.fu-berlin.de>
Message-ID: <CAA-vtUx+8mdaqSVrUDwmDKa8L2w5jseLt6Yzarzxp07GWd8OEQ@mail.gmail.com>
Good and trivial. The cast is not needed, I think.
Thanks, Thomas
On Thu, Apr 12, 2018 at 12:13 PM, John Paul Adrian Glaubitz
<glaubitz at physik.fu-berlin.de> wrote:
> Hi!
>
> Please review this small change which fixes a crash on linux-sparc
> in the ISA/CPU feature detection code [1].
>
> The change can be found in [2] and affects Hotspot on linux-sparc
> only as the change is specific to this target. It does not affect
> Zero.
>
> Thanks,
> Adrian
>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8201480
>> [2] http://cr.openjdk.java.net/~glaubitz/8201480/webrev.01/
>
>
> --
> .''`. John Paul Adrian Glaubitz
> : :' : Debian Developer - glaubitz at debian.org
> `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From glaubitz at physik.fu-berlin.de Thu Apr 12 11:37:59 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Thu, 12 Apr 2018 13:37:59 +0200
Subject: RFR: 8201480: ISA/CPU feature detection code crashes on
linux-sparc
In-Reply-To: <54a11820-cbd7-0220-da25-c072220cbfa0@oracle.com>
References: <1be0b4cc-9b98-237f-fe62-e1830e901c2b@physik.fu-berlin.de>
<54a11820-cbd7-0220-da25-c072220cbfa0@oracle.com>
Message-ID: <ffc5fe9a-58d9-2b9f-18b2-61a25450fe11@physik.fu-berlin.de>
On 04/12/2018 01:02 PM, David Holmes wrote:
> Looks fine to me.
Thanks.
> Please update copyright year before pushing.
Will do. Just waiting for the result from the submit repo now.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From jesper.wilhelmsson at oracle.com Thu Apr 12 16:14:59 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Thu, 12 Apr 2018 18:14:59 +0200
Subject: Closing jdk/hs tonight (Re: Merging jdk/hs with jdk/jdk)
In-Reply-To: <952F85EF-BB76-4645-AC05-F843DB83881B@oracle.com>
References: <8819CAD3-AF29-463E-8A76-14440CF37D2B@oracle.com>
<952F85EF-BB76-4645-AC05-F843DB83881B@oracle.com>
Message-ID: <AF1CF463-3A9A-4AAC-9766-01C9C91A35CB@oracle.com>
Hi all,
Just a reminder that we will be closing jdk/hs tonight at 8 pm PST. Please do not push anything to jdk/hs after this time.
I will send another announcement once the PIT snapshot has been integrated to jdk/jdk at which time we will open jdk/jdk for all hotspot pushes.
Thanks,
/Jesper
> On 6 Apr 2018, at 02:37, jesper.wilhelmsson at oracle.com wrote:
>
> Hi all,
>
> I've gotten only positive feedback on this suggestion. The next step
> is to propose a date and outline the steps needed to go through with
> this change.
>
> The proposed date is April 12 (Thursday next week).
>
> The steps are:
>
> 1. jdk/hs is closed for pushes at 8 pm PST on April 12. This is when
> the hotspot nightly takes the snapshot of jdk/hs and starts the nightly
> tests. Please note that this is a hard deadline as the system is
> automated and will take the snapshot on time.
>
> 2. The Thursday snapshot will then be sent through the regular product
> integration testing (PIT) which runs over the weekend.
>
> 3. On Friday, April 13, the hotspot nightly and the hotspot CI (post
> integration testing) will be reconfigured to look at jdk/jdk.
>
> 4. The goal is to get the PIT analysis done by Wednesday, April 18.
> At this point the PIT snapshot will be pushed to jdk/jdk.
>
> 5. Once the PIT snapshot has been pushed to jdk/jdk, the jdk/jdk
> repository will be open for hotspot changes.
>
> In order to minimize the risk of merge conflicts when pushing the
> PIT snapshot to jdk/jdk, we will not open for hotspot changes
> until after the snapshot has been pushed.
>
> It is important that everyone that has a new change in the snapshot
> are available on Monday / Tuesday (April 16-17) to handle any
> problems that might arise as a result of the change. If you know that
> you will not be available these days, make sure someone else can
> cover your change, or hold your push until after the merge is done.
>
> Thanks,
> /Jesper
>
>
>> On 14 Mar 2018, at 22:00, jesper.wilhelmsson at oracle.com <mailto:jesper.wilhelmsson at oracle.com> wrote:
>>
>> All,
>>
>> Over the last couple of years we have left behind a graph of
>> integration forests where each component in the JVM had its own
>> line of development. Today all HotSpot development is done in the
>> same repository, jdk/hs [1]. As a result of merging we have seen
>> several positive effects, ranging from less confusion around
>> where and how to do things, and reduced time for fixes to
>> propagate, to significantly better cooperation between the
>> components, and improved quality of the product. We would like to
>> improve further and therefore we suggest to merge jdk/hs into
>> jdk/jdk [2].
>>
>> As before, we expect this change to build a stronger team spirit
>> between the merged areas, and contribute to less confusion -
>> especially around ramp down phases and similar. We also expect
>> further improvements in quality as changes that cause problems in
>> a different area are found faster and can be dealt with
>> immediately.
>>
>> In the same way as we did in the past, we suggest to try this out
>> as an experiment for at least two weeks (giving us some time to
>> adapt in case of issues). Monitoring and evaluation of the new
>> structure will take place continuously, with an option to revert
>> back if things do not work out. The experiment would keep going
>> for at least a few months, after which we will evaluate it and
>> depending on the results consider making it the new standard. If
>> so, the jdk/hs forest will eventually be retired. As part of this
>> merge we can also retire the newly setup submit-hs [3] repository
>> and do all testing using the submit repo based on jdk/jdk [4].
>>
>> Much like what we have done in the past we would leave the jdk/hs
>> forest around until we see if the experiment works out. We would
>> also lock it down so that no accidental pushes are made to
>> it. Once the jdk/hs forest is locked down, any work in flight
>> based on it would have to be rebased on jdk/jdk.
>>
>> We tried this approach during the last few months of JDK 10
>> development and it worked out fine there.
>>
>> Please let us know if you have any feedback or questions!
>>
>> Thanks,
>> /Jesper
>>
>> [1] http://hg.openjdk.java.net/jdk/hs <http://hg.openjdk.java.net/jdk/hs> <http://hg.openjdk.java.net/jdk/hs <http://hg.openjdk.java.net/jdk/hs>>
>> [2] http://hg.openjdk.java.net/jdk/jdk <http://hg.openjdk.java.net/jdk/jdk> <http://hg.openjdk.java.net/jdk/jdk <http://hg.openjdk.java.net/jdk/jdk>>
>> [3] http://hg.openjdk.java.net/jdk/submit-hs <http://hg.openjdk.java.net/jdk/submit-hs> <http://hg.openjdk.java.net/jdk/submit-hs <http://hg.openjdk.java.net/jdk/submit-hs>>
>> [4] http://hg.openjdk.java.net/jdk/submit <http://hg.openjdk.java.net/jdk/submit> <http://hg.openjdk.java.net/jdk/submit <http://hg.openjdk.java.net/jdk/submit>>
From gerard.ziemski at oracle.com Thu Apr 12 17:50:15 2018
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Thu, 12 Apr 2018 12:50:15 -0500
Subject: RFR (XL) 8081519 Split globals.hpp to factor out the Flag class
In-Reply-To: <8009E1D8-0493-48FC-97C3-3BBDFE76A13F@oracle.com>
References: <D6E4A4E8-8356-4694-BD9C-03AB5FA5BC65@oracle.com>
<6656E162-56BE-4E75-8343-7567715F30C7@oracle.com>
<8009E1D8-0493-48FC-97C3-3BBDFE76A13F@oracle.com>
Message-ID: <93796AC9-2B83-4163-9763-DF443C2FF411@oracle.com>
Hi all,
Here is http://cr.openjdk.java.net/~gziemski/8081519_rev4 with the addition of a merge due to https://bugs.openjdk.java.net/browse/JDK-8201168, which turned out to be nontrivial.
Tested locally with open/closed, debug/product, precompiled header/no precompiled header build variations.
Running Mach5 hs-tier1,2,3,4,5 ...
cheers
> On Apr 9, 2018, at 1:35 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
>
> Hi all,
>
> Here is http://cr.openjdk.java.net/~gziemski/8081519_rev3 with the addition requested by Coleen to include jvmFlag.hpp directly anywhere jvmFlag is used.
>
> Tested locally with open/closed, debug/product, precompiled header/no precompiled header build variations.
>
>
> cheers
>
>> On Apr 5, 2018, at 12:46 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
>>
>> Hi all,
>>
>> Here is webrev 2 with the following additions:
>>
>> #1 Factor FlagSetting class out of "runtime/flags/jvmFlag.hpp" and into its own "runtime/flags/flagSetting.hpp", so that FlagSetting class can extend from ?public StackObj? (thanks Coleen)
>>
>> #2 change the hierarchy from ?runtime/jvmFlag/? to "runtime/flags/? (thanks David)
>>
>> #3 Fix the header files, so that both closed and open repository build with and without precompiled headers
>>
>> #4 Add ?runtime/flags/*.hpp? headers to ?precompiled.hpp?
>>
>> The number of touched files got even longer - sorry about that and big thank you for taking your time to review!
>>
>> Running final Mach5 hs_tier1-5 tests? (it passed earlier iterations). Passes local builds (on Mac OS X) with and without precompiled headers for both closed and open repos and both debug and product versions (should I try any other build varations?)
>>
>> http://cr.openjdk.java.net/~gziemski/8081519_rev2
>>
>>
>> cheers
>>
>>> On Mar 29, 2018, at 2:01 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
>>>
>>> Hi all,
>>>
>>> Please review this large and tedious (sorry), but simple fix that accomplishes the following:
>>>
>>> #1 factor out the command option flag related APIs out of globals.hpp/.cpp into its own dedicated files, i.e. jvmFlag.hpp/.cpp
>>> #2 merge Flag (too generic name) and CommandLineFlag classes and rename them as JVMFlag
>>> #3 cleanup globals.hpp includes originally added by the JEP-245
>>>
>>> Note: the renamed file retain their history, but one needs to add ?follow? flag, ex. ?hg log -f file?
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8081519
>>> http://cr.openjdk.java.net/~gziemski/8081519_rev1
>>>
>>> Passes Mach5 hs_tier1-tier5, jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges tests.
>>>
>>>
>>> cheers
>>
>
From kim.barrett at oracle.com Thu Apr 12 18:59:21 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 12 Apr 2018 14:59:21 -0400
Subject: RFR: 8201450: Provide access to LogHandle tagset
Message-ID: <FB8D07FD-4A54-4944-A6FF-A3BE46B4AC2E@oracle.com>
Please review this small addition to the LogHandle API, providing
access to its _tagset member. This supports constructing a
LogStream from a log level and a LogHandle, among other things.
CR:
https://bugs.openjdk.java.net/browse/JDK-8201450
Webrev:
http://cr.openjdk.java.net/~kbarrett/8201450/open.00/
Testing:
Built on on Oracle supported platforms, hs-tier1.
From stefan.karlsson at oracle.com Thu Apr 12 19:07:39 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 12 Apr 2018 21:07:39 +0200
Subject: RFR: 8201450: Provide access to LogHandle tagset
In-Reply-To: <FB8D07FD-4A54-4944-A6FF-A3BE46B4AC2E@oracle.com>
References: <FB8D07FD-4A54-4944-A6FF-A3BE46B4AC2E@oracle.com>
Message-ID: <d169d938-d83f-d554-9209-42aca353f9e3@oracle.com>
Looks good, and trivial.
StefanK
On 2018-04-12 20:59, Kim Barrett wrote:
> Please review this small addition to the LogHandle API, providing
> access to its _tagset member. This supports constructing a
> LogStream from a log level and a LogHandle, among other things.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8201450
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8201450/open.00/
>
> Testing:
> Built on on Oracle supported platforms, hs-tier1.
>
From coleen.phillimore at oracle.com Thu Apr 12 19:08:25 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 12 Apr 2018 15:08:25 -0400
Subject: RFR (XL) 8081519 Split globals.hpp to factor out the Flag class
In-Reply-To: <93796AC9-2B83-4163-9763-DF443C2FF411@oracle.com>
References: <D6E4A4E8-8356-4694-BD9C-03AB5FA5BC65@oracle.com>
<6656E162-56BE-4E75-8343-7567715F30C7@oracle.com>
<8009E1D8-0493-48FC-97C3-3BBDFE76A13F@oracle.com>
<93796AC9-2B83-4163-9763-DF443C2FF411@oracle.com>
Message-ID: <aa0047bd-03f4-8753-82ae-41dfe8d448c3@oracle.com>
Still good.
Coleen
On 4/12/18 1:50 PM, Gerard Ziemski wrote:
> Hi all,
>
> Here is http://cr.openjdk.java.net/~gziemski/8081519_rev4 with the addition of a merge due to https://bugs.openjdk.java.net/browse/JDK-8201168, which turned out to be nontrivial.
>
> Tested locally with open/closed, debug/product, precompiled header/no precompiled header build variations.
>
> Running Mach5 hs-tier1,2,3,4,5 ...
>
>
> cheers
>
>> On Apr 9, 2018, at 1:35 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
>>
>> Hi all,
>>
>> Here is http://cr.openjdk.java.net/~gziemski/8081519_rev3 with the addition requested by Coleen to include jvmFlag.hpp directly anywhere jvmFlag is used.
>>
>> Tested locally with open/closed, debug/product, precompiled header/no precompiled header build variations.
>>
>>
>> cheers
>>
>>> On Apr 5, 2018, at 12:46 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
>>>
>>> Hi all,
>>>
>>> Here is webrev 2 with the following additions:
>>>
>>> #1 Factor FlagSetting class out of "runtime/flags/jvmFlag.hpp" and into its own "runtime/flags/flagSetting.hpp", so that FlagSetting class can extend from ?public StackObj? (thanks Coleen)
>>>
>>> #2 change the hierarchy from ?runtime/jvmFlag/? to "runtime/flags/? (thanks David)
>>>
>>> #3 Fix the header files, so that both closed and open repository build with and without precompiled headers
>>>
>>> #4 Add ?runtime/flags/*.hpp? headers to ?precompiled.hpp?
>>>
>>> The number of touched files got even longer - sorry about that and big thank you for taking your time to review!
>>>
>>> Running final Mach5 hs_tier1-5 tests? (it passed earlier iterations). Passes local builds (on Mac OS X) with and without precompiled headers for both closed and open repos and both debug and product versions (should I try any other build varations?)
>>>
>>> http://cr.openjdk.java.net/~gziemski/8081519_rev2
>>>
>>>
>>> cheers
>>>
>>>> On Mar 29, 2018, at 2:01 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Please review this large and tedious (sorry), but simple fix that accomplishes the following:
>>>>
>>>> #1 factor out the command option flag related APIs out of globals.hpp/.cpp into its own dedicated files, i.e. jvmFlag.hpp/.cpp
>>>> #2 merge Flag (too generic name) and CommandLineFlag classes and rename them as JVMFlag
>>>> #3 cleanup globals.hpp includes originally added by the JEP-245
>>>>
>>>> Note: the renamed file retain their history, but one needs to add ?follow? flag, ex. ?hg log -f file?
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8081519
>>>> http://cr.openjdk.java.net/~gziemski/8081519_rev1
>>>>
>>>> Passes Mach5 hs_tier1-tier5, jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges tests.
>>>>
>>>>
>>>> cheers
From kim.barrett at oracle.com Thu Apr 12 19:33:18 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 12 Apr 2018 15:33:18 -0400
Subject: RFR: 8201450: Provide access to LogHandle tagset
In-Reply-To: <d169d938-d83f-d554-9209-42aca353f9e3@oracle.com>
References: <FB8D07FD-4A54-4944-A6FF-A3BE46B4AC2E@oracle.com>
<d169d938-d83f-d554-9209-42aca353f9e3@oracle.com>
Message-ID: <AFCFC1CA-F78B-4458-94B6-BEBEF9E78D10@oracle.com>
> On Apr 12, 2018, at 3:07 PM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
>
> Looks good, and trivial.
Thanks.
> StefanK
>
> On 2018-04-12 20:59, Kim Barrett wrote:
>> Please review this small addition to the LogHandle API, providing
>> access to its _tagset member. This supports constructing a
>> LogStream from a log level and a LogHandle, among other things.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8201450
>>
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8201450/open.00/
>>
>> Testing:
>> Built on on Oracle supported platforms, hs-tier1.
From robbin.ehn at oracle.com Thu Apr 12 20:27:28 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Thu, 12 Apr 2018 22:27:28 +0200
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <f2f9d586-fa23-e474-8e39-fae80483bf5a@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<f2f9d586-fa23-e474-8e39-fae80483bf5a@oracle.com>
Message-ID: <5a1ae09d-e541-70d4-1498-6aa933768759@oracle.com>
Hi all, please review this change to the gtest.
I found an issue in the gtest, it have a theoretical worse case of several
hundreds of seconds. With the jtreg timeout of 120 s this can cause sporadic
failures and/or consume time. This is because the readers spent a big majority
of the time inside the read-section, thus there is always a reader thread to
wait for. When running the test on e.g. 1 CPU the write_synchronize will yield
the CPU to a reader (or spin until sleep) but the each reader will consume it's
timeslice. One generation can take one time-slice per reader thread and the test
does at minimum one time 100000 write_synchronize.
I have limited the test to max 100000 write_synchronize or 1 seconds test time.
On a normal machine the test now takes ~400ms (including ~50ms setup time).
Tested locally with 1, 2, many CPU's and I did a couple of hundreds of gtest
runs on different platforms in mach5 and tier-1 run which include the gtests.
Inc: http://rehn-ws.se.oracle.com/cr_mirror/8195099/v4/inc/webrev/
Full: http://rehn-ws.se.oracle.com/cr_mirror/8195099/v4/webrev/
Thanks, Robbin
On 2018-04-11 15:17, Robbin Ehn wrote:
> Thanks for reviews, here is an updated version:
>
> Inc:
> http://cr.openjdk.java.net/~rehn/8195099/v3/inc/webrev/
>
> (if you missed v2 it's here: http://cr.openjdk.java.net/~rehn/8195099/v2/)
>
> Full:
> http://cr.openjdk.java.net/~rehn/8195099/v3/webrev/
>
> Thanks, Robbin
>
> On 04/10/2018 02:18 PM, Robbin Ehn wrote:
>> Hi all,
>>
>> We have moved the global-counter to a separate change-set. The global-counter
>> uses a counter to determine current generation. Any reader needs to have a local
>> counter for which generation is currently read. By increment the global-counter
>> and scan for threads reading an old generation and wait for them to complete, we
>> know when an old generation is not visible (no pre-existing reader). In RCU
>> terms, this creates a grace-period. Making this mechanism suitable for a
>> read-mostly scenario. In this initial change-set we scan JavaThreads and the
>> VMThread.
>>
>> A couple of enhancement to the global-counter will be looked into:
>> - Quiescent state RCU semantic by using the natural state of JavaThreads in
>> the VM.
>> - Asynchronous write synchronize, where reclamation, if there are per-existing
>> reader, is done by the last reader leaving that generation.
>> - Register/deregister threads.
>>
>> The current usage is the upcoming hash-table which uses the global-counter to
>> reclaim memory and to concurrently grow. We have also potential use-cases in
>> other work-in-progress code.
>>
>> The new gtest passes on our platforms. For now you can look at the gtest if
>> you think you have a use-case for this as an example.
>>
>> Code: http://cr.openjdk.java.net/~rehn/8195099/v1/webrev/
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8195099
>>
>> Thanks, Robbin
From kim.barrett at oracle.com Thu Apr 12 20:51:53 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 12 Apr 2018 16:51:53 -0400
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <5a1ae09d-e541-70d4-1498-6aa933768759@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<f2f9d586-fa23-e474-8e39-fae80483bf5a@oracle.com>
<5a1ae09d-e541-70d4-1498-6aa933768759@oracle.com>
Message-ID: <3484A4DF-B195-454D-834A-855B3E553121@oracle.com>
> On Apr 12, 2018, at 4:27 PM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>
> Hi all, please review this change to the gtest.
>
> I found an issue in the gtest, it have a theoretical worse case of several hundreds of seconds. With the jtreg timeout of 120 s this can cause sporadic failures and/or consume time. This is because the readers spent a big majority of the time inside the read-section, thus there is always a reader thread to wait for. When running the test on e.g. 1 CPU the write_synchronize will yield the CPU to a reader (or spin until sleep) but the each reader will consume it's timeslice. One generation can take one time-slice per reader thread and the test does at minimum one time 100000 write_synchronize.
>
> I have limited the test to max 100000 write_synchronize or 1 seconds test time. On a normal machine the test now takes ~400ms (including ~50ms setup time).
>
> Tested locally with 1, 2, many CPU's and I did a couple of hundreds of gtest runs on different platforms in mach5 and tier-1 run which include the gtests.
>
> Inc: http://rehn-ws.se.oracle.com/cr_mirror/8195099/v4/inc/webrev/
> Full: http://rehn-ws.se.oracle.com/cr_mirror/8195099/v4/webrev/
>
> Thanks, Robbin
Looks good.
From kim.barrett at oracle.com Thu Apr 12 21:04:10 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 12 Apr 2018 17:04:10 -0400
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
Message-ID: <776653F7-F598-4454-8562-E70DC892942E@oracle.com>
> On Apr 9, 2018, at 11:03 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>
> VM_Version::determine_features() needs a code blob, and hence
> ResourceMark, on sparc and ppc and s390 I think.
>
> But I think the reason that only sparc fails is that
> VM_Version::determine_features() is called too early on Sparc (as part of
> os::init_before_ergo()). The other platforms call that function later in
> initialization (VM_Version_init() -> init_globals()). Could that be the
> error, and if yes, could VM_Version::determine_features() be delayed?
This sounded familiar to me, so I looked into the history of that placement.
init_before_ergo was created specifically to call determine_features that early:
https://bugs.openjdk.java.net/browse/JDK-8133023
From david.holmes at oracle.com Fri Apr 13 01:45:38 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 13 Apr 2018 11:45:38 +1000
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <776653F7-F598-4454-8562-E70DC892942E@oracle.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<776653F7-F598-4454-8562-E70DC892942E@oracle.com>
Message-ID: <9b7cf256-6e4b-906b-f454-6c0e203a949c@oracle.com>
On 13/04/2018 7:04 AM, Kim Barrett wrote:
>> On Apr 9, 2018, at 11:03 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>>
>> VM_Version::determine_features() needs a code blob, and hence
>> ResourceMark, on sparc and ppc and s390 I think.
VM_Version::determine_features calls the os-cpu specific
VM_Version::platform_features. I don't see where a code blob is being
used on Solaris sparc, or Linux sparc. ??
David
-----
>>
>> But I think the reason that only sparc fails is that
>> VM_Version::determine_features() is called too early on Sparc (as part of
>> os::init_before_ergo()). The other platforms call that function later in
>> initialization (VM_Version_init() -> init_globals()). Could that be the
>> error, and if yes, could VM_Version::determine_features() be delayed?
>
> This sounded familiar to me, so I looked into the history of that placement.
> init_before_ergo was created specifically to call determine_features that early:
>
> https://bugs.openjdk.java.net/browse/JDK-8133023
>
From david.holmes at oracle.com Fri Apr 13 02:03:55 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 13 Apr 2018 12:03:55 +1000
Subject: RFR (XL) 8081519 Split globals.hpp to factor out the Flag class
In-Reply-To: <aa0047bd-03f4-8753-82ae-41dfe8d448c3@oracle.com>
References: <D6E4A4E8-8356-4694-BD9C-03AB5FA5BC65@oracle.com>
<6656E162-56BE-4E75-8343-7567715F30C7@oracle.com>
<8009E1D8-0493-48FC-97C3-3BBDFE76A13F@oracle.com>
<93796AC9-2B83-4163-9763-DF443C2FF411@oracle.com>
<aa0047bd-03f4-8753-82ae-41dfe8d448c3@oracle.com>
Message-ID: <55376ef7-ebc4-2ee5-47a6-363760aefbf2@oracle.com>
+1
David
On 13/04/2018 5:08 AM, coleen.phillimore at oracle.com wrote:
> Still good.
> Coleen
>
> On 4/12/18 1:50 PM, Gerard Ziemski wrote:
>> Hi all,
>>
>> Here is http://cr.openjdk.java.net/~gziemski/8081519_rev4 with the
>> addition of a merge due to
>> https://bugs.openjdk.java.net/browse/JDK-8201168, which turned out to
>> be nontrivial.
>>
>> Tested locally with open/closed, debug/product, precompiled header/no
>> precompiled header build variations.
>>
>> Running Mach5 hs-tier1,2,3,4,5 ...
>>
>>
>> cheers
>>
>>> On Apr 9, 2018, at 1:35 PM, Gerard Ziemski
>>> <gerard.ziemski at oracle.com> wrote:
>>>
>>> Hi all,
>>>
>>> Here is http://cr.openjdk.java.net/~gziemski/8081519_rev3 with the
>>> addition requested by Coleen to include jvmFlag.hpp directly anywhere
>>> jvmFlag is used.
>>>
>>> Tested locally with open/closed, debug/product, precompiled header/no
>>> precompiled header build variations.
>>>
>>>
>>> cheers
>>>
>>>> On Apr 5, 2018, at 12:46 PM, Gerard Ziemski
>>>> <gerard.ziemski at oracle.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Here is webrev 2 with the following additions:
>>>>
>>>> #1 Factor FlagSetting class out of "runtime/flags/jvmFlag.hpp" and
>>>> into its own "runtime/flags/flagSetting.hpp", so that FlagSetting
>>>> class can extend from ?public StackObj? (thanks Coleen)
>>>>
>>>> #2 change the hierarchy from ?runtime/jvmFlag/? to "runtime/flags/?
>>>> (thanks David)
>>>>
>>>> #3 Fix the header files, so that both closed and open repository
>>>> build with and without precompiled headers
>>>>
>>>> #4 Add ?runtime/flags/*.hpp? headers to ?precompiled.hpp?
>>>>
>>>> The number of touched files got even longer - sorry about that and
>>>> big thank you for taking your time to review!
>>>>
>>>> Running final Mach5 hs_tier1-5 tests? (it passed earlier
>>>> iterations). Passes local builds (on Mac OS X) with and without
>>>> precompiled headers for both closed and open repos and both debug
>>>> and product versions (should I try any other build varations?)
>>>>
>>>> http://cr.openjdk.java.net/~gziemski/8081519_rev2
>>>>
>>>>
>>>> cheers
>>>>
>>>>> On Mar 29, 2018, at 2:01 PM, Gerard Ziemski
>>>>> <gerard.ziemski at oracle.com> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Please review this large and tedious (sorry), but simple fix that
>>>>> accomplishes the following:
>>>>>
>>>>> #1 factor out the command option flag related APIs out of
>>>>> globals.hpp/.cpp into its own dedicated files, i.e. jvmFlag.hpp/.cpp
>>>>> #2 merge Flag (too generic name) and CommandLineFlag classes and
>>>>> rename them as JVMFlag
>>>>> #3 cleanup globals.hpp includes originally added by the JEP-245
>>>>>
>>>>> Note: the renamed file retain their history, but one needs to add
>>>>> ?follow? flag, ex. ?hg log -f file?
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8081519
>>>>> http://cr.openjdk.java.net/~gziemski/8081519_rev1
>>>>>
>>>>> Passes Mach5 hs_tier1-tier5,
>>>>> jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges
>>>>> tests.
>>>>>
>>>>>
>>>>> cheers
>
From matthias.baesken at sap.com Fri Apr 13 05:48:23 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 13 Apr 2018 05:48:23 +0000
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
places in function declarations/implementations
In-Reply-To: <9fff2e7e-06ac-54c1-8f66-33bff34ea621@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
<81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com>
<7c5e68c2a023490e96ce6452fbda1700@sap.com>
<c7f9df33-e9c8-2fcd-f8bd-df7f5a1e2494@oracle.com>
<9fff2e7e-06ac-54c1-8f66-33bff34ea621@oracle.com>
Message-ID: <f6dbd54e78714305b78ecd3a3d232f11@sap.com>
Hi Phil/Alexey, thanks for adding the other lists .
> Is this the current version of the change : http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ ?
Yes.
Best regards, Matthias
> -----Original Message-----
> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
> Sent: Donnerstag, 12. April 2018 23:53
> To: Phil Race <philip.race at oracle.com>; Baesken, Matthias
> <matthias.baesken at sap.com>; Alan Bateman <Alan.Bateman at oracle.com>;
> Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
> Cc: build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Doerr,
> Martin <martin.doerr at sap.com>; 2d-dev <2d-dev at openjdk.java.net>;
> hotspot-dev <hotspot-dev at openjdk.java.net>
> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> some places in function declarations/implementations
>
>
> On 12/04/2018 21:42, Phil Race wrote:
> > How can JNIEXPORT be different between 32 bit & 64 bit ?
> > I'm sure you saw compilation errors but I don't get why it failed for
> > 32 only.
> >
> > JNICALL (_stdcall) may be unnecessary on 64 bit Windows but that doesn't
> > explain why the 32 bit compiler would complain about inconsistent
> > application
> > of __declspec(dllexport) - ie JNIEXPORT.
> >
> > Or is that part (adding JNIEXPORT) pure clean up and the compilation
> > errors were all down to JNICALL ?
>
> Adding missing JNIEXPORT is for cleanup only.
>
> The compiler complained about mismatched JNICALL / non-JNICALL
> declarations as the macro changes calling convention from the default
> __cdecl? to __stdcall on 32 bit Windows.
>
> Another issue is that __stdcall decorates the functions: prefixes with
> underscore and postfixes with @ + size of parameters. Because of the
> decorations, classLoader.cpp can't lookup the required functions by name
> from zip.dll and jimage.dll. The functions are exported but with
> different name.
>
> I hope this information adds more details to the picture.
>
> > I was a bit puzzled at the removals I saw here :
> >
> >
> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.deskto
> p/share/native/libsplashscreen/splashscreen_impl.h.udiff.html
> >
> >
> > .. I needed to look at the whole file to realise that you were
> > removing a duplicate
> > declaration.
>
> That was tricky. I could have been mentioned in the review.
>
>
> Regards,
> Alexey
>
> >
> > -phil.
> >
> > On 04/12/2018 04:04 AM, Baesken, Matthias wrote:
> >> Hi? Alan , this is the up to date webrev .
> >> However we want to add?? Alexey?? Ivanov? as additional? author .
> >>
> >>> As I read it, this changes the calling convention of these functions on
> >>> 32-bit Windows but it will have no impact on 64-bit Windows (as
> >>> __stdcall is ignored) or other platforms, is that correct?
> >>>
> >> The? change adds? JNIEXPORT?? at some places? where it is? ben
> >> forgotten , for example :
> >>
> >>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.deskto
> p/share/native/libmlib_image/mlib_c_ImageLookUp.c.udiff.html
> >>
> >>
> >> This might have? potential? impact? on other platforms?? (fixes the
> >> mismatches) .
> >>
> >> Best regards, Matthias
> >>
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
> >>> Sent: Donnerstag, 12. April 2018 12:54
> >>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
> Bursie
> >>> <magnus.ihse.bursie at oracle.com>
> >>> Cc: build-dev at openjdk.java.net; Doerr, Martin
> <martin.doerr at sap.com>;
> >>> core-libs-dev at openjdk.java.net
> >>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
> >>> function
> >>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> >>> some places in function declarations/implementations
> >>>
> >>> Adding core-libs-dev as this is change code in libjava, libzip,
> >>> libjimage, ...
> >>>
> >>> Can you confirm that this is the up to date webrev:
> >>> ???? http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
> >>>
> >>> As I read it, this changes the calling convention of these functions on
> >>> 32-bit Windows but it will have no impact on 64-bit Windows (as
> >>> __stdcall is ignored) or other platforms, is that correct?
> >>>
> >>> -Alan
> >>>
> >>>
> >>> On 06/04/2018 14:20, Baesken, Matthias wrote:
> >>>> Hello, I just noticed? 2? additonal issues? regarding
> >>>> mapfile-removal :
> >>>>
> >>>>
> >>>> ??? 1.? The?? follow up change? that removed?? mapfiles for exes
> >>>> as well
> >>> leads on Win32 bit? to? this link error :
> >>>> ??? Creating library
> >>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and
> >>> object
> >>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
> >>>> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main
> >>> referenced in function ___tmainCRTStartup
> >>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe
> :
> >>> fatal error LNK1120: 1 unresolved externals
> >>>>
> >>>> Looks like we? cannot have?? JNICALL?? in main.c?? :
> >>>>
> >>>> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c
> >>>> --- a/src/java.base/share/native/launcher/main.c??????? Thu Apr 05
> >>>> 14:39:04
> >>> 2018 -0700
> >>>> +++ b/src/java.base/share/native/launcher/main.c??????? Fri Apr 06
> >>>> 15:16:40
> >>> 2018 +0200
> >>>> @@ -93,7 +93,7 @@
> >>>> ?????? __initenv = _environ;
> >>>>
> >>>> #else /* JAVAW */
> >>>> -JNIEXPORT int JNICALL
> >>>> +JNIEXPORT int
> >>>> main(int argc, char **argv)
> >>>> {
> >>>> ?????? int margc;
> >>>>
> >>>>
> >>>>
> >>>> ??? 1.? Zip-library? has runtime issues?? when? symbols? are
> >>>> resolved? in
> >>> src/hotspot/share/classfile/classLoader.cpp.
> >>>> I added? the declaration of the missing symbol, this seems to fix it .
> >>>>
> >>>>
> >>>> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h
> >>>> --- a/src/java.base/share/native/libzip/zip_util.h????? Thu Apr 05
> >>>> 14:39:04
> >>> 2018 -0700
> >>>> +++ b/src/java.base/share/native/libzip/zip_util.h????? Fri Apr 06
> >>>> 15:16:40
> >>> 2018 +0200
> >>>> @@ -284,4 +284,7 @@
> >>>> JNIEXPORT jboolean JNICALL
> >>>> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong
> >>>> outLen, char
> >>> **pmsg);
> >>>> +JNIEXPORT jint JNICALL
> >>>> +ZIP_CRC32(jint crc, const jbyte *buf, jint len);
> >>>> +
> >>>>
> >>>>
> >>>> Should I? prepare? another? bug,? or? add this to the existing one
> >>>> and??? post a
> >>> second webrev ?
> >>>> Best regards, Matthias
> >>>>
> >>>>
> >>>> From: Baesken, Matthias
> >>>> Sent: Freitag, 6. April 2018 09:54
> >>>> To: 'Magnus Ihse Bursie' <magnus.ihse.bursie at oracle.com>
> >>>> Cc: build-dev at openjdk.java.net; Doerr, Martin
> <martin.doerr at sap.com>
> >>>> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in
> >>> function declarations/implementations - was : RE: missing JNIEXPORT /
> >>> JNICALL at some places in function declarations/implementations
> >>>> Hello, please review :
> >>>>
> >>>> Bug :
> >>>>
> >>>> https://bugs.openjdk.java.net/browse/JDK-8201226
> >>>>
> >>>> change :
> >>>>
> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
> >>>>
> >>>> mostly I added? JNIEXPORT / JNICALL at some places? where the
> win32bit
> >>> build missed it .
> >>>> A difference is
> >>> src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h
> >>>> Where I removed?? a few? declarations (one? decl?? with one without
> >>> JNIEXPORT / JNICALL ? looked a bit strange ) .
> >>>> Best regards , Matthias
> >>>>
> >>>>
> >>>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com]
> >>>> Sent: Donnerstag, 5. April 2018 17:45
> >>>> To: Baesken, Matthias
> >>> <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>
> >>>> Cc: build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>;
> >>> Doerr, Martin
> <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>
> >>>> Subject: Re: missing JNIEXPORT / JNICALL at some places in function
> >>> declarations/implementations
> >>>> That's most likely a result of the new JNIEXPORT I added as part of
> >>>> the
> >>> mapfile removal.
> >>>> I tried to match header file and C file, but I can certainly have
> >>>> missed cases.
> >>> If I didn't get any warnings, it was hard to know what I missed.
> >>>> Please do submit your patch.
> >>>>
> >>>> I'm a bit surprised 32-bit Window is still buildable. :)
> >>>>
> >>>> /Magnus
> >>>>
> >>>> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias
> >>> <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>:
> >>>> Hello, we noticed? that? at a number of places in the coding? ,?? the
> >>> JNIEXPORT and/or?? JNICALL modifiers?? do not match? when one
> compares
> >>> the declaration and
> >>>> The implementation of functions.
> >>>> While this is ok on most platforms, it seems to fail on Windows 32
> >>>> bit and
> >>> leads to errors like this one :
> >>>>
> >>>
> e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/ml
> >>>
> >>> ib_ImageConvKernelConvert.c(87) : error C2373:
> >>> 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type
> >>> modifiers
> >>>
> e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\ml
> >>>
> >>> ib_image_proto.h(2630) : see declaration of
> >>> 'j2d_mlib_ImageConvKernelConvert'
> >>>> (there are quite a few of these e.g. in mlib? / splashscreen etc.)
> >>>>
> >>>>
> >>>> Another example is this one :
> >>>>
> >>>> diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp
> >>>> --- a/src/java.base/share/native/libjimage/jimage.hpp? Thu Apr 05
> >>>> 09:55:16
> >>> 2018 +0200
> >>>> +++ b/src/java.base/share/native/libjimage/jimage.hpp Thu Apr 05
> >>> 17:07:40 2018 +0200
> >>>> @@ -126,7 +126,7 @@
> >>>> ??? *?? JImageLocationRef location = (*JImageFindResource)(image,
> >>>> ??? *??????????????????????????????? "java.base", "9.0",
> >>>> "java/lang/String.class", &size);
> >>>> ??? */
> >>>> -extern "C" JNIEXPORT JImageLocationRef
> >>> JIMAGE_FindResource(JImageFile* jimage,
> >>>> +extern "C" JNIEXPORT JImageLocationRef JNICALL
> >>> JIMAGE_FindResource(JImageFile* jimage,
> >>>> ?????????? const char* module_name, const char* version, const
> >>>> char* name,
> >>>> ?????????? jlong* size);
> >>>>
> >>>>
> >>>> Is there some generic way to get? the? same? declarations /
> >>>> impementations
> >>> in the code? ?
> >>>> Or should I just add a patch with my findings ?
> >>>>
> >>>> Best regards, Matthias
> >>>>
> >
From erik.osterlund at oracle.com Fri Apr 13 09:02:20 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Fri, 13 Apr 2018 11:02:20 +0200
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <5a1ae09d-e541-70d4-1498-6aa933768759@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<f2f9d586-fa23-e474-8e39-fae80483bf5a@oracle.com>
<5a1ae09d-e541-70d4-1498-6aa933768759@oracle.com>
Message-ID: <5AD0721C.304@oracle.com>
Hi Robbin,
Looks good.
Thanks,
/ERik
On 2018-04-12 22:27, Robbin Ehn wrote:
> Hi all, please review this change to the gtest.
>
> I found an issue in the gtest, it have a theoretical worse case of
> several hundreds of seconds. With the jtreg timeout of 120 s this can
> cause sporadic failures and/or consume time. This is because the
> readers spent a big majority of the time inside the read-section, thus
> there is always a reader thread to wait for. When running the test on
> e.g. 1 CPU the write_synchronize will yield the CPU to a reader (or
> spin until sleep) but the each reader will consume it's timeslice. One
> generation can take one time-slice per reader thread and the test does
> at minimum one time 100000 write_synchronize.
>
> I have limited the test to max 100000 write_synchronize or 1 seconds
> test time. On a normal machine the test now takes ~400ms (including
> ~50ms setup time).
>
> Tested locally with 1, 2, many CPU's and I did a couple of hundreds of
> gtest runs on different platforms in mach5 and tier-1 run which
> include the gtests.
>
> Inc: http://rehn-ws.se.oracle.com/cr_mirror/8195099/v4/inc/webrev/
> Full: http://rehn-ws.se.oracle.com/cr_mirror/8195099/v4/webrev/
>
> Thanks, Robbin
>
>
> On 2018-04-11 15:17, Robbin Ehn wrote:
>> Thanks for reviews, here is an updated version:
>>
>> Inc:
>> http://cr.openjdk.java.net/~rehn/8195099/v3/inc/webrev/
>>
>> (if you missed v2 it's here:
>> http://cr.openjdk.java.net/~rehn/8195099/v2/)
>>
>> Full:
>> http://cr.openjdk.java.net/~rehn/8195099/v3/webrev/
>>
>> Thanks, Robbin
>>
>> On 04/10/2018 02:18 PM, Robbin Ehn wrote:
>>> Hi all,
>>>
>>> We have moved the global-counter to a separate change-set. The
>>> global-counter
>>> uses a counter to determine current generation. Any reader needs to
>>> have a local
>>> counter for which generation is currently read. By increment the
>>> global-counter
>>> and scan for threads reading an old generation and wait for them to
>>> complete, we
>>> know when an old generation is not visible (no pre-existing reader).
>>> In RCU
>>> terms, this creates a grace-period. Making this mechanism suitable
>>> for a read-mostly scenario. In this initial change-set we scan
>>> JavaThreads and the VMThread.
>>>
>>> A couple of enhancement to the global-counter will be looked into:
>>> - Quiescent state RCU semantic by using the natural state of
>>> JavaThreads in the VM.
>>> - Asynchronous write synchronize, where reclamation, if there are
>>> per-existing
>>> reader, is done by the last reader leaving that generation.
>>> - Register/deregister threads.
>>>
>>> The current usage is the upcoming hash-table which uses the
>>> global-counter to reclaim memory and to concurrently grow. We have
>>> also potential use-cases in
>>> other work-in-progress code.
>>>
>>> The new gtest passes on our platforms. For now you can look at the
>>> gtest if you think you have a use-case for this as an example.
>>>
>>> Code: http://cr.openjdk.java.net/~rehn/8195099/v1/webrev/
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8195099
>>>
>>> Thanks, Robbin
From robbin.ehn at oracle.com Fri Apr 13 09:32:32 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Fri, 13 Apr 2018 11:32:32 +0200
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <3484A4DF-B195-454D-834A-855B3E553121@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<f2f9d586-fa23-e474-8e39-fae80483bf5a@oracle.com>
<5a1ae09d-e541-70d4-1498-6aa933768759@oracle.com>
<3484A4DF-B195-454D-834A-855B3E553121@oracle.com>
Message-ID: <8ce5254b-1c24-f59e-7fa2-3ae16ef52bb5@oracle.com>
Thanks, Robbin!
On 04/12/2018 10:51 PM, Kim Barrett wrote:
>> On Apr 12, 2018, at 4:27 PM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>>
>> Hi all, please review this change to the gtest.
>>
>> I found an issue in the gtest, it have a theoretical worse case of several hundreds of seconds. With the jtreg timeout of 120 s this can cause sporadic failures and/or consume time. This is because the readers spent a big majority of the time inside the read-section, thus there is always a reader thread to wait for. When running the test on e.g. 1 CPU the write_synchronize will yield the CPU to a reader (or spin until sleep) but the each reader will consume it's timeslice. One generation can take one time-slice per reader thread and the test does at minimum one time 100000 write_synchronize.
>>
>> I have limited the test to max 100000 write_synchronize or 1 seconds test time. On a normal machine the test now takes ~400ms (including ~50ms setup time).
>>
>> Tested locally with 1, 2, many CPU's and I did a couple of hundreds of gtest runs on different platforms in mach5 and tier-1 run which include the gtests.
>>
>> Inc: http://rehn-ws.se.oracle.com/cr_mirror/8195099/v4/inc/webrev/
>> Full: http://rehn-ws.se.oracle.com/cr_mirror/8195099/v4/webrev/
>>
>> Thanks, Robbin
>
> Looks good.
>
From robbin.ehn at oracle.com Fri Apr 13 09:32:51 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Fri, 13 Apr 2018 11:32:51 +0200
Subject: RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism
In-Reply-To: <5AD0721C.304@oracle.com>
References: <a047194c-1946-984b-3e8d-3f38f5d12015@oracle.com>
<f2f9d586-fa23-e474-8e39-fae80483bf5a@oracle.com>
<5a1ae09d-e541-70d4-1498-6aa933768759@oracle.com> <5AD0721C.304@oracle.com>
Message-ID: <348fb532-2187-59e3-83dc-e270209f5f97@oracle.com>
Thanks, Robbin!
On 04/13/2018 11:02 AM, Erik ?sterlund wrote:
> Hi Robbin,
>
> Looks good.
>
> Thanks,
> /ERik
>
> On 2018-04-12 22:27, Robbin Ehn wrote:
>> Hi all, please review this change to the gtest.
>>
>> I found an issue in the gtest, it have a theoretical worse case of several
>> hundreds of seconds. With the jtreg timeout of 120 s this can cause sporadic
>> failures and/or consume time. This is because the readers spent a big majority
>> of the time inside the read-section, thus there is always a reader thread to
>> wait for. When running the test on e.g. 1 CPU the write_synchronize will yield
>> the CPU to a reader (or spin until sleep) but the each reader will consume
>> it's timeslice. One generation can take one time-slice per reader thread and
>> the test does at minimum one time 100000 write_synchronize.
>>
>> I have limited the test to max 100000 write_synchronize or 1 seconds test
>> time. On a normal machine the test now takes ~400ms (including ~50ms setup time).
>>
>> Tested locally with 1, 2, many CPU's and I did a couple of hundreds of gtest
>> runs on different platforms in mach5 and tier-1 run which include the gtests.
>>
>> Inc: http://rehn-ws.se.oracle.com/cr_mirror/8195099/v4/inc/webrev/
>> Full: http://rehn-ws.se.oracle.com/cr_mirror/8195099/v4/webrev/
>>
>> Thanks, Robbin
>>
>>
>> On 2018-04-11 15:17, Robbin Ehn wrote:
>>> Thanks for reviews, here is an updated version:
>>>
>>> Inc:
>>> http://cr.openjdk.java.net/~rehn/8195099/v3/inc/webrev/
>>>
>>> (if you missed v2 it's here: http://cr.openjdk.java.net/~rehn/8195099/v2/)
>>>
>>> Full:
>>> http://cr.openjdk.java.net/~rehn/8195099/v3/webrev/
>>>
>>> Thanks, Robbin
>>>
>>> On 04/10/2018 02:18 PM, Robbin Ehn wrote:
>>>> Hi all,
>>>>
>>>> We have moved the global-counter to a separate change-set. The global-counter
>>>> uses a counter to determine current generation. Any reader needs to have a
>>>> local
>>>> counter for which generation is currently read. By increment the global-counter
>>>> and scan for threads reading an old generation and wait for them to
>>>> complete, we
>>>> know when an old generation is not visible (no pre-existing reader). In RCU
>>>> terms, this creates a grace-period. Making this mechanism suitable for a
>>>> read-mostly scenario. In this initial change-set we scan JavaThreads and the
>>>> VMThread.
>>>>
>>>> A couple of enhancement to the global-counter will be looked into:
>>>> - Quiescent state RCU semantic by using the natural state of JavaThreads in
>>>> the VM.
>>>> - Asynchronous write synchronize, where reclamation, if there are per-existing
>>>> reader, is done by the last reader leaving that generation.
>>>> - Register/deregister threads.
>>>>
>>>> The current usage is the upcoming hash-table which uses the global-counter
>>>> to reclaim memory and to concurrently grow. We have also potential use-cases in
>>>> other work-in-progress code.
>>>>
>>>> The new gtest passes on our platforms. For now you can look at the gtest if
>>>> you think you have a use-case for this as an example.
>>>>
>>>> Code: http://cr.openjdk.java.net/~rehn/8195099/v1/webrev/
>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8195099
>>>>
>>>> Thanks, Robbin
>
From coleen.phillimore at oracle.com Fri Apr 13 12:12:42 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 13 Apr 2018 08:12:42 -0400
Subject: RFR (M) 8201505: Use WeakHandle for ProtectionDomainCacheTable and
ResolvedMethodTable
Message-ID: <7091958f-01a0-beb0-7ab7-2372944f54b1@oracle.com>
8193524: Redefining a method that removes use of 1 or more lambda
expressions causes the JVM to hang
Summary: Remove oop pointers from runtime data structures and fix
missing next assignment.
Also, this contains a fix for
https://bugs.openjdk.java.net/browse/JDK-8193524 (forgotten next pointer
assignment) because I changed that function 3 lines up, and tests
contributed by Lois.
Tested with mach5 tier1-5.
Thanks,
Coleen
From coleen.phillimore at oracle.com Fri Apr 13 12:16:03 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 13 Apr 2018 08:16:03 -0400
Subject: RFR (M) 8201505: Use WeakHandle for ProtectionDomainCacheTable
and ResolvedMethodTable
In-Reply-To: <7091958f-01a0-beb0-7ab7-2372944f54b1@oracle.com>
References: <7091958f-01a0-beb0-7ab7-2372944f54b1@oracle.com>
Message-ID: <43780f09-b3b2-ccfd-e39a-ce058ef2d64b@oracle.com>
And here's the webrev:
open webrev at http://cr.openjdk.java.net/~coleenp/8201505.01/webrev
bug link https://bugs.openjdk.java.net/browse/JDK-8201505
Thanks,
Coleen
On 4/13/18 8:12 AM, coleen.phillimore at oracle.com wrote:
> 8193524: Redefining a method that removes use of 1 or more lambda
> expressions causes the JVM to hang
> Summary: Remove oop pointers from runtime data structures and fix
> missing next assignment.
>
> Also, this contains a fix for
> https://bugs.openjdk.java.net/browse/JDK-8193524 (forgotten next
> pointer assignment) because I changed that function 3 lines up, and
> tests contributed by Lois.
>
> Tested with mach5 tier1-5.
>
> Thanks,
> Coleen
>
From aph at redhat.com Fri Apr 13 13:33:50 2018
From: aph at redhat.com (Andrew Haley)
Date: Fri, 13 Apr 2018 14:33:50 +0100
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
Message-ID: <f1c9b155-7f06-262c-98f6-f0d3d3b025b6@redhat.com>
On 04/10/2018 01:51 PM, Per Liden wrote:
> A couple of commits were pushed, which causes conflicts with this
> change, so here's a rebased version:
>
> http://cr.openjdk.java.net/~pliden/8201318/webrev.1
Did the Graal changes go upstream?
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From adam.farley at uk.ibm.com Fri Apr 13 14:14:49 2018
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Fri, 13 Apr 2018 15:14:49 +0100
Subject: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory
Usage for Direct Byte Buffers
Message-ID: <OF081603B6.A5E4A0E9-ON0025826E.00432B47-8025826E.004E432A@notes.na.collabserv.com>
Hi Alan, Peter,
I see that native memory is tracked in java.nio.Bits, but that only
includes what the user thinks they are allocating.
When the VM adds extra memory to the allocation amount this extra bit is
not represented in the Bits total.
A cursory glance shows, minimum, that we round the requested memory
quantity up to the heap word size in
the Unsafe.allocateMemory code, and something to do with nmt_header_size
in os:malloc() (os.cpp) too.
Here's a set of solutions for the problem of "what you see isn't what you
get" for DBBs (3 is my favourite, but I
suspect 2 is the most likely to be accepted):
1) Use the code below to call DBB-specific Unsafe methods, allowing us to
track the quantity of native
memory reserved for DBBs at the point of allocation.
Pros:
- Doesn't require changing the Bits class.
- Allows us to easily devise a list of DBB native memory allocation
locations.
- Fits with existing OpenJ9 code, which tracks DBB memory usage *after*
native code has added to the total
memory requested, resulting in more accurate totals than Bits.
Cons:
- Requires some work on the Hotspot side to make it happen if Hotspot
users want the true benefit.
OR
- Requires a commit that only benefits Java if you're running on the
OpenJ9 VM.
2) Modify the Bits code to interrogate the VM via an extra method in
Unsafe, in order to determine the
true quantity of native memory that is being allocated.
E.g. User requests 10 bits, VM says it needs +2, add 12 to cumulative
total, return "true".
User later says to free 10 bits, VM says it needs +2, so we subtract 12
from the total.
Note: For consistency, the VM and Bits should use the same code when
figuring out how much space
will be added to the request by the VM.
Pros:
- Much smaller change than (1)
- Makes Bits much more accurate.
- Retains the Bits interface, and doesn't require a change to Unsafe.
Cons:
- Requires us to add a native method to Bits, or somewhere visible to
Bits.
3) Modify the Bits code to use an internal array for memory reservations,
returns an index. The user
can use this index to:
- Return the amount of memory they requested.
- Return the amount of memory the VM will actually reserve (Bits will
retrieve this from the VM via a
native method).
- Set the address the VM gave them for this reservation.
- Free the memory reserved.
Note: The existing internal totals, along with Shared Secrets, remain.
Pros:
- *Much* more accurate memory tracking for DBBs.
- Easier debugging for DBB overruns, as we know where all the DBBs are.
- Prevents the user trying to free too much or too little memory for an
allocated DBB.
Cons:
- Many changes to Bits.
- Native code changes.
- Probably best to restructure the memory allocation code to share the
same logic
(abstracting out the size+x gubbins so Bits' new native code logic remains
up to date).
Any thoughts?
- Adam
>> Hi Adam,
>>
>> Did you know that native memory is already tracked on the Java side for
>> direct ByteBuffers? See class java.nio.Bits. Could you make use of it?
>>
> Right, these are the fields that are exposed at runtime via
> BufferPoolMXBean. A SA based tool could read from a core file. I can't
> tell if this is enough for Adam, it may be that the his tool reveals
> more details on the buffers in the pools.
>
> -Alan
P.S. Code:
diff --git
a/src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
b/src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
--- a/src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
+++ b/src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
@@ -85,7 +85,7 @@
// Paranoia
return;
}
- UNSAFE.freeMemory(address);
+ UNSAFE.freeDBBMemory(address);
address = 0;
Bits.unreserveMemory(size, capacity);
}
@@ -118,7 +118,7 @@
long base = 0;
try {
- base = UNSAFE.allocateMemory(size);
+ base = UNSAFE.allocateDBBMemory(size);
} catch (OutOfMemoryError x) {
Bits.unreserveMemory(size, cap);
throw x;
diff --git a/src/java.base/share/classes/jdk/internal/misc/Unsafe.java
b/src/java.base/share/classes/jdk/internal/misc/Unsafe.java
--- a/src/java.base/share/classes/jdk/internal/misc/Unsafe.java
+++ b/src/java.base/share/classes/jdk/internal/misc/Unsafe.java
@@ -632,6 +632,26 @@
}
/**
+ * Allocates a new block of native memory for DirectByteBuffers, of
the
+ * given size in bytes. The contents of the memory are
uninitialized;
+ * they will generally be garbage. The resulting native pointer will
+ * never be zero, and will be aligned for all value types. Dispose
of
+ * this memory by calling {@link #freeDBBMemory} or resize it with
+ * {@link #reallocateDBBMemory}.
+ *
+ * @throws RuntimeException if the size is negative or too large
+ * for the native size_t type
+ *
+ * @throws OutOfMemoryError if the allocation is refused by the
system
+ *
+ * @see #getByte(long)
+ * @see #putByte(long, byte)
+ */
+ public long allocateDBBMemory(long bytes) {
+ return allocateMemory(bytes);
+ }
+
+ /**
* Resizes a new block of native memory, to the given size in bytes.
The
* contents of the new block past the size of the old block are
* uninitialized; they will generally be garbage. The resulting
native
@@ -687,6 +707,27 @@
}
/**
+ * Resizes a new block of native memory for DirectByteBuffers, to the
+ * given size in bytes. The contents of the new block past the size
of
+ * the old block are uninitialized; they will generally be garbage.
The
+ * resulting native pointer will be zero if and only if the requested
size
+ * is zero. The resulting native pointer will be aligned for all
value
+ * types. Dispose of this memory by calling {@link #freeDBBMemory},
or
+ * resize it with {@link #reallocateDBBMemory}. The address passed
to
+ * this method may be null, in which case an allocation will be
performed.
+ *
+ * @throws RuntimeException if the size is negative or too large
+ * for the native size_t type
+ *
+ * @throws OutOfMemoryError if the allocation is refused by the
system
+ *
+ * @see #allocateDBBMemory
+ */
+ public long reallocateDBBMemory(long address, long bytes) {
+ return reallocateMemory(address, bytes);
+ }
+
+ /**
* Sets all bytes in a given block of memory to a fixed value
* (usually zero).
*
@@ -918,6 +959,17 @@
checkPointer(null, address);
}
+ /**
+ * Disposes of a block of native memory, as obtained from {@link
+ * #allocateDBBMemory} or {@link #reallocateDBBMemory}. The address
passed
+ * to this method may be null, in which case no action is taken.
+ *
+ * @see #allocateDBBMemory
+ */
+ public void freeDBBMemory(long address) {
+ freeMemory(address);
+ }
+
/// random queries
/**
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
From zgu at redhat.com Fri Apr 13 14:29:45 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Fri, 13 Apr 2018 10:29:45 -0400
Subject: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory
Usage for Direct Byte Buffers
In-Reply-To: <OF081603B6.A5E4A0E9-ON0025826E.00432B47-8025826E.004E432A@notes.na.collabserv.com>
References: <OF081603B6.A5E4A0E9-ON0025826E.00432B47-8025826E.004E432A@notes.na.collabserv.com>
Message-ID: <941b2192-1fe1-fbee-17df-420f0bbb42de@redhat.com>
Hi Adam,
On 04/13/2018 10:14 AM, Adam Farley8 wrote:
> Hi Alan, Peter,
>
> I see that native memory is tracked in java.nio.Bits, but that only
> includes what the user thinks they are allocating.
>
> When the VM adds extra memory to the allocation amount this extra bit is
> not represented in the Bits total.
> A cursory glance shows, minimum, that we round the requested memory
> quantity up to the heap word size in
> the Unsafe.allocateMemory code, and something to do with nmt_header_size
> in os:malloc() (os.cpp) too.
This header overhead only incurs when detail native memory tracking is on.
>
> Here's a set of solutions for the problem of "what you see isn't what you
> get" for DBBs (3 is my favourite, but I
> suspect 2 is the most likely to be accepted):
I don't understand why you care about this header? The overheads are not
counted to allocators or memory categories (mtOther in this case), but
reported by NMT as tracking overhead.
Thanks,
-Zhengyu
>
> 1) Use the code below to call DBB-specific Unsafe methods, allowing us to
> track the quantity of native
> memory reserved for DBBs at the point of allocation.
>
> Pros:
> - Doesn't require changing the Bits class.
> - Allows us to easily devise a list of DBB native memory allocation
> locations.
> - Fits with existing OpenJ9 code, which tracks DBB memory usage *after*
> native code has added to the total
> memory requested, resulting in more accurate totals than Bits.
>
> Cons:
> - Requires some work on the Hotspot side to make it happen if Hotspot
> users want the true benefit.
> OR
> - Requires a commit that only benefits Java if you're running on the
> OpenJ9 VM.
>
> 2) Modify the Bits code to interrogate the VM via an extra method in
> Unsafe, in order to determine the
> true quantity of native memory that is being allocated.
>
> E.g. User requests 10 bits, VM says it needs +2, add 12 to cumulative
> total, return "true".
> User later says to free 10 bits, VM says it needs +2, so we subtract 12
> from the total.
>
> Note: For consistency, the VM and Bits should use the same code when
> figuring out how much space
> will be added to the request by the VM.
>
> Pros:
> - Much smaller change than (1)
> - Makes Bits much more accurate.
> - Retains the Bits interface, and doesn't require a change to Unsafe.
>
> Cons:
> - Requires us to add a native method to Bits, or somewhere visible to
> Bits.
>
> 3) Modify the Bits code to use an internal array for memory reservations,
> returns an index. The user
> can use this index to:
> - Return the amount of memory they requested.
> - Return the amount of memory the VM will actually reserve (Bits will
> retrieve this from the VM via a
> native method).
> - Set the address the VM gave them for this reservation.
> - Free the memory reserved.
>
> Note: The existing internal totals, along with Shared Secrets, remain.
>
> Pros:
> - *Much* more accurate memory tracking for DBBs.
> - Easier debugging for DBB overruns, as we know where all the DBBs are.
> - Prevents the user trying to free too much or too little memory for an
> allocated DBB.
>
> Cons:
> - Many changes to Bits.
> - Native code changes.
> - Probably best to restructure the memory allocation code to share the
> same logic
> (abstracting out the size+x gubbins so Bits' new native code logic remains
> up to date).
>
>
> Any thoughts?
>
> - Adam
>
>
>
>
>>> Hi Adam,
>>>
>>> Did you know that native memory is already tracked on the Java side for
>>> direct ByteBuffers? See class java.nio.Bits. Could you make use of it?
>>>
>> Right, these are the fields that are exposed at runtime via
>> BufferPoolMXBean. A SA based tool could read from a core file. I can't
>> tell if this is enough for Adam, it may be that the his tool reveals
>> more details on the buffers in the pools.
>>
>> -Alan
>
>
> P.S. Code:
>
> diff --git
> a/src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
> b/src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
> --- a/src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
> +++ b/src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
> @@ -85,7 +85,7 @@
> // Paranoia
> return;
> }
> - UNSAFE.freeMemory(address);
> + UNSAFE.freeDBBMemory(address);
> address = 0;
> Bits.unreserveMemory(size, capacity);
> }
> @@ -118,7 +118,7 @@
>
> long base = 0;
> try {
> - base = UNSAFE.allocateMemory(size);
> + base = UNSAFE.allocateDBBMemory(size);
> } catch (OutOfMemoryError x) {
> Bits.unreserveMemory(size, cap);
> throw x;
> diff --git a/src/java.base/share/classes/jdk/internal/misc/Unsafe.java
> b/src/java.base/share/classes/jdk/internal/misc/Unsafe.java
> --- a/src/java.base/share/classes/jdk/internal/misc/Unsafe.java
> +++ b/src/java.base/share/classes/jdk/internal/misc/Unsafe.java
> @@ -632,6 +632,26 @@
> }
>
> /**
> + * Allocates a new block of native memory for DirectByteBuffers, of
> the
> + * given size in bytes. The contents of the memory are
> uninitialized;
> + * they will generally be garbage. The resulting native pointer will
> + * never be zero, and will be aligned for all value types. Dispose
> of
> + * this memory by calling {@link #freeDBBMemory} or resize it with
> + * {@link #reallocateDBBMemory}.
> + *
> + * @throws RuntimeException if the size is negative or too large
> + * for the native size_t type
> + *
> + * @throws OutOfMemoryError if the allocation is refused by the
> system
> + *
> + * @see #getByte(long)
> + * @see #putByte(long, byte)
> + */
> + public long allocateDBBMemory(long bytes) {
> + return allocateMemory(bytes);
> + }
> +
> + /**
> * Resizes a new block of native memory, to the given size in bytes.
> The
> * contents of the new block past the size of the old block are
> * uninitialized; they will generally be garbage. The resulting
> native
> @@ -687,6 +707,27 @@
> }
>
> /**
> + * Resizes a new block of native memory for DirectByteBuffers, to the
> + * given size in bytes. The contents of the new block past the size
> of
> + * the old block are uninitialized; they will generally be garbage.
> The
> + * resulting native pointer will be zero if and only if the requested
> size
> + * is zero. The resulting native pointer will be aligned for all
> value
> + * types. Dispose of this memory by calling {@link #freeDBBMemory},
> or
> + * resize it with {@link #reallocateDBBMemory}. The address passed
> to
> + * this method may be null, in which case an allocation will be
> performed.
> + *
> + * @throws RuntimeException if the size is negative or too large
> + * for the native size_t type
> + *
> + * @throws OutOfMemoryError if the allocation is refused by the
> system
> + *
> + * @see #allocateDBBMemory
> + */
> + public long reallocateDBBMemory(long address, long bytes) {
> + return reallocateMemory(address, bytes);
> + }
> +
> + /**
> * Sets all bytes in a given block of memory to a fixed value
> * (usually zero).
> *
> @@ -918,6 +959,17 @@
> checkPointer(null, address);
> }
>
> + /**
> + * Disposes of a block of native memory, as obtained from {@link
> + * #allocateDBBMemory} or {@link #reallocateDBBMemory}. The address
> passed
> + * to this method may be null, in which case no action is taken.
> + *
> + * @see #allocateDBBMemory
> + */
> + public void freeDBBMemory(long address) {
> + freeMemory(address);
> + }
> +
> /// random queries
>
> /**
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
From zgu at redhat.com Fri Apr 13 14:32:01 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Fri, 13 Apr 2018 10:32:01 -0400
Subject: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory
Usage for Direct Byte Buffers
In-Reply-To: <941b2192-1fe1-fbee-17df-420f0bbb42de@redhat.com>
References: <OF081603B6.A5E4A0E9-ON0025826E.00432B47-8025826E.004E432A@notes.na.collabserv.com>
<941b2192-1fe1-fbee-17df-420f0bbb42de@redhat.com>
Message-ID: <52403ce7-cc6a-ce10-06b1-5e682700e3a1@redhat.com>
On 04/13/2018 10:29 AM, Zhengyu Gu wrote:
> Hi Adam,
>
> On 04/13/2018 10:14 AM, Adam Farley8 wrote:
>> Hi Alan, Peter,
>>
>> I see that native memory is tracked in java.nio.Bits, but that only
>> includes what the user thinks they are allocating.
>>
>> When the VM adds extra memory to the allocation amount this extra bit is
>> not represented in the Bits total.
>> A cursory glance shows, minimum, that we round the requested memory
>> quantity up to the heap word size in
>> the Unsafe.allocateMemory code, and something to do with nmt_header_size
>> in os:malloc() (os.cpp) too.
>
> This header overhead only incurs when detail native memory tracking is on.
Oops, should say "native memory tracking is on"
-Zhengyu
>
>>
>> Here's a set of solutions for the problem of "what you see isn't what you
>> get" for DBBs (3 is my favourite, but I
>> suspect 2 is the most likely to be accepted):
>
> I don't understand why you care about this header? The overheads are not
> counted to allocators or memory categories (mtOther in this case), but
> reported by NMT as tracking overhead.
>
> Thanks,
>
> -Zhengyu
>
>>
>> 1) Use the code below to call DBB-specific Unsafe methods, allowing us to
>> track the quantity of native
>> memory reserved for DBBs at the point of allocation.
>>
>> Pros:
>> - Doesn't require changing the Bits class.
>> - Allows us to easily devise a list of DBB native memory allocation
>> locations.
>> - Fits with existing OpenJ9 code, which tracks DBB memory usage *after*
>> native code has added to the total
>> memory requested, resulting in more accurate totals than Bits.
>>
>> Cons:
>> - Requires some work on the Hotspot side to make it happen if Hotspot
>> users want the true benefit.
>> OR
>> - Requires a commit that only benefits Java if you're running on the
>> OpenJ9 VM.
>>
>> 2) Modify the Bits code to interrogate the VM via an extra method in
>> Unsafe, in order to determine the
>> true quantity of native memory that is being allocated.
>>
>> E.g. User requests 10 bits, VM says it needs +2, add 12 to cumulative
>> total, return "true".
>> User later says to free 10 bits, VM says it needs +2, so we subtract 12
>> from the total.
>>
>> Note: For consistency, the VM and Bits should use the same code when
>> figuring out how much space
>> will be added to the request by the VM.
>>
>> Pros:
>> - Much smaller change than (1)
>> - Makes Bits much more accurate.
>> - Retains the Bits interface, and doesn't require a change to Unsafe.
>>
>> Cons:
>> - Requires us to add a native method to Bits, or somewhere visible to
>> Bits.
>>
>> 3) Modify the Bits code to use an internal array for memory reservations,
>> returns an index. The user
>> can use this index to:
>> - Return the amount of memory they requested.
>> - Return the amount of memory the VM will actually reserve (Bits will
>> retrieve this from the VM via a
>> native method).
>> - Set the address the VM gave them for this reservation.
>> - Free the memory reserved.
>>
>> Note: The existing internal totals, along with Shared Secrets, remain.
>>
>> Pros:
>> - *Much* more accurate memory tracking for DBBs.
>> - Easier debugging for DBB overruns, as we know where all the DBBs are.
>> - Prevents the user trying to free too much or too little memory for an
>> allocated DBB.
>>
>> Cons:
>> - Many changes to Bits.
>> - Native code changes.
>> - Probably best to restructure the memory allocation code to share the
>> same logic
>> (abstracting out the size+x gubbins so Bits' new native code logic
>> remains
>> up to date).
>>
>>
>> Any thoughts?
>>
>> - Adam
>>
>>
>>
>>
>>>> Hi Adam,
>>>>
>>>> Did you know that native memory is already tracked on the Java side for
>>>> direct ByteBuffers? See class java.nio.Bits. Could you make use of it?
>>>>
>>> Right, these are the fields that are exposed at runtime via
>>> BufferPoolMXBean. A SA based tool could read from a core file. I can't
>>> tell if this is enough for Adam, it may be that the his tool reveals
>>> more details on the buffers in the pools.
>>>
>>> -Alan
>>
>>
>> P.S. Code:
>>
>> diff --git
>> a/src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
>> b/src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
>> --- a/src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
>> +++ b/src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
>> @@ -85,7 +85,7 @@
>> ????????????????? // Paranoia
>> ????????????????? return;
>> ????????????? }
>> -??????????? UNSAFE.freeMemory(address);
>> +??????????? UNSAFE.freeDBBMemory(address);
>> ????????????? address = 0;
>> ????????????? Bits.unreserveMemory(size, capacity);
>> ????????? }
>> @@ -118,7 +118,7 @@
>> ????????? long base = 0;
>> ????????? try {
>> -??????????? base = UNSAFE.allocateMemory(size);
>> +??????????? base = UNSAFE.allocateDBBMemory(size);
>> ????????? } catch (OutOfMemoryError x) {
>> ????????????? Bits.unreserveMemory(size, cap);
>> ????????????? throw x;
>> diff --git a/src/java.base/share/classes/jdk/internal/misc/Unsafe.java
>> b/src/java.base/share/classes/jdk/internal/misc/Unsafe.java
>> --- a/src/java.base/share/classes/jdk/internal/misc/Unsafe.java
>> +++ b/src/java.base/share/classes/jdk/internal/misc/Unsafe.java
>> @@ -632,6 +632,26 @@
>> ????? }
>> ????? /**
>> +???? * Allocates a new block of native memory for DirectByteBuffers, of
>> the
>> +???? * given size in bytes.? The contents of the memory are
>> uninitialized;
>> +???? * they will generally be garbage.? The resulting native pointer
>> will
>> +???? * never be zero, and will be aligned for all value types.? Dispose
>> of
>> +???? * this memory by calling {@link #freeDBBMemory} or resize it with
>> +???? * {@link #reallocateDBBMemory}.
>> +???? *
>> +???? * @throws RuntimeException if the size is negative or too large
>> +???? *????????????????????????? for the native size_t type
>> +???? *
>> +???? * @throws OutOfMemoryError if the allocation is refused by the
>> system
>> +???? *
>> +???? * @see #getByte(long)
>> +???? * @see #putByte(long, byte)
>> +???? */
>> +??? public long allocateDBBMemory(long bytes) {
>> +??????? return allocateMemory(bytes);
>> +??? }
>> +
>> +??? /**
>> ?????? * Resizes a new block of native memory, to the given size in
>> bytes.
>> The
>> ?????? * contents of the new block past the size of the old block are
>> ?????? * uninitialized; they will generally be garbage.? The resulting
>> native
>> @@ -687,6 +707,27 @@
>> ????? }
>> ????? /**
>> +???? * Resizes a new block of native memory for DirectByteBuffers, to
>> the
>> +???? * given size in bytes.? The contents of the new block past the size
>> of
>> +???? * the old block are uninitialized; they will generally be garbage.
>> The
>> +???? * resulting native pointer will be zero if and only if the
>> requested
>> size
>> +???? * is zero.? The resulting native pointer will be aligned for all
>> value
>> +???? * types.? Dispose of this memory by calling {@link #freeDBBMemory},
>> or
>> +???? * resize it with {@link #reallocateDBBMemory}.? The address passed
>> to
>> +???? * this method may be null, in which case an allocation will be
>> performed.
>> +???? *
>> +???? * @throws RuntimeException if the size is negative or too large
>> +???? *????????????????????????? for the native size_t type
>> +???? *
>> +???? * @throws OutOfMemoryError if the allocation is refused by the
>> system
>> +???? *
>> +???? * @see #allocateDBBMemory
>> +???? */
>> +??? public long reallocateDBBMemory(long address, long bytes) {
>> +??????? return reallocateMemory(address, bytes);
>> +??? }
>> +
>> +??? /**
>> ?????? * Sets all bytes in a given block of memory to a fixed value
>> ?????? * (usually zero).
>> ?????? *
>> @@ -918,6 +959,17 @@
>> ????????? checkPointer(null, address);
>> ????? }
>> +??? /**
>> +???? * Disposes of a block of native memory, as obtained from {@link
>> +???? * #allocateDBBMemory} or {@link #reallocateDBBMemory}.? The address
>> passed
>> +???? * to this method may be null, in which case no action is taken.
>> +???? *
>> +???? * @see #allocateDBBMemory
>> +???? */
>> +??? public void freeDBBMemory(long address) {
>> +??????? freeMemory(address);
>> +??? }
>> +
>> ????? /// random queries
>> ????? /**
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
>> 3AU
>>
From coleen.phillimore at oracle.com Fri Apr 13 14:56:33 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 13 Apr 2018 10:56:33 -0400
Subject: RFR (M) 8200555: OopHandle should use Access API
Message-ID: <f176b0d9-6152-45d2-ace9-1effb6b5fa28@oracle.com>
Summary: Add RootAccess<> to OopHandle.resolve() in runtime and
interpreter code.? Add comments for compiler code for later.
For the current GCs this code does not generate additional code. Also,
the compiler Access API code is TBD.?? Since oopHandle.hpp erroneously
included orderAccess.hpp and atomic.hpp, some include file fixing is
also in this change.
Tested with mach5 tier1,tier2 on all Oracle platforms.? Also tested
compilation on linux-aarch64.? The other non-Oracle platforms weren't
changed because they'll never need this.
open webrev at http://cr.openjdk.java.net/~coleenp/8200555.01/webrev
bug link https://bugs.openjdk.java.net/browse/JDK-8200555
Thanks,
Coleen
From erik.osterlund at oracle.com Fri Apr 13 15:11:26 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Fri, 13 Apr 2018 17:11:26 +0200
Subject: RFR: 8201543: Modularize C1 GC barriers
Message-ID: <5AD0C89E.7050807@oracle.com>
Hi,
The GC barriers for C1 are not as modular as they could be. It currently
uses switch statements to check which GC barrier set is being used, and
calls one or another barrier based on that, in a way that it can only be
used for write barriers.
The solution I propose is to add the same facilities that have been
added in runtime and the interpreter already: a barrier set backend for
C1. I call it BarrierSetC1, and it helps us generate decorated accesses
that give the GC control over the details how to generate this access.
It recognizes the same decorators (accessDecorators.hpp) that the other
parts of the VM recognize. Each concrete barrier set has its own
backend. For now, these are CardTableBarrierSetC1 and G1BarrierSetC1,
but this should pave way for upcoming concurrently compacting GCs as well.
Two decorators were added for C1 specifically (found in c1_Decorators.hpp):
C1_NEEDS_PATCHING for accesses where the index is not yet load because
the class has yet to be loaded, and
C1_MASK_BOOLEAN for accesses that need to mask untrusted boolean values.
LIRGenerator calls a wrapper called access_store_at, access_load_at, etc
(there are variants for cpmxchg, xchg and atomic add as well).
The access call calls straight into the BarrierSetC1 hierarchy using
virtual calls. It is structured in a way very similar to
BarrierSetAssembler.
BarrierSetC1 can also be called during initialization to generate stubs
and runtime methods required by C1. For G1BarrierSetC1, this results in
calling the BarrierSetAssembler for the platform specific code. This
way, the BarrierSetC1 hierarchy has been carefully kept in shared code,
and the switch statements for generating G1 code have been removed. Some
code that used to be platform specific (like unsafe get/set and array
store) have been broken out to shared code, with the actual platform
specific details (some register allocation for store check and atomics)
broken out to platform specific methods. This way, calls to access are
kept in platform specific code.
As usual, big thanks go to Martin Doerr for helping out with S390 and
PPC, and Roman for taking care of AArch64.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8201543
Webrev:
http://cr.openjdk.java.net/~eosterlund/8201543/webrev.00/
Thanks,
/Erik
From lois.foltan at oracle.com Fri Apr 13 15:29:25 2018
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 13 Apr 2018 11:29:25 -0400
Subject: RFR (M) 8201505: Use WeakHandle for ProtectionDomainCacheTable
and ResolvedMethodTable
In-Reply-To: <43780f09-b3b2-ccfd-e39a-ce058ef2d64b@oracle.com>
References: <7091958f-01a0-beb0-7ab7-2372944f54b1@oracle.com>
<43780f09-b3b2-ccfd-e39a-ce058ef2d64b@oracle.com>
Message-ID: <52a8f23b-ab71-8501-0799-19f72ba23f40@oracle.com>
Looks good Coleen.? Thanks for fixing JDK-8193524 as well!
Lois
On 4/13/2018 8:16 AM, coleen.phillimore at oracle.com wrote:
>
> And here's the webrev:
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8201505.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8201505
>
> Thanks,
> Coleen
>
> On 4/13/18 8:12 AM, coleen.phillimore at oracle.com wrote:
>> 8193524: Redefining a method that removes use of 1 or more lambda
>> expressions causes the JVM to hang
>> Summary: Remove oop pointers from runtime data structures and fix
>> missing next assignment.
>>
>> Also, this contains a fix for
>> https://bugs.openjdk.java.net/browse/JDK-8193524 (forgotten next
>> pointer assignment) because I changed that function 3 lines up, and
>> tests contributed by Lois.
>>
>> Tested with mach5 tier1-5.
>>
>> Thanks,
>> Coleen
>>
>
From aph at redhat.com Fri Apr 13 17:01:29 2018
From: aph at redhat.com (Andrew Haley)
Date: Fri, 13 Apr 2018 18:01:29 +0100
Subject: RFR: 8185505: AArch64: Port AOT
Message-ID: <b439eaf0-e026-7ff8-e832-3717368027e4@redhat.com>
http://cr.openjdk.java.net/~aph/8185505-1
The corresponding Graal changes are at
https://github.com/oracle/graal/pull/334/files
I think I've done all the things that reviewers mentioned. There is a
clean set of test result for JVMCI and AOT. Thank you everyone.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From coleen.phillimore at oracle.com Fri Apr 13 17:25:03 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 13 Apr 2018 13:25:03 -0400
Subject: RFR (M) 8201505: Use WeakHandle for ProtectionDomainCacheTable
and ResolvedMethodTable
In-Reply-To: <52a8f23b-ab71-8501-0799-19f72ba23f40@oracle.com>
References: <7091958f-01a0-beb0-7ab7-2372944f54b1@oracle.com>
<43780f09-b3b2-ccfd-e39a-ce058ef2d64b@oracle.com>
<52a8f23b-ab71-8501-0799-19f72ba23f40@oracle.com>
Message-ID: <b84935ec-2b73-a259-60cf-46f1efa829c2@oracle.com>
Thank you Lois!
Coleen
On 4/13/18 11:29 AM, Lois Foltan wrote:
> Looks good Coleen.? Thanks for fixing JDK-8193524 as well!
> Lois
>
> On 4/13/2018 8:16 AM, coleen.phillimore at oracle.com wrote:
>>
>> And here's the webrev:
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8201505.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8201505
>>
>> Thanks,
>> Coleen
>>
>> On 4/13/18 8:12 AM, coleen.phillimore at oracle.com wrote:
>>> 8193524: Redefining a method that removes use of 1 or more lambda
>>> expressions causes the JVM to hang
>>> Summary: Remove oop pointers from runtime data structures and fix
>>> missing next assignment.
>>>
>>> Also, this contains a fix for
>>> https://bugs.openjdk.java.net/browse/JDK-8193524 (forgotten next
>>> pointer assignment) because I changed that function 3 lines up, and
>>> tests contributed by Lois.
>>>
>>> Tested with mach5 tier1-5.
>>>
>>> Thanks,
>>> Coleen
>>>
>>
>
From Alan.Bateman at oracle.com Fri Apr 13 17:26:05 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 13 Apr 2018 10:26:05 -0700 (PDT)
Subject: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory
Usage for Direct Byte Buffers
In-Reply-To: <OF081603B6.A5E4A0E9-ON0025826E.00432B47-8025826E.004E432A@notes.na.collabserv.com>
References: <OF081603B6.A5E4A0E9-ON0025826E.00432B47-8025826E.004E432A@notes.na.collabserv.com>
Message-ID: <044af3a4-016c-9225-ee49-7cd7d23daefa@oracle.com>
On 13/04/2018 15:14, Adam Farley8 wrote:
> Hi Alan, Peter,
>
> I see that native memory is tracked in java.nio.Bits, but that only
> includes what the user thinks they are allocating.
>
> When the VM adds extra memory to the allocation amount this extra bit
> is not represented in the Bits total.
> A cursory glance shows, minimum, that we round the requested memory
> quantity up to the heap word size in
> the Unsafe.allocateMemory code, and something to do with
> nmt_header_size in os:malloc() (os.cpp) too.
Is the align_up(sz, HeapWordSize) really causing an issue?
We could change Bits to align with HotSpot. The BufferPoolMXBean API
allows the capacity and memory usage to differ (when we originally added
this, direct buffers were page aligned) so doing this would mean it more
accurately reflects the memory allocated to direct buffers.
-Alan
From per.liden at oracle.com Fri Apr 13 19:10:22 2018
From: per.liden at oracle.com (Per Liden)
Date: Fri, 13 Apr 2018 21:10:22 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <f1c9b155-7f06-262c-98f6-f0d3d3b025b6@redhat.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<f1c9b155-7f06-262c-98f6-f0d3d3b025b6@redhat.com>
Message-ID: <d583942c-7151-d783-14cd-658b6295203a@oracle.com>
On 04/13/2018 03:33 PM, Andrew Haley wrote:
> On 04/10/2018 01:51 PM, Per Liden wrote:
>> A couple of commits were pushed, which causes conflicts with this
>> change, so here's a rebased version:
>>
>> http://cr.openjdk.java.net/~pliden/8201318/webrev.1
>
> Did the Graal changes go upstream?
I assume that will happen in the next Graal re-sync.
/Per
From rkennke at redhat.com Fri Apr 13 20:08:35 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Fri, 13 Apr 2018 22:08:35 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
Message-ID: <d86c8c1a-de33-ce4c-37d0-429ca20f78e8@redhat.com>
Hi Per,
I'm late to the party, somehow this totally went below my radar. The
week was a bit hectic here.
I verified that it hasn't broken aarch64. And even though it's already
pushed, I like the change. I'd probably have done it almost 100% the
same ;-)
Thanks for doing it!
Cheers,
Roman
> Hi Martin & Roman,
>
> I just want to highlight that this change touches platform code for
> s390/ppc and aarch64, so please verify that it doesn't break your builds.
>
> cheers,
> Per
>
> On 04/10/2018 01:42 PM, Per Liden wrote:
>> As part of the effort to make GCs more pluggable, the G1-specific data
>> in JavaThread should be moved out into a more appropriate abstraction.
>>
>> This is the second step (building on JDK-8201316), which introduces
>> GCThreadLocalData, an opaque data area in Thread. Each GC is free to
>> decide the internal structure and contents of this area.
>>
>> With this in place, we can remove G1's thread-local SATB queue and
>> dirty card queue from JavaThread and instead let G1 use the data area
>> provided by GCThreadLocalData to store these.
>>
>> Other GCs that wants to store pre-thread information (e.g. ZGC and
>> Shenandoah) are encouraged to look at what G1 is doing here and use
>> that as a template/example.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201318
>> Webrev: http://cr.openjdk.java.net/~pliden/8201318/webrev.0/
>>
>> Testing: hs-tier{1-3}
>>
>> /Per
>>
From per.liden at oracle.com Fri Apr 13 20:22:54 2018
From: per.liden at oracle.com (Per Liden)
Date: Fri, 13 Apr 2018 22:22:54 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <d86c8c1a-de33-ce4c-37d0-429ca20f78e8@redhat.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<d86c8c1a-de33-ce4c-37d0-429ca20f78e8@redhat.com>
Message-ID: <c2f04132-ca4a-aa96-aa00-10ba480da1d8@oracle.com>
Hi Roman,
On 04/13/2018 10:08 PM, Roman Kennke wrote:
> Hi Per,
>
> I'm late to the party, somehow this totally went below my radar. The
> week was a bit hectic here.
>
> I verified that it hasn't broken aarch64. And even though it's already
> pushed, I like the change. I'd probably have done it almost 100% the
> same ;-)
Thanks, I'm happy you like it ;)
/Per
>
> Thanks for doing it!
> Cheers,
> Roman
>
>
>> Hi Martin & Roman,
>>
>> I just want to highlight that this change touches platform code for
>> s390/ppc and aarch64, so please verify that it doesn't break your builds.
>>
>> cheers,
>> Per
>>
>> On 04/10/2018 01:42 PM, Per Liden wrote:
>>> As part of the effort to make GCs more pluggable, the G1-specific data
>>> in JavaThread should be moved out into a more appropriate abstraction.
>>>
>>> This is the second step (building on JDK-8201316), which introduces
>>> GCThreadLocalData, an opaque data area in Thread. Each GC is free to
>>> decide the internal structure and contents of this area.
>>>
>>> With this in place, we can remove G1's thread-local SATB queue and
>>> dirty card queue from JavaThread and instead let G1 use the data area
>>> provided by GCThreadLocalData to store these.
>>>
>>> Other GCs that wants to store pre-thread information (e.g. ZGC and
>>> Shenandoah) are encouraged to look at what G1 is doing here and use
>>> that as a template/example.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201318
>>> Webrev: http://cr.openjdk.java.net/~pliden/8201318/webrev.0/
>>>
>>> Testing: hs-tier{1-3}
>>>
>>> /Per
>>>
>
>
From aph at redhat.com Sat Apr 14 10:42:18 2018
From: aph at redhat.com (Andrew Haley)
Date: Sat, 14 Apr 2018 11:42:18 +0100
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <d583942c-7151-d783-14cd-658b6295203a@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<f1c9b155-7f06-262c-98f6-f0d3d3b025b6@redhat.com>
<d583942c-7151-d783-14cd-658b6295203a@oracle.com>
Message-ID: <cf5e6638-443e-1243-96f8-599d8950c1af@redhat.com>
On 04/13/2018 08:10 PM, Per Liden wrote:
> On 04/13/2018 03:33 PM, Andrew Haley wrote:
>> On 04/10/2018 01:51 PM, Per Liden wrote:
>>> A couple of commits were pushed, which causes conflicts with this
>>> change, so here's a rebased version:
>>>
>>> http://cr.openjdk.java.net/~pliden/8201318/webrev.1
>>
>> Did the Graal changes go upstream?
>
> I assume that will happen in the next Graal re-sync.
Does anybody do two-way syncs to Graal? I thought we imported Graal
wholesale, but I may be wrong about that.
In the meantime, be aware that Graal development on JDK11 is broken
until this change is pushed to Graal. As far as I know, Graal changes
are supposed to be reviewed by Graal developers.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From doug.simon at oracle.com Sat Apr 14 12:29:24 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Sat, 14 Apr 2018 14:29:24 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <cf5e6638-443e-1243-96f8-599d8950c1af@redhat.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<f1c9b155-7f06-262c-98f6-f0d3d3b025b6@redhat.com>
<d583942c-7151-d783-14cd-658b6295203a@oracle.com>
<cf5e6638-443e-1243-96f8-599d8950c1af@redhat.com>
Message-ID: <F3231CFC-7B66-4BB1-B911-95AD3B2C0A83@oracle.com>
> On 14 Apr 2018, at 12:42, Andrew Haley <aph at redhat.com> wrote:
>
> On 04/13/2018 08:10 PM, Per Liden wrote:
>> On 04/13/2018 03:33 PM, Andrew Haley wrote:
>>> On 04/10/2018 01:51 PM, Per Liden wrote:
>>>> A couple of commits were pushed, which causes conflicts with this
>>>> change, so here's a rebased version:
>>>>
>>>> http://cr.openjdk.java.net/~pliden/8201318/webrev.1
>>>
>>> Did the Graal changes go upstream?
>>
>> I assume that will happen in the next Graal re-sync.
>
> Does anybody do two-way syncs to Graal? I thought we imported Graal
> wholesale, but I may be wrong about that.
No, you're right. It only goes one way. That said, small changes like this could be be pushed to openjdk to keep testing working but a PR must be made at the same time at https://github.com/oracle/graal/pulls so that the next Graal update will not override the changes pushed directly to the openjdk repo. However, the HotSpot team responsible for the Graal updates probably prefers the changes only to be done in the updates.
> In the meantime, be aware that Graal development on JDK11 is broken
> until this change is pushed to Graal. As far as I know, Graal changes
> are supposed to be reviewed by Graal developers.
Changes like this one can be reviewed by anyone in the HotSpot compiler team or Graal team.
-Doug
From dmitry.samersoff at bell-sw.com Sat Apr 14 17:24:48 2018
From: dmitry.samersoff at bell-sw.com (Dmitry Samersoff)
Date: Sat, 14 Apr 2018 20:24:48 +0300
Subject: JEP 328: Flight Recorder on AARCH64 platfrom
Message-ID: <449ed692-6d69-6a82-4b7e-87819645f06e@bell-sw.com>
Hi Everybody,
As soon as preview patch form JFR is available now, I created a CR to
test it on AARCH64 platform.
See. JDK-8201564
-Dmitry
From glaubitz at physik.fu-berlin.de Sat Apr 14 21:50:49 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Sat, 14 Apr 2018 23:50:49 +0200
Subject: Backtrace for Java thread at early JVM startup - was: Hotspot
segfaulting on Linux SPARC
Message-ID: <90751820-6383-e2fc-6d17-b23607fe5975@physik.fu-berlin.de>
Hi!
I am still trying to fix Hotspot on Linux/SPARC and it seems that the
problem is related to a HashMap which is created during VM startup.
From studying the code, I found that the following exception:
glaubitz at deb4g:/srv/glaubitz/hs$ ./build/linux-sparcv9-normal-server-fastdebug/jdk/bin/java --version
Error occurred during initialization of boot layer
java.lang.module.FindException: Error reading module: /srv/glaubitz/hs/build/linux-sparcv9-normal-server-fastdebug/jdk/modules/java.sql
Caused by: java.lang.module.InvalidModuleDescriptorException: Illegal load factor: -1.2197928E-12
glaubitz at deb4g:/srv/glaubitz/hs$
is thrown in this constructor:
public HashMap(int initialCapacity, float loadFactor)
in src/java.base/share/classes/java/util/HashMap.java.
Now, if I hard-wire the load factor to the default value of 0.75f:
diff -r 46dc568d6804 src/java.base/share/classes/java/util/HashMap.java
--- a/src/java.base/share/classes/java/util/HashMap.java Fri Apr 13 14:06:39 2018 +0200
+++ b/src/java.base/share/classes/java/util/HashMap.java Sun Apr 15 00:48:11 2018 +0300
@@ -448,6 +448,7 @@
if (initialCapacity < 0)
throw new IllegalArgumentException("Illegal initial capacity: " +
initialCapacity);
+ loadFactor = 0.75f;
if (initialCapacity > MAXIMUM_CAPACITY)
initialCapacity = MAXIMUM_CAPACITY;
if (loadFactor <= 0 || Float.isNaN(loadFactor))
the JVM seems to startup normally:
glaubitz at deb4g:/srv/glaubitz/hs$ ./build/linux-sparcv9-normal-server-fastdebug/jdk/bin/java --version
openjdk 11-internal 2018-09-25
OpenJDK Runtime Environment (fastdebug build 11-internal+0-adhoc.glaubitz.hs)
OpenJDK 64-Bit Server VM (fastdebug build 11-internal+0-adhoc.glaubitz.hs, mixed mode)
glaubitz at deb4g:/srv/glaubitz/hs$
Now, in order to figure out what's actually wrong, it would be handy to get
a backtrace of the Java thread to understand where the invalid value for
loadFactor, -1.2197928E-12, comes from.
Any suggestions?
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From Alan.Bateman at oracle.com Sun Apr 15 07:28:54 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 15 Apr 2018 08:28:54 +0100
Subject: Backtrace for Java thread at early JVM startup - was: Hotspot
segfaulting on Linux SPARC
In-Reply-To: <90751820-6383-e2fc-6d17-b23607fe5975@physik.fu-berlin.de>
References: <90751820-6383-e2fc-6d17-b23607fe5975@physik.fu-berlin.de>
Message-ID: <3d598918-a7b5-a230-1354-ed38aebcf730@oracle.com>
On 14/04/2018 22:50, John Paul Adrian Glaubitz wrote:
> :
>
> Now, in order to figure out what's actually wrong, it would be handy
> to get
> a backtrace of the Java thread to understand where the invalid value for
> loadFactor, -1.2197928E-12, comes from.
Can you try `java -Xlog:init=debug --version` ?
-Alan
From aph at redhat.com Sun Apr 15 10:03:11 2018
From: aph at redhat.com (Andrew Haley)
Date: Sun, 15 Apr 2018 11:03:11 +0100
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <F3231CFC-7B66-4BB1-B911-95AD3B2C0A83@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<f1c9b155-7f06-262c-98f6-f0d3d3b025b6@redhat.com>
<d583942c-7151-d783-14cd-658b6295203a@oracle.com>
<cf5e6638-443e-1243-96f8-599d8950c1af@redhat.com>
<F3231CFC-7B66-4BB1-B911-95AD3B2C0A83@oracle.com>
Message-ID: <4616d0a8-61b0-a369-61cc-e4c82c39539e@redhat.com>
On 04/14/2018 01:29 PM, Doug Simon wrote:
>> In the meantime, be aware that Graal development on JDK11 is broken
>> until this change is pushed to Graal. As far as I know, Graal changes
>> are supposed to be reviewed by Graal developers.
> Changes like this one can be reviewed by anyone in the HotSpot
> compiler team or Graal team.
That's good to know. The change is obviously correct, but it needs to
be handled correctly.
For my information, though, I presume "changes like this" means simple
changes to JVMCI. That right?
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From dms at samersoff.net Sun Apr 15 12:34:15 2018
From: dms at samersoff.net (Dmitry Samersoff)
Date: Sun, 15 Apr 2018 15:34:15 +0300
Subject: JEP 328 : Flight Recorder open source preview
In-Reply-To: <687dbe1f-80dc-46ff-9f9f-da03687322e6@default>
References: <687dbe1f-80dc-46ff-9f9f-da03687322e6@default>
Message-ID: <98495f12-6074-4ff6-5080-8cf601ce7367@samersoff.net>
Hi Markus,
I'm trying to compile the patch but get following errors:
Compiling 1616 files for jdk.localedata
.../hs/src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java:60:
error: package jdk.internal.misc is not visible
import jdk.internal.misc.Unsafe;
^
(package jdk.internal.misc is declared in module java.base, which does
not export it to module jdk.jfr)
.../hs/src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java:61:
error: package jdk.internal.module does not exist
import jdk.internal.module.Modules;
^
.../hs/src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java:31: error:
package jdk.internal is not visible
import jdk.internal.HotSpotIntrinsicCandidate;
etc.
Any ideas of what could be wrong?
-Dmitry
On 04/07/2018 01:28 PM, Markus Gronlund wrote:
> Greetings,
>
>
>
> This is a preview of a large part of the source code for JEP 328 : Flight Recorder[1].
>
>
>
> Webrev: http://cr.openjdk.java.net/~mgronlun/JEP328_FlightRecorder/Preview/webrev/index.html
>
>
>
> It has been tested on the following platforms:
>
> * Linux-x64
>
> * Windows-x64
>
> * MacOSX-x64
>
>
>
> We are planning to send out the code for full review in a couple of weeks.
>
>
>
> At this point, we are preparing changes to move to a single backend, as suggested in the JEP.
>
> These will encompass the following:
>
>
>
> 1. Rename macro INCLUDE_TRACE to INCLUDE_JFR.
>
> 2. Remove flag -XX:[+|-]EnableTracing.
>
> 3. Cleanup unused elements and attributes by restructuring the trace xml files.
>
> 4. Move code under hotspot/share/trace to hotspot/share/jfr/metadata.
>
>
>
> Thank you
>
> Markus and Erik
>
>
>
> [1] http://openjdk.java.net/jeps/328
>
>
>
> PS the patch was generated from the hs repository [2] using change [3] as parent.
>
> [2] http://hg.openjdk.java.net/jdk/hs
>
> [3] changeset: 49618:947560700a09
>
> user: stefank
>
> date: Fri Apr 06 13:55:25 2018 +0200
>
> summary: 8201136: Move GC flags from globals.hpp to GC specific files
>
--
Dmitry Samersoff
http://devnull.samersoff.net
* There will come soft rains ...
From me at md-5.net Sun Apr 15 12:39:14 2018
From: me at md-5.net (Michael Dardis)
Date: Sun, 15 Apr 2018 12:39:14 +0000
Subject: Backtrace for Java thread at early JVM startup - was: Hotspot
segfaulting on Linux SPARC
In-Reply-To: <90751820-6383-e2fc-6d17-b23607fe5975@physik.fu-berlin.de>
References: <90751820-6383-e2fc-6d17-b23607fe5975@physik.fu-berlin.de>
Message-ID: <01000162c9510aba-d2f17b52-b05c-4629-8e94-b0b0fff3627d-000000@email.amazonses.com>
Adrian,
The invalid value is 0xabababab in hexadecimal.
In debug builds this option is set:
https://github.com/md-5/OpenJDK/blob/1415df45a29a0a0c56adf1271786e41d5f93ca57/src/hotspot/share/runtime/globals.hpp#L905
Which causes freed memory to be filled with 0xabababab upon clearing.
Probably a memory bounds issue with access above or below the correct
memory chunk.
Unfortunately I can't provide further help, but hopefully that answers your
question of where it's coming from.
Michael
On 15 April 2018 at 07:50, John Paul Adrian Glaubitz <
glaubitz at physik.fu-berlin.de> wrote:
> Hi!
>
> I am still trying to fix Hotspot on Linux/SPARC and it seems that the
> problem is related to a HashMap which is created during VM startup.
>
> From studying the code, I found that the following exception:
>
> glaubitz at deb4g:/srv/glaubitz/hs$ ./build/linux-sparcv9-normal-server-fastdebug/jdk/bin/java
> --version
> Error occurred during initialization of boot layer
> java.lang.module.FindException: Error reading module:
> /srv/glaubitz/hs/build/linux-sparcv9-normal-server-fastdebug
> /jdk/modules/java.sql
> Caused by: java.lang.module.InvalidModuleDescriptorException: Illegal
> load factor: -1.2197928E-12
> glaubitz at deb4g:/srv/glaubitz/hs$
>
> is thrown in this constructor:
>
> public HashMap(int initialCapacity, float loadFactor)
>
> in src/java.base/share/classes/java/util/HashMap.java.
>
> Now, if I hard-wire the load factor to the default value of 0.75f:
>
> diff -r 46dc568d6804 src/java.base/share/classes/java/util/HashMap.java
> --- a/src/java.base/share/classes/java/util/HashMap.java Fri Apr
> 13 14:06:39 2018 +0200
> +++ b/src/java.base/share/classes/java/util/HashMap.java Sun Apr
> 15 00:48:11 2018 +0300
> @@ -448,6 +448,7 @@
> if (initialCapacity < 0)
> throw new IllegalArgumentException("Illegal initial
> capacity: " +
> initialCapacity);
> + loadFactor = 0.75f;
> if (initialCapacity > MAXIMUM_CAPACITY)
> initialCapacity = MAXIMUM_CAPACITY;
> if (loadFactor <= 0 || Float.isNaN(loadFactor))
>
> the JVM seems to startup normally:
>
> glaubitz at deb4g:/srv/glaubitz/hs$ ./build/linux-sparcv9-normal-server-fastdebug/jdk/bin/java
> --version
> openjdk 11-internal 2018-09-25
> OpenJDK Runtime Environment (fastdebug build 11-internal+0-adhoc.glaubitz.h
> s)
> OpenJDK 64-Bit Server VM (fastdebug build 11-internal+0-adhoc.glaubitz.hs,
> mixed mode)
> glaubitz at deb4g:/srv/glaubitz/hs$
>
> Now, in order to figure out what's actually wrong, it would be handy to get
> a backtrace of the Java thread to understand where the invalid value for
> loadFactor, -1.2197928E-12, comes from.
>
> Any suggestions?
>
> Thanks,
> Adrian
>
> --
> .''`. John Paul Adrian Glaubitz
> : :' : Debian Developer - glaubitz at debian.org
> `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>
From erik.gahlin at oracle.com Sun Apr 15 12:59:11 2018
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Sun, 15 Apr 2018 14:59:11 +0200
Subject: JEP 328 : Flight Recorder open source preview
In-Reply-To: <98495f12-6074-4ff6-5080-8cf601ce7367@samersoff.net>
References: <687dbe1f-80dc-46ff-9f9f-da03687322e6@default>
<98495f12-6074-4ff6-5080-8cf601ce7367@samersoff.net>
Message-ID: <5AD34C9F.1010209@oracle.com>
I think changes to module.info.java in java.base got lost when we
re-based the repository.
These changes seem to be missing:
diff --git a/src/java.base/share/classes/module-info.java
b/src/java.base/share/classes/module-info.java
--- a/src/java.base/share/classes/module-info.java
+++ b/src/java.base/share/classes/module-info.java
@@ -134,6 +134,8 @@
exports com.sun.security.ntlm to
java.security.sasl;
+ exports jdk.internal to
+ jdk.jfr;
exports jdk.internal.jimage to
jdk.jlink;
exports jdk.internal.jimage.decompressor to
@@ -149,16 +151,28 @@
exports jdk.internal.org.objectweb.asm to
jdk.jartool,
jdk.jlink,
+ jdk.jfr,
jdk.scripting.nashorn,
jdk.internal.vm.ci;
exports jdk.internal.org.objectweb.asm.tree to
- jdk.jlink;
+ jdk.jlink,
+ jdk.jfr;
exports jdk.internal.org.objectweb.asm.util to
+ jdk.jfr,
jdk.scripting.nashorn;
exports jdk.internal.org.objectweb.asm.commons to
+ jdk.jfr,
jdk.scripting.nashorn;
exports jdk.internal.org.objectweb.asm.signature to
jdk.scripting.nashorn;
+ exports jdk.internal.org.xml.sax to
+ jdk.jfr;
+ exports jdk.internal.org.xml.sax.helpers to
+ jdk.jfr;
+ exports jdk.internal.util.xml to
+ jdk.jfr;
+ exports jdk.internal.util.xml.impl to
+ jdk.jfr;
exports jdk.internal.math to
java.desktop;
exports jdk.internal.misc to
@@ -175,6 +189,7 @@
jdk.compiler, // reflective dependency
jdk.incubator.httpclient,
jdk.jdeps,
+ jdk.jfr,
jdk.jlink,
jdk.jshell,
jdk.net,
@@ -186,6 +201,7 @@
java.instrument,
java.management.rmi,
jdk.jartool,
+ jdk.jfr,
jdk.jlink;
exports jdk.internal.perf to
java.desktop,
We will look into this more closely next week and update the webrev.
Thanks
Erik
On 2018-04-15 14:34, Dmitry Samersoff wrote:
> Hi Markus,
>
> I'm trying to compile the patch but get following errors:
>
> Compiling 1616 files for jdk.localedata
>
> .../hs/src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java:60:
> error: package jdk.internal.misc is not visible
> import jdk.internal.misc.Unsafe;
> ^
> (package jdk.internal.misc is declared in module java.base, which does
> not export it to module jdk.jfr)
>
> .../hs/src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java:61:
> error: package jdk.internal.module does not exist
> import jdk.internal.module.Modules;
> ^
> .../hs/src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java:31: error:
> package jdk.internal is not visible
> import jdk.internal.HotSpotIntrinsicCandidate;
>
> etc.
>
> Any ideas of what could be wrong?
>
> -Dmitry
>
> On 04/07/2018 01:28 PM, Markus Gronlund wrote:
>> Greetings,
>>
>>
>>
>> This is a preview of a large part of the source code for JEP 328 : Flight Recorder[1].
>>
>>
>>
>> Webrev: http://cr.openjdk.java.net/~mgronlun/JEP328_FlightRecorder/Preview/webrev/index.html
>>
>>
>>
>> It has been tested on the following platforms:
>>
>> * Linux-x64
>>
>> * Windows-x64
>>
>> * MacOSX-x64
>>
>>
>>
>> We are planning to send out the code for full review in a couple of weeks.
>>
>>
>>
>> At this point, we are preparing changes to move to a single backend, as suggested in the JEP.
>>
>> These will encompass the following:
>>
>>
>>
>> 1. Rename macro INCLUDE_TRACE to INCLUDE_JFR.
>>
>> 2. Remove flag -XX:[+|-]EnableTracing.
>>
>> 3. Cleanup unused elements and attributes by restructuring the trace xml files.
>>
>> 4. Move code under hotspot/share/trace to hotspot/share/jfr/metadata.
>>
>>
>>
>> Thank you
>>
>> Markus and Erik
>>
>>
>>
>> [1] http://openjdk.java.net/jeps/328
>>
>>
>>
>> PS the patch was generated from the hs repository [2] using change [3] as parent.
>>
>> [2] http://hg.openjdk.java.net/jdk/hs
>>
>> [3] changeset: 49618:947560700a09
>>
>> user: stefank
>>
>> date: Fri Apr 06 13:55:25 2018 +0200
>>
>> summary: 8201136: Move GC flags from globals.hpp to GC specific files
>>
>
From glaubitz at physik.fu-berlin.de Sun Apr 15 20:27:29 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Sun, 15 Apr 2018 22:27:29 +0200
Subject: Backtrace for Java thread at early JVM startup - was: Hotspot
segfaulting on Linux SPARC
In-Reply-To: <01000162c9510aff-0d69ceac-76db-4bae-ab74-9b2c3e02f298-000000@email.amazonses.com>
References: <90751820-6383-e2fc-6d17-b23607fe5975@physik.fu-berlin.de>
<01000162c9510aff-0d69ceac-76db-4bae-ab74-9b2c3e02f298-000000@email.amazonses.com>
Message-ID: <b5a2bcdc-8baa-addd-4960-e2773e9d32c8@physik.fu-berlin.de>
Hello Michael!
On 04/15/2018 02:39 PM, Michael Dardis wrote:
> The invalid value is 0xabababab in hexadecimal.
> In debug builds this option is set: https://github.com/md-5/OpenJDK/blob/1415df45a29a0a0c56adf1271786e41d5f93ca57/src/hotspot/share/runtime/globals.hpp#L905
> Which causes freed memory to be filled with 0xabababab upon clearing.
This is a very useful information. I now know what to look for.
> Probably a memory bounds issue with access above or below the correct memory chunk.
> Unfortunately I can't provide further help, but hopefully that answers your question of where it's coming from.
Thanks a lot. I actually learned today that there is a regression in
the current Linux kernel version on sparc64 which can cause memory
corruption in userland. I have updated the kernel to a version which
carries a fix for it. Let's see if that helps.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From doug.simon at oracle.com Sun Apr 15 21:27:48 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Sun, 15 Apr 2018 23:27:48 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <4616d0a8-61b0-a369-61cc-e4c82c39539e@redhat.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<f1c9b155-7f06-262c-98f6-f0d3d3b025b6@redhat.com>
<d583942c-7151-d783-14cd-658b6295203a@oracle.com>
<cf5e6638-443e-1243-96f8-599d8950c1af@redhat.com>
<F3231CFC-7B66-4BB1-B911-95AD3B2C0A83@oracle.com>
<4616d0a8-61b0-a369-61cc-e4c82c39539e@redhat.com>
Message-ID: <19F3CB79-99F3-4288-AAB4-7E54D8828837@oracle.com>
> On 15 Apr 2018, at 12:03, Andrew Haley <aph at redhat.com> wrote:
>
> On 04/14/2018 01:29 PM, Doug Simon wrote:
>>> In the meantime, be aware that Graal development on JDK11 is broken
>>> until this change is pushed to Graal. As far as I know, Graal changes
>>> are supposed to be reviewed by Graal developers.
>> Changes like this one can be reviewed by anyone in the HotSpot
>> compiler team or Graal team.
>
> That's good to know. The change is obviously correct, but it needs to
> be handled correctly.
Right. The GitHub Graal code base needs to work from JDK 8 (with a JVMCI patch) onwards. We have just recently switched to using multi-release jars to make this process saner and avoid the use of reflection to access version dependent API. When GitHub Graal snapshots are taken for syncing the code into OpenJDK, the versioned directories are flattened to the non-versioned root directory following the same logic that would be applied when resolving a versioned class at runtime. The flattenmultireleasesources command[1] was added to mx to facilitate this flattening.
The particular change in this webrev is a good opportunity to make GraalHotSpotVMConfig versioned in this way. I'll make the necessary changes for this in GitHub Graal. Normally, no manual change should be made to OpenJDK Graal but in this case I think it's necessary so that OpenJDK testing of Graal won't break.
> For my information, though, I presume "changes like this" means simple
> changes to JVMCI. That right?
Sorry for my ambiguity. I meant that this is a simple change to both JVMCI and Graal and by now most HotSpot compiler developers should be able to review it. Of course, having a Graal developer look at it as well is recommended. The preferred way to do this is to open a PR at https://github.com/graalvm/mx/pulls.
-Doug
[1] https://github.com/graalvm/mx/commit/bad56c1101db758c3f8c6560fc62012c15be39e4
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=4ZggofCo53X0nV2fk4nYuyBqw3xG4MZTeRDFqVH-pnI&s=4mmTmtLnlPEwCZErTwYIz3N2z1cw2_X5GqZs0GCBYA8&e=>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From glaubitz at physik.fu-berlin.de Sun Apr 15 22:34:09 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 16 Apr 2018 00:34:09 +0200
Subject: Backtrace for Java thread at early JVM startup - was: Hotspot
segfaulting on Linux SPARC
In-Reply-To: <3d598918-a7b5-a230-1354-ed38aebcf730@oracle.com>
References: <90751820-6383-e2fc-6d17-b23607fe5975@physik.fu-berlin.de>
<3d598918-a7b5-a230-1354-ed38aebcf730@oracle.com>
Message-ID: <9b6f39aa-3f08-cbfa-279a-2b462bf25460@physik.fu-berlin.de>
On 04/15/2018 09:28 AM, Alan Bateman wrote:
>> Now, in order to figure out what's actually wrong, it would be handy to get
>> a backtrace of the Java thread to understand where the invalid value for
>> loadFactor, -1.2197928E-12, comes from.
> Can you try `java -Xlog:init=debug --version` ?
This actually provides a backtrace:
glaubitz at deb4g:/srv/glaubitz/hs$ ./build/linux-sparcv9-normal-server-fastdebug/jdk/bin/java -Xlog:init=debug --version
Error occurred during initialization of boot layer
java.lang.module.FindException: Error reading module: /srv/glaubitz/hs/build/linux-sparcv9-normal-server-fastdebug/jdk/modules/java.management
at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:349)
at java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:283)
at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:231)
at java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:189)
at java.base/jdk.internal.module.ModulePath.find(ModulePath.java:153)
at java.base/jdk.internal.module.SystemModuleFinders$1.lambda$find$0(SystemModuleFinders.java:214)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/jdk.internal.module.SystemModuleFinders$1.find(SystemModuleFinders.java:215)
at java.base/jdk.internal.module.ModuleBootstrap.boot(ModuleBootstrap.java:204)
at java.base/java.lang.System.initPhase2(System.java:1976)
Caused by: java.lang.module.InvalidModuleDescriptorException: Illegal load factor: -1.2197928E-12
at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1092)
at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:134)
at java.base/jdk.internal.module.ModulePath.readExplodedModule(ModulePath.java:688)
at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:319)
... 9 more
glaubitz at deb4g:/srv/glaubitz/hs$
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From aph at redhat.com Mon Apr 16 09:03:31 2018
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Apr 2018 10:03:31 +0100
Subject: 8185505: AArch64: Port AOT
In-Reply-To: <AM5PR0802MB2449400467C4E4042C3C6A6390B00@AM5PR0802MB2449.eurprd08.prod.outlook.com>
References: <b439eaf0-e026-7ff8-e832-3717368027e4@redhat.com>
<AM5PR0802MB2449400467C4E4042C3C6A6390B00@AM5PR0802MB2449.eurprd08.prod.outlook.com>
Message-ID: <57767253-4826-e5b4-d142-7990d7114704@redhat.com>
On 04/16/2018 09:53 AM, Ningsheng Jian wrote:
> I can see both the jdk patch and Graal PR contain changes of AArch64Assembler.java and AArch64MacroAssembler.java, but the changes looks somewhat different. How will they be synced?
The changes to Graal in JDK do no more than allow OpenJDK to build. They
are not called by anything, and will disappear at the next Graal import.
> I noticed that in make/hotspot/lib/JvmFeatures.gmk line ~144, there's:
>
> JVM_EXCLUDE_FILES += \
> compiledIC_aot_x86_64.cpp
>
> Do you want to add compiledIC_aot_aarch64.cpp to that list?
I don't really know what this does, so I have no idea.
> I also found that _immutable_PIC and its getters/setters are in the INCLUDE_AOT block, but some of their uses are not:
>
> src/hotspot/cpu/aarch64/compiledIC_aarch64.cpp:
>
> 61 if (cbuf.immutable_PIC()) {
>
> src/hotspot/share/jvmci/jvmciCodeInstaller.cpp:
>
> 594 buffer.set_immutable_PIC(_immutable_pic_compilation);
> 628 buffer.set_immutable_PIC(_immutable_pic_compilation);
Thank you. For the sake of consistency I will change it.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From thomas.stuefe at gmail.com Mon Apr 16 09:56:53 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 16 Apr 2018 11:56:53 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<11d9c2a6-7a7d-5498-f075-ca1c6b84f18d@redhat.com>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
<6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
Message-ID: <CAA-vtUwnVXnRPkT6Waw=q3SsV+J33TYUmY-3MM76QBYMZ9DqJg@mail.gmail.com>
Hi,
just curious, I lost track in this thread... Is this the same issue:
https://bugs.openjdk.java.net/browse/JDK-8200288
?
Thanks, Thomas
On Mon, Apr 9, 2018 at 11:15 PM, John Paul Adrian Glaubitz
<glaubitz at physik.fu-berlin.de> wrote:
> On 04/09/2018 11:11 PM, David Holmes wrote:
>>> (gdb) bt
>>> #0 0xffff8001080d7f68 in ?? ()
>>> #1 0xffff800101c88a34 in SafeFetch32 (errValue=2748, adr=0xabc0000000000abc) at /srv/openjdk/hs/src/hotspot/share/runtime/stubRoutines.hpp:460
>>
>> This isn't the assertion failure stack.
>
> You're right. Somehow gdb tricked me.
>
> I think this looks better:
>
> (gdb) bt
> #0 0xffff8001006afb9c in __libc_signal_restore_set (set=0xffff80012df915b8) at ../sysdeps/unix/sysv/linux/nptl-signals.h:80
> #1 __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:48
> #2 0xffff8001006b1144 in __GI_abort () at abort.c:79
> #3 0xffff800101af17ac in os::abort (dump_core=<optimized out>, siginfo=0x0, context=0x0) at /srv/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:1423
> #4 0xffff800101f0d45c in VMError::report_and_die (id=id at entry=-536870912, message=message at entry=0xffff800101fef9a0 "assert(!(is_cti(prev) && is_cti(insn)))
> failed",
> detail_fmt=detail_fmt at entry=0xffff800101fef988 "CTI-CTI not allowed.", detail_args=detail_args at entry=0xffff80012df91d10,
> thread=thread at entry=0xffff8001042cf000,
> pc=pc at entry=0x0, siginfo=0x0, context=0x0, filename=0xffff800101fef948 "/srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.cpp", lineno=52, size=0)
> at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1504
> #5 0xffff800101f0e298 in VMError::report_and_die (thread=0xffff8001042cf000, context=context at entry=0x0,
> filename=filename at entry=0xffff800101fef948 "/srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.cpp", lineno=lineno at entry=52,
> message=message at entry=0xffff800101fef9a0 "assert(!(is_cti(prev) && is_cti(insn))) failed", detail_fmt=detail_fmt at entry=0xffff800101fef988 "CTI-CTI not
> allowed.",
> detail_args=<optimized out>) at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1244
> #6 0xffff80010117cdec in report_vm_error (file=0xffff800101fef948 "/srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.cpp", line=line at entry=52,
> error_msg=0xffff800101fef9a0 "assert(!(is_cti(prev) && is_cti(insn))) failed", detail_fmt=0xffff800101fef988 "CTI-CTI not allowed.")
> at /srv/openjdk/hs/src/hotspot/share/utilities/debug.cpp:230
> #7 0xffff800100c92e70 in Assembler::validate_no_pipeline_hazards (this=this at entry=0xffff800180029510) at
> /srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.cpp:52
> #8 0xffff800100d220ec in Assembler::flush (this=0xffff800180029510) at /srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.hpp:786
> #9 Compilation::emit_code_epilog (assembler=0xffff80012df91df8, this=0xffff80012df92310) at /srv/openjdk/hs/src/hotspot/share/c1/c1_Compilation.cpp:319
> #10 Compilation::emit_code_body (this=this at entry=0xffff80012df92310) at /srv/openjdk/hs/src/hotspot/share/c1/c1_Compilation.cpp:355
> #11 0xffff800100d228e0 in Compilation::compile_java_method (this=this at entry=0xffff80012df92310) at /srv/openjdk/hs/src/hotspot/share/c1/c1_Compilation.cpp:404
> #12 0xffff800100d23960 in Compilation::compile_method (this=this at entry=0xffff80012df92310) at /srv/openjdk/hs/src/hotspot/share/c1/c1_Compilation.cpp:460
> #13 0xffff800100d24754 in Compilation::Compilation (this=0xffff80012df92310, compiler=<optimized out>, env=<optimized out>, method=0xffff800180010ee0,
> osr_bci=<optimized out>, buffer_blob=<optimized out>, directive=0xffff8001041f7980) at /srv/openjdk/hs/src/hotspot/share/c1/c1_Compilation.cpp:584
> #14 0xffff800100d2717c in Compiler::compile_method (this=0xffff80010429f8a0, env=0xffff80012df92828, method=0xffff800180010ee0, entry_bci=<optimized out>,
> directive=<optimized out>) at /srv/openjdk/hs/src/hotspot/share/c1/c1_Compiler.cpp:249
> #15 0xffff8001010da944 in CompileBroker::invoke_compiler_on_method (task=task at entry=0xffff8001042c9650)
> at /srv/openjdk/hs/src/hotspot/share/compiler/compileBroker.cpp:1915
> #16 0xffff8001010dcf14 in CompileBroker::compiler_thread_loop () at /srv/openjdk/hs/src/hotspot/share/compiler/compileBroker.cpp:1620
> #17 0xffff800101e3d21c in JavaThread::thread_main_inner (this=this at entry=0xffff8001042cf000) at /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:1797
> #18 0xffff800101e3d810 in JavaThread::run (this=0xffff8001042cf000) at /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:1777
> #19 0xffff800101afb5c8 in thread_native_entry (thread=0xffff8001042cf000) at /srv/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:710
> #20 0xffff800100347874 in start_thread (arg=0xffff80012df93910) at pthread_create.c:463
> #21 0xffff800100763140 in __thread_start () at ../sysdeps/unix/sysv/linux/sparc/sparc64/clone.S:78
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)
>
> --
> .''`. John Paul Adrian Glaubitz
> : :' : Debian Developer - glaubitz at debian.org
> `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From glaubitz at physik.fu-berlin.de Mon Apr 16 10:44:26 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 16 Apr 2018 12:44:26 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <CAA-vtUwnVXnRPkT6Waw=q3SsV+J33TYUmY-3MM76QBYMZ9DqJg@mail.gmail.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<087f95e3-85f6-7029-fa42-50910380610c@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
<6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
<CAA-vtUwnVXnRPkT6Waw=q3SsV+J33TYUmY-3MM76QBYMZ9DqJg@mail.gmail.com>
Message-ID: <43f7de51-4fd9-3dac-2e23-f40ce3e7b4c0@physik.fu-berlin.de>
Hi Thomas!
On 04/16/2018 11:56 AM, Thomas St?fe wrote:
> just curious, I lost track in this thread... Is this the same issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8200288
Yes, this must be related:
glaubitz at stadler:/srv/openjdk/hs$ ./build/linux-sparcv9-normal-server-fastdebug/jdk/bin/java --version
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=/assembler_sparc.cpp:52
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/srv/openjdk/hs/src/hotspot/cpu/sparc/assembler_sparc.cpp:52), pid=9953, tid=9980
# assert(!(is_cti(prev) && is_cti(insn))) failed: CTI-CTI not allowed.
#
# JRE version: OpenJDK Runtime Environment (11.0) (fastdebug build 11-internal+0-adhoc.glaubitz.hs)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 11-internal+0-adhoc.glaubitz.hs, mixed mode, tiered, compressed oops, g1 gc, linux-sparc)
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /srv/openjdk/hs/hs_err_pid9953.log
#
# Compiler replay data is saved as:
# /srv/openjdk/hs/replay_pid9953.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
Current thread is 9980
Dumping core ...
Aborted
glaubitz at stadler:/srv/openjdk/hs$
Maybe this is indirectly causing the issue with the load factor that
I sometimes see.
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From adam.farley at uk.ibm.com Mon Apr 16 10:46:00 2018
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Mon, 16 Apr 2018 11:46:00 +0100
Subject: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory
Usage for Direct Byte Buffers
In-Reply-To: <044af3a4-016c-9225-ee49-7cd7d23daefa@oracle.com>
References: <OF081603B6.A5E4A0E9-ON0025826E.00432B47-8025826E.004E432A@notes.na.collabserv.com>
<044af3a4-016c-9225-ee49-7cd7d23daefa@oracle.com>
Message-ID: <OFECEAB370.7427015D-ON00258271.0038C76F-80258271.003B24A5@notes.na.collabserv.com>
> On 13/04/2018 15:14, Adam Farley8 wrote:
>> Hi Alan, Peter,
>>
>> I see that native memory is tracked in java.nio.Bits, but that only
includes what the user thinks they are allocating.
>>
>> When the VM adds extra memory to the allocation amount this extra bit
is not represented in the Bits total.
>> A cursory glance shows, minimum, that we round the requested memory
quantity up to the heap word size in
>> the Unsafe.allocateMemory code, and something to do with
nmt_header_size in os:malloc() (os.cpp) too.
> Is the align_up(sz, HeapWordSize) really causing an issue?
Coupled with the nmt_header_size business, it makes the Bits values wrong.
The more DBB allocations, the more
inaccurate those numbers will be.
>
> We could change Bits to align with HotSpot. The BufferPoolMXBean API
allows the capacity and memory usage to differ (when we originally added
this, direct buffers were page aligned) so doing this would mean it more
accurately reflects the memory allocated to direct buffers.
>
> -Alan
I agree with you that the "+x" information should be added to only one of
the two atomic longs.
To get "X", it seems to me that the best option would be to introduce an
native method in Bits that fetches
"X" directly from Hotspot, using the same code that Hotspot uses (so we'd
have to abstract-out the Hotspot logic
that adds X to the memory quantity).
This way, anyone modifying the Hotspot logic won't risk rendering the Bits
logic wrong again.
Best Regards
Adam Farley
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
From glaubitz at physik.fu-berlin.de Mon Apr 16 10:49:07 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 16 Apr 2018 12:49:07 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <43f7de51-4fd9-3dac-2e23-f40ce3e7b4c0@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<34d61f68-2b24-cd17-898c-c28f31f07da9@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
<6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
<CAA-vtUwnVXnRPkT6Waw=q3SsV+J33TYUmY-3MM76QBYMZ9DqJg@mail.gmail.com>
<43f7de51-4fd9-3dac-2e23-f40ce3e7b4c0@physik.fu-berlin.de>
Message-ID: <3ea48b20-8d19-18f4-40e5-d8beb6c35461@physik.fu-berlin.de>
On 04/16/2018 12:44 PM, John Paul Adrian Glaubitz wrote:
> Maybe this is indirectly causing the issue with the load factor that
> I sometimes see.
Ah, according to the bug report, this particular issue affects older
SPARC CPUs only. This explains why it happens on the UltraSPARC T1
but currently not on the SPARC T5.
Will keep on digging! Thanks for the additional pointers.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From magnus.ihse.bursie at oracle.com Mon Apr 16 13:03:12 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 16 Apr 2018 15:03:12 +0200
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
places in function declarations/implementations
In-Reply-To: <c93c031a-2527-3d3e-369e-9f6274c2ad3b@oracle.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
<81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com>
<7c5e68c2a023490e96ce6452fbda1700@sap.com>
<c7f9df33-e9c8-2fcd-f8bd-df7f5a1e2494@oracle.com>
<9fff2e7e-06ac-54c1-8f66-33bff34ea621@oracle.com>
<f6dbd54e78714305b78ecd3a3d232f11@sap.com>
<c93c031a-2527-3d3e-369e-9f6274c2ad3b@oracle.com>
Message-ID: <e848b584-23c3-9690-1b2f-9c6d210ab3da@oracle.com>
On 2018-04-16 14:59, Alexey Ivanov wrote:
> Hi Matthias, Phil,
>
> The build of 32 bit Windows is broken because of mlib_image.dll. As
> JNICALL modifier has been added to function declarations, they're
> exported with a decorated name, for example _j2d_mlib_ImageCreate at 16.
> The functions in this library are looked up by their name [1] and
> therefore none can be found.
You should most likely just be able to remove the JNICALL modifiers for
libmlib_image.
/Magnus
>
> If you run tests in test/jdk/java/awt/image, for example
> test/jdk/java/awt/image/mlib/MlibOpsTest.java, some of them fail
> because ImagingLib is not available.
>
> I'm working on a patch to fix it.
>
>
> Regards,
> Alexey
>
> [1]
> http://hg.openjdk.java.net/jdk/jdk/file/bc1c7e41e285/src/java.desktop/windows/native/libawt/windows/awt_Mlib.cpp#l60
>
> On 13/04/2018 06:48, Baesken, Matthias wrote:
>> Hi Phil/Alexey,? thanks for? adding the other lists .
>>
>>> Is this the current version of the change :
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ ?
>> Yes.
>>
>> Best regards, Matthias
>>
>>
>>> -----Original Message-----
>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>>> Sent: Donnerstag, 12. April 2018 23:53
>>> To: Phil Race <philip.race at oracle.com>; Baesken, Matthias
>>> <matthias.baesken at sap.com>; Alan Bateman <Alan.Bateman at oracle.com>;
>>> Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
>>> Cc: build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Doerr,
>>> Martin <martin.doerr at sap.com>; 2d-dev <2d-dev at openjdk.java.net>;
>>> hotspot-dev <hotspot-dev at openjdk.java.net>
>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>> function
>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>> some places in function declarations/implementations
>>>
>>>
>>> On 12/04/2018 21:42, Phil Race wrote:
>>>> How can JNIEXPORT be different between 32 bit & 64 bit ?
>>>> I'm sure you saw compilation errors but I don't get why it failed for
>>>> 32 only.
>>>>
>>>> JNICALL (_stdcall) may be unnecessary on 64 bit Windows but that
>>>> doesn't
>>>> explain why the 32 bit compiler would complain about inconsistent
>>>> application
>>>> of __declspec(dllexport) - ie JNIEXPORT.
>>>>
>>>> Or is that part (adding JNIEXPORT) pure clean up and the compilation
>>>> errors were all down to JNICALL ?
>>> Adding missing JNIEXPORT is for cleanup only.
>>>
>>> The compiler complained about mismatched JNICALL / non-JNICALL
>>> declarations as the macro changes calling convention from the default
>>> __cdecl? to __stdcall on 32 bit Windows.
>>>
>>> Another issue is that __stdcall decorates the functions: prefixes with
>>> underscore and postfixes with @ + size of parameters. Because of the
>>> decorations, classLoader.cpp can't lookup the required functions by
>>> name
>>> from zip.dll and jimage.dll. The functions are exported but with
>>> different name.
>>>
>>> I hope this information adds more details to the picture.
>>>
>>>> I was a bit puzzled at the removals I saw here :
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.deskto
>>> p/share/native/libsplashscreen/splashscreen_impl.h.udiff.html
>>>> .. I needed to look at the whole file to realise that you were
>>>> removing a duplicate
>>>> declaration.
>>> That was tricky. I could have been mentioned in the review.
>>>
>>>
>>> Regards,
>>> Alexey
>>>
>>>> -phil.
>>>>
>>>> On 04/12/2018 04:04 AM, Baesken, Matthias wrote:
>>>>> Hi? Alan , this is the up to date webrev .
>>>>> However we want to add?? Alexey?? Ivanov? as additional author .
>>>>>
>>>>>> As I read it, this changes the calling convention of these
>>>>>> functions on
>>>>>> 32-bit Windows but it will have no impact on 64-bit Windows (as
>>>>>> __stdcall is ignored) or other platforms, is that correct?
>>>>>>
>>>>> The? change adds? JNIEXPORT?? at some places? where it is ben
>>>>> forgotten , for example :
>>>>>
>>>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp.c.udiff.html
>>>
>>>>>
>>>>> This might have? potential? impact? on other platforms (fixes the
>>>>> mismatches) .
>>>>>
>>>>> Best regards, Matthias
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
>>>>>> Sent: Donnerstag, 12. April 2018 12:54
>>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse
>>>>>> Bursie <magnus.ihse.bursie at oracle.com>
>>>>>> Cc: build-dev at openjdk.java.net; Doerr, Martin
>>>>>> <martin.doerr at sap.com>; core-libs-dev at openjdk.java.net
>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>>>>> function
>>>>>> declarations/implementations - was : RE: missing JNIEXPORT /
>>>>>> JNICALL at
>>>>>> some places in function declarations/implementations
>>>>>>
>>>>>> Adding core-libs-dev as this is change code in libjava, libzip,
>>>>>> libjimage, ...
>>>>>>
>>>>>> Can you confirm that this is the up to date webrev:
>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
>>>>>>
>>>>>> As I read it, this changes the calling convention of these
>>>>>> functions on
>>>>>> 32-bit Windows but it will have no impact on 64-bit Windows (as
>>>>>> __stdcall is ignored) or other platforms, is that correct?
>>>>>>
>>>>>> -Alan
>>>>>>
>>>>>>
>>>>>> <SNIP>
>
From glaubitz at physik.fu-berlin.de Mon Apr 16 13:09:41 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 16 Apr 2018 15:09:41 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <3ea48b20-8d19-18f4-40e5-d8beb6c35461@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<5eae9163-b262-2f7d-affa-ac29e979fbe6@redhat.com>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
<6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
<CAA-vtUwnVXnRPkT6Waw=q3SsV+J33TYUmY-3MM76QBYMZ9DqJg@mail.gmail.com>
<43f7de51-4fd9-3dac-2e23-f40ce3e7b4c0@physik.fu-berlin.de>
<3ea48b20-8d19-18f4-40e5-d8beb6c35461@physik.fu-berlin.de>
Message-ID: <49cd1bbe-0243-d34e-7990-7e727e3e509a@physik.fu-berlin.de>
On 04/16/2018 12:49 PM, John Paul Adrian Glaubitz wrote:
> Ah, according to the bug report, this particular issue affects older
> SPARC CPUs only. This explains why it happens on the UltraSPARC T1
> but currently not on the SPARC T5.
>
> Will keep on digging! Thanks for the additional pointers.
Ok, so the actual crash after working around JDK-8144448 now seems this one:
(gdb) bt
#0 0xffff8001006abb9c in __libc_signal_restore_set (set=0xffff8001026d0f28) at ../sysdeps/unix/sysv/linux/nptl-signals.h:80
#1 __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#2 0xffff8001006ad144 in __GI_abort () at abort.c:79
#3 0xffff800101aeefbc in os::abort (dump_core=<optimized out>, siginfo=0xffff8001026d1fb0, context=0xffff8001026d1fb0) at /srv/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:1423
#4 0xffff800101f0f38c in VMError::report_and_die (id=id at entry=-536870912, message=message at entry=0xffff80010205b260 "fatal error", detail_fmt=detail_fmt at entry=0xffff80010214f850 "LEAF method calling lock?", detail_args=detail_args at entry=0xffff8001026d1678,
thread=thread at entry=0xffff80010401a000, pc=pc at entry=0x0, siginfo=0x0, context=0x0, filename=0xffff80010214eec8 "/srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp", lineno=985, size=0) at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1504
#5 0xffff800101f101c8 in VMError::report_and_die (thread=0xffff80010401a000, context=context at entry=0x0, filename=filename at entry=0xffff80010214eec8 "/srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp", lineno=lineno at entry=985,
message=0xffff80010205b260 "fatal error", detail_fmt=detail_fmt at entry=0xffff80010214f850 "LEAF method calling lock?", detail_args=<optimized out>) at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1244
#6 0xffff80010117e6c8 in report_fatal (file=0xffff80010214eec8 "/srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp", line=line at entry=985, detail_fmt=0xffff80010214f850 "LEAF method calling lock?") at /srv/openjdk/hs/src/hotspot/share/utilities/debug.cpp:250
#7 0xffff800101e2ae10 in Thread::check_for_valid_safepoint_state (this=this at entry=0xffff80010401a000, potential_vm_operation=potential_vm_operation at entry=false) at /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:985
#8 0xffff800101e49394 in ThreadsSMRSupport::acquire_stable_list (is_ThreadsListSetter=false, self=0xffff80010401a000) at /srv/openjdk/hs/src/hotspot/share/runtime/threadSMR.cpp:629
#9 ThreadsListHandle::ThreadsListHandle (this=0xffff8001026d1818, self=0xffff80010401a000) at /srv/openjdk/hs/src/hotspot/share/runtime/threadSMR.cpp:471
#10 0xffff800101ae1af0 in JavaThreadIteratorWithHandle::JavaThreadIteratorWithHandle (this=0xffff8001026d1810) at /srv/openjdk/hs/src/hotspot/share/runtime/threadSMR.hpp:307
#11 os::print_location (st=st at entry=0xffff8001023e3228 <VMError::log>, x=416, verbose=verbose at entry=false) at /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:1113
#12 0xffff800101b02b3c in os::print_register_info (st=st at entry=0xffff8001023e3228 <VMError::log>, context=0xffff8001026d1fb0) at /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp:253
#13 0xffff800101f0dfac in VMError::report (st=st at entry=0xffff8001023e3228 <VMError::log>, _verbose=_verbose at entry=true) at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:748
#14 0xffff800101f0f440 in VMError::report_and_die (id=id at entry=11, message=message at entry=0x0, detail_fmt=detail_fmt at entry=0xffff80010214c870 "%s", detail_args=detail_args at entry=0xffff8001026d1ce0, thread=thread at entry=0xffff80010401a000,
pc=pc at entry=0xffff80010fbfd0c8 "\300\\ ", siginfo=0xffff8001026d1fb0, context=0xffff8001026d1fb0, filename=0x0, lineno=0, size=0) at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1405
#15 0xffff800101f100b8 in VMError::report_and_die (thread=thread at entry=0xffff80010401a000, sig=sig at entry=11, pc=pc at entry=0xffff80010fbfd0c8 "\300\\ ", siginfo=siginfo at entry=0xffff8001026d1fb0, context=context at entry=0xffff8001026d1fb0, detail_fmt=0xffff80010214c870 "%s")
at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1219
#16 0xffff800101f10104 in VMError::report_and_die (thread=thread at entry=0xffff80010401a000, sig=sig at entry=11, pc=pc at entry=0xffff80010fbfd0c8 "\300\\ ", siginfo=siginfo at entry=0xffff8001026d1fb0, context=context at entry=0xffff8001026d1fb0)
at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1225
#17 0xffff800101b058b4 in JVM_handle_linux_signal (sig=sig at entry=11, info=info at entry=0xffff8001026d1fb0, ucVoid=ucVoid at entry=0xffff8001026d1fb0, abort_if_unrecognized=abort_if_unrecognized at entry=1) at /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp:646
#18 0xffff800101aec0a0 in signalHandler (sig=<optimized out>, info=0xffff8001026d1fb0, uc=0xffff8001026d1fb0) at /srv/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:4396
#19 <signal handler called>
#20 0xffff80010fbfd0c8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From coleen.phillimore at oracle.com Mon Apr 16 14:00:50 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 16 Apr 2018 10:00:50 -0400
Subject: RFR (M) 8201537: Remove is_alive closure from Klass::is_loader_alive()
Message-ID: <f380f832-3c6d-5c60-09c5-4b447f87d94b@oracle.com>
Summary: remove is_alive closure from callers of Klass::is_loader_alive
so that cleaning metadata doesn't require GC closure.
This changes runtime, GC and compiler code.
Tested with mach5 tier1-5 with no failures.
open webrev at http://cr.openjdk.java.net/~coleenp/8201537.01/webrev
bug link https://bugs.openjdk.java.net/browse/JDK-8201537
Thanks,
Coleen
From gunter.haug at sap.com Mon Apr 16 14:03:49 2018
From: gunter.haug at sap.com (Haug, Gunter)
Date: Mon, 16 Apr 2018 14:03:49 +0000
Subject: RFR(S): 8200720: Print accumulated number of allocated bytes in
thread dump
In-Reply-To: <721b10fe-742a-4d4b-0b97-44258664a408@oracle.com>
References: <171FA571-AFEC-4E88-B681-D10F8DFD1639@sap.com>
<721b10fe-742a-4d4b-0b97-44258664a408@oracle.com>
Message-ID: <62D591F7-AA82-40A3-B518-53AD60DC97BE@sap.com>
Hi Stefan,
Thank you for your reply and sorry for being late with mine.
Probably I made a poor choice with the field I took as an example. There is absolutely no reason to add a separate accounting mechanism for bytes allocated by a thread. We implemented our version many years ago, sorry that I didn't check this again. In this particular case we could just use the existing one and get rid of ours.
However, as mentioned, we output more data (cpu time, number of defined classes, number of files opened, number of socks opened, number of bytes read/written via file and socket io and pthread-id) in the thread dump. The question is: is it desirable or even acceptable to add this information (or in fact any information) to the thread dump output?
Thank you,
Gunter
?On 06.04.18, 10:24, "hotspot-dev on behalf of Stefan Johansson" <hotspot-dev-bounces at openjdk.java.net on behalf of stefan.johansson at oracle.com> wrote:
Hi Gunter,
On 2018-04-05 12:28, Haug, Gunter wrote:
> Hi,
>
> can I please have a review and a sponsor for the following enhancement:
>
> http://cr.openjdk.java.net/~ghaug/webrevs/8200720
> https://bugs.openjdk.java.net/browse/JDK-8200720
>
There is already accounting of allocated bytes on Thread:
jlong _allocated_bytes; // Cumulative number of bytes allocated on
// the Java heap
The value is updated at TLAB refills and allocations outside the TLAB,
so it already includes the type allocations JC is mentioning. Any reason
this can't be used instead of adding your new accounting?
To include bytes allocated in the current TLAB you can call:
Thread::cooked_allocated_bytes();
Thanks,
Stefan
> We at SAP have extended the thread dumps (obtained by jstack or jcmd) by several fields providing thread specific information. These extensions are quite popular with our support team. With some knowledge of the architecture of the application, they often allow for quick and simple diagnosis of a running system. Therefore we would like to contribute these enhancements.
>
> I took the quite simple accumulated number of bytes allocated by a thread as an example. This only works with TLAB active. Provided it is known how the application should behave, a misbehaving thread can identified easily.
>
> There is no measurable overhead for this enhancement. However, it may be a problem that the format of the output is changed. Tools parsing the output may have to be changed.
>
> Here is an example of the output generated:
>
> ---------------------------------------------------------
> "main" #1 prio=5 os_prio=31 allocated=243048448B tid=0x00007fca98000800 nid=0x1d03 waiting on condition [0x0000000109baa000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(java.base/Native Method)
> ...
> ---------------------------------------------------------
>
> As mentioned above, we have a whole bunch of other enhancements to the thread dump similar to this one and would be willing to contribute them if there is any interest.
>
> Thanks and best regards,
> Gunter
>
From gunter.haug at sap.com Mon Apr 16 14:04:08 2018
From: gunter.haug at sap.com (Haug, Gunter)
Date: Mon, 16 Apr 2018 14:04:08 +0000
Subject: RFR(S): 8200720: Print accumulated number of allocated bytes in
thread dump
In-Reply-To: <CAF9BGBx1fixaHdb-edT+BXu-YnFMo-UpuYg43jXuifNL00L0Aw@mail.gmail.com>
References: <171FA571-AFEC-4E88-B681-D10F8DFD1639@sap.com>
<CAF9BGBx1fixaHdb-edT+BXu-YnFMo-UpuYg43jXuifNL00L0Aw@mail.gmail.com>
Message-ID: <8A37C807-0588-468C-A433-30E2C1C561F3@sap.com>
Hi Jc,
Thank you for your reply and sorry for being late with mine!
You?re completely right with everything you write. It would be best to either piggy back our counters in your ThreadHeapSampler side structure (probably rename it and incorporate the improvements you suggest) or even better have the sampling system provide this information as you describe.
OTOH as mentioned, we output more data (cpu time, number of defined classes, number of files opened, number of socks opened, number of bytes read/written via file and socket io and pthread-id), so it would also be an option to implement a separate side structure to hold data required.
Thank you very much,
Gunter
From: JC Beyler <jcbeyler at google.com>
Date: Thursday, 5. April 2018 at 18:02
To: "Haug, Gunter" <gunter.haug at sap.com>
Cc: hotspot-dev Source Developers <hotspot-dev at openjdk.java.net>
Subject: Re: RFR(S): 8200720: Print accumulated number of allocated bytes in thread dump
Hi Gunter,
I really am new to the Java scene so I really am not speaking about the implementation and its potential integration into the code. Or even would the feature be accepted or not, however, from what I've seen in the webrev you provided:
? - In theory, adding to Thread is not really accepted and a side structure is better, perhaps we could piggy back on the same structure, since I'm trying to add one called ThreadHeapSampler, we could rename it to ThreadHeapInformation and both use that (see?http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.10/src/hotspot/share/runtime/threadHeapSampler.cpp.html) in order to not have different structures provide similar information topics.
? -??bytes_in_tlab should be words_in_tlab if I'm not mistaken
? - seems like you are missing allocations that do not fit in the TLAB due to too big, no?
On another note, depending on what your users want, this might not be relevant:
We actually implemented a similar approach but it was on top of the sampling technique I'm pushing currently. It provides the same information you do but also the bytes allocated still live for a given thread due to how our internal system is implemented (because our users preferred to know how much a thread was holding instead of how much a thread allocated). With the work I'm doing here (via JDK-8171119), it might be reasonable and do-able to have the sampling system provide this information on the native agent side (and thus you can do your implementation and provide the data to your users without this change). Would this perhaps be of interest to you? We could build an example test and you can test it on your side and I can test it on mine and we can see how far off either technique is in regards to the information about per thread allocation?
I have not done the overhead calculation of this in a long time, we could wrap that together and see if that's acceptable. I'm not sure you get a 0% as you do but it would be small.
Thanks,
Jc
On Thu, Apr 5, 2018 at 3:28 AM Haug, Gunter <mailto:gunter.haug at sap.com> wrote:
Hi,
can I please have a review and a sponsor for the following enhancement:
http://cr.openjdk.java.net/~ghaug/webrevs/8200720
https://bugs.openjdk.java.net/browse/JDK-8200720
We at SAP have extended the thread dumps (obtained by jstack or jcmd) by several fields providing thread specific information. These extensions are quite popular with our support team. With some knowledge of the architecture of the application, they often allow for quick and simple diagnosis of a running system. Therefore we would like to contribute these enhancements.
I took the quite simple accumulated number of bytes allocated by a thread as an example. This only works with TLAB active. Provided it is known how the application should behave, a misbehaving thread can identified easily.
There is no measurable overhead for this enhancement. However, it may be a problem that the format of the output is changed. Tools parsing the output may have to be changed.
Here is an example of the output generated:
---------------------------------------------------------
"main" #1 prio=5 os_prio=31 allocated=243048448B tid=0x00007fca98000800 nid=0x1d03 waiting on condition? [0x0000000109baa000]
? ?java.lang.Thread.State: TIMED_WAITING (sleeping)
? ? ? ? at java.lang.Thread.sleep(java.base/Native Method)
? ? ? ? ? ? ? ?...
---------------------------------------------------------
As mentioned above, we have a whole bunch of other enhancements to the thread dump similar to this one and would be willing to contribute them if there is any interest.
Thanks and best regards,
Gunter
From erik.osterlund at oracle.com Mon Apr 16 14:26:00 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Mon, 16 Apr 2018 16:26:00 +0200
Subject: RFR (M) 8200555: OopHandle should use Access API
In-Reply-To: <f176b0d9-6152-45d2-ace9-1effb6b5fa28@oracle.com>
References: <f176b0d9-6152-45d2-ace9-1effb6b5fa28@oracle.com>
Message-ID: <5AD4B278.8060901@oracle.com>
Hi Coleen,
This looks good to me. Thank you for accessorizing OopHandle.
Thanks,
/Erik
On 2018-04-13 16:56, coleen.phillimore at oracle.com wrote:
> Summary: Add RootAccess<> to OopHandle.resolve() in runtime and
> interpreter code. Add comments for compiler code for later.
>
> For the current GCs this code does not generate additional code. Also,
> the compiler Access API code is TBD. Since oopHandle.hpp erroneously
> included orderAccess.hpp and atomic.hpp, some include file fixing is
> also in this change.
>
> Tested with mach5 tier1,tier2 on all Oracle platforms. Also tested
> compilation on linux-aarch64. The other non-Oracle platforms weren't
> changed because they'll never need this.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8200555.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8200555
>
> Thanks,
> Coleen
From adinn at redhat.com Mon Apr 16 14:59:23 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 16 Apr 2018 15:59:23 +0100
Subject: RFR (M) 8201537: Remove is_alive closure from
Klass::is_loader_alive()
In-Reply-To: <f380f832-3c6d-5c60-09c5-4b447f87d94b@oracle.com>
References: <f380f832-3c6d-5c60-09c5-4b447f87d94b@oracle.com>
Message-ID: <e0d09fd2-bfe1-cbc0-4949-a011e86b8260@redhat.com>
Hi Coleen,
On 16/04/18 15:00, coleen.phillimore at oracle.com wrote:
> Summary: remove is_alive closure from callers of Klass::is_loader_alive
> so that cleaning metadata doesn't require GC closure.
>
> This changes runtime, GC and compiler code.
>
> Tested with mach5 tier1-5 with no failures.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8201537.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8201537
The changes look good to me.
I think you missed copyright updates in
loaderConstraints.cpp
resolutionErrors.cpp
genMarkSweep.cpp
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
From glaubitz at physik.fu-berlin.de Mon Apr 16 15:07:54 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 16 Apr 2018 17:07:54 +0200
Subject: Confusing Mercurial history - was: Re: Hotspot segfaulting on Linux
SPARC
Message-ID: <a7c616c3-830b-9411-f50e-cf4f4c6ddd27@physik.fu-berlin.de>
Hi!
I am trying to bisect the segefault I am seeing on linux-sparc.
For this, I am checking out revision 46931 which should be a good one.
However, trying to build this revision shows that the checked out version
is missing the patches from revision 46667 and 46668, so I have to make
those changes manually.
Is there any explanation why a checkout from the newer revision 46931
is missing the changes from the revisions 46667 and 46668? I have
the impression I am using Mercurial wrong :(.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From coleen.phillimore at oracle.com Mon Apr 16 15:20:21 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 16 Apr 2018 11:20:21 -0400
Subject: RFR (M) 8201537: Remove is_alive closure from
Klass::is_loader_alive()
In-Reply-To: <e0d09fd2-bfe1-cbc0-4949-a011e86b8260@redhat.com>
References: <f380f832-3c6d-5c60-09c5-4b447f87d94b@oracle.com>
<e0d09fd2-bfe1-cbc0-4949-a011e86b8260@redhat.com>
Message-ID: <f5e97b68-2e36-4966-e680-d0cdac69b7a7@oracle.com>
On 4/16/18 10:59 AM, Andrew Dinn wrote:
> Hi Coleen,
>
> On 16/04/18 15:00, coleen.phillimore at oracle.com wrote:
>> Summary: remove is_alive closure from callers of Klass::is_loader_alive
>> so that cleaning metadata doesn't require GC closure.
>>
>> This changes runtime, GC and compiler code.
>>
>> Tested with mach5 tier1-5 with no failures.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8201537.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8201537
> The changes look good to me.
>
> I think you missed copyright updates in
>
> loaderConstraints.cpp
> resolutionErrors.cpp
> genMarkSweep.cpp
Thanks Andrew.
I forgot to mention that I update the copyrights in my commit script so
that people don't have to see that change.
thanks!
Coleen
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
From coleen.phillimore at oracle.com Mon Apr 16 15:21:02 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 16 Apr 2018 11:21:02 -0400
Subject: RFR (M) 8200555: OopHandle should use Access API
In-Reply-To: <5AD4B278.8060901@oracle.com>
References: <f176b0d9-6152-45d2-ace9-1effb6b5fa28@oracle.com>
<5AD4B278.8060901@oracle.com>
Message-ID: <b1618bc0-5399-7068-593d-fe2eaacf0ed7@oracle.com>
On 4/16/18 10:26 AM, Erik ?sterlund wrote:
> Hi Coleen,
>
> This looks good to me. Thank you for accessorizing OopHandle.
Thank you for the code review and discussions!
Coleen
>
> Thanks,
> /Erik
>
> On 2018-04-13 16:56, coleen.phillimore at oracle.com wrote:
>> Summary: Add RootAccess<> to OopHandle.resolve() in runtime and
>> interpreter code.? Add comments for compiler code for later.
>>
>> For the current GCs this code does not generate additional code.
>> Also, the compiler Access API code is TBD.?? Since oopHandle.hpp
>> erroneously included orderAccess.hpp and atomic.hpp, some include
>> file fixing is also in this change.
>>
>> Tested with mach5 tier1,tier2 on all Oracle platforms.? Also tested
>> compilation on linux-aarch64.? The other non-Oracle platforms weren't
>> changed because they'll never need this.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8200555.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8200555
>>
>> Thanks,
>> Coleen
>
From aph at redhat.com Mon Apr 16 15:26:41 2018
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Apr 2018 16:26:41 +0100
Subject: RFR: 8201597: AArch64: Update relocs for CompiledDirectStaticCall
Message-ID: <05a179dd-b0bc-a537-dace-fd489029a693@redhat.com>
http://cr.openjdk.java.net/~aph/8201597/
We're not updating the relocs for OOPs and metadata in compiled static
stubs. Fixed thusly:
http://cr.openjdk.java.net/~aph/8201597/
Every other target except x86 does the same thing, with similar code.
I'm therefore baffled that this isn't done in shared code; it
certainly could be.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From sgehwolf at redhat.com Mon Apr 16 15:32:36 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 16 Apr 2018 17:32:36 +0200
Subject: Confusing Mercurial history - was: Re: Hotspot segfaulting on
Linux SPARC
In-Reply-To: <a7c616c3-830b-9411-f50e-cf4f4c6ddd27@physik.fu-berlin.de>
References: <a7c616c3-830b-9411-f50e-cf4f4c6ddd27@physik.fu-berlin.de>
Message-ID: <1523892756.4046.40.camel@redhat.com>
On Mon, 2018-04-16 at 17:07 +0200, John Paul Adrian Glaubitz wrote:
> Hi!
>
> I am trying to bisect the segefault I am seeing on linux-sparc.
>
> For this, I am checking out revision 46931 which should be a good one.
>
> However, trying to build this revision shows that the checked out version
> is missing the patches from revision 46667 and 46668, so I have to make
> those changes manually.
>
> Is there any explanation why a checkout from the newer revision 46931
> is missing the changes from the revisions 46667 and 46668? I have
> the impression I am using Mercurial wrong :(.
Those numbers seem to be local revision numbers. These are not unique
across different checkouts. Have you tried using sha's? How to find a
sha for a specific bug?
$ hg log -k <bug>
HTH,
Severin
From glaubitz at physik.fu-berlin.de Mon Apr 16 15:34:57 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 16 Apr 2018 17:34:57 +0200
Subject: Confusing Mercurial history - was: Re: Hotspot segfaulting on
Linux SPARC
In-Reply-To: <1523892756.4046.40.camel@redhat.com>
References: <a7c616c3-830b-9411-f50e-cf4f4c6ddd27@physik.fu-berlin.de>
<1523892756.4046.40.camel@redhat.com>
Message-ID: <8c1fd817-b632-7e17-1c73-ad2dacf5343b@physik.fu-berlin.de>
On 04/16/2018 05:32 PM, Severin Gehwolf wrote:
> Those numbers seem to be local revision numbers. These are not unique
> across different checkouts. Have you tried using sha's? How to find a
> sha for a specific bug?
Yeah, I also tried the SHA for the checkout. I checked out with:
$ hg update 6e1b59330482
which seemed to work:
glaubitz at deb4g:/srv/glaubitz/hs$ hg id -i
6e1b59330482
glaubitz at deb4g:/srv/glaubitz/hs$
But then I still got a build failure which indicated that 46668 is missing.
> $ hg log -k <bug>
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From adinn at redhat.com Mon Apr 16 16:03:30 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 16 Apr 2018 17:03:30 +0100
Subject: RFR: 8201597: AArch64: Update relocs for CompiledDirectStaticCall
In-Reply-To: <05a179dd-b0bc-a537-dace-fd489029a693@redhat.com>
References: <05a179dd-b0bc-a537-dace-fd489029a693@redhat.com>
Message-ID: <d412591d-77fa-456b-1895-2d7625d34b03@redhat.com>
On 16/04/18 16:26, Andrew Haley wrote:
> http://cr.openjdk.java.net/~aph/8201597/
>
> We're not updating the relocs for OOPs and metadata in compiled static
> stubs. Fixed thusly:
>
> http://cr.openjdk.java.net/~aph/8201597/
Code changes look good.
Your webrev doesn't seem to have found a IRA issue yet though.
Also, you appear to have updated the Red Hat copyright but not the
Oracle one. Is that kosher?
> Every other target except x86 does the same thing, with similar code.
> I'm therefore baffled that this isn't done in shared code; it
> certainly could be.
Hmm, yes. All of them with minor differences in irrelevant details just
to keep you on your toes. What larks, eh!
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
From aph at redhat.com Mon Apr 16 16:12:44 2018
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Apr 2018 17:12:44 +0100
Subject: RFR: 8201597: AArch64: Update relocs for CompiledDirectStaticCall
In-Reply-To: <d412591d-77fa-456b-1895-2d7625d34b03@redhat.com>
References: <05a179dd-b0bc-a537-dace-fd489029a693@redhat.com>
<d412591d-77fa-456b-1895-2d7625d34b03@redhat.com>
Message-ID: <006b46d0-ef4a-d51b-40db-8181d743c24f@redhat.com>
On 04/16/2018 05:03 PM, Andrew Dinn wrote:
> On 16/04/18 16:26, Andrew Haley wrote:
>> http://cr.openjdk.java.net/~aph/8201597/
>>
>> We're not updating the relocs for OOPs and metadata in compiled static
>> stubs. Fixed thusly:
>>
>> http://cr.openjdk.java.net/~aph/8201597/
>
> Code changes look good.
>
> Your webrev doesn't seem to have found a IRA issue yet though.
How odd! Fixed.
> Also, you appear to have updated the Red Hat copyright but not the
> Oracle one. Is that kosher?
Yes.
>> Every other target except x86 does the same thing, with similar code.
>> I'm therefore baffled that this isn't done in shared code; it
>> certainly could be.
> Hmm, yes. All of them with minor differences in irrelevant details just
> to keep you on your toes. What larks, eh!
Right. It could all be in the shared code with an "unless x86" flag.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From Ningsheng.Jian at arm.com Mon Apr 16 08:53:01 2018
From: Ningsheng.Jian at arm.com (Ningsheng Jian)
Date: Mon, 16 Apr 2018 08:53:01 +0000
Subject: 8185505: AArch64: Port AOT
In-Reply-To: <b439eaf0-e026-7ff8-e832-3717368027e4@redhat.com>
References: <b439eaf0-e026-7ff8-e832-3717368027e4@redhat.com>
Message-ID: <AM5PR0802MB2449400467C4E4042C3C6A6390B00@AM5PR0802MB2449.eurprd08.prod.outlook.com>
Hi Andrew,
This is great! Some minor comments:
I can see both the jdk patch and Graal PR contain changes of AArch64Assembler.java and AArch64MacroAssembler.java, but the changes looks somewhat different. How will they be synced?
I noticed that in make/hotspot/lib/JvmFeatures.gmk line ~144, there's:
JVM_EXCLUDE_FILES += \
compiledIC_aot_x86_64.cpp
Do you want to add compiledIC_aot_aarch64.cpp to that list?
I also found that _immutable_PIC and its getters/setters are in the INCLUDE_AOT block, but some of their uses are not:
src/hotspot/cpu/aarch64/compiledIC_aarch64.cpp:
61 if (cbuf.immutable_PIC()) {
src/hotspot/share/jvmci/jvmciCodeInstaller.cpp:
594 buffer.set_immutable_PIC(_immutable_pic_compilation);
628 buffer.set_immutable_PIC(_immutable_pic_compilation);
Thanks,
Ningsheng
> -----Original Message-----
> From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On Behalf Of
> Andrew Haley
> Sent: Saturday, April 14, 2018 1:01 AM
> To: hotspot-dev at openjdk.java.net
> Subject: RFR: 8185505: AArch64: Port AOT
>
> http://cr.openjdk.java.net/~aph/8185505-1
>
> The corresponding Graal changes are at
>
> https://github.com/oracle/graal/pull/334/files
>
> I think I've done all the things that reviewers mentioned. There is a clean set
> of test result for JVMCI and AOT. Thank you everyone.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From alexey.ivanov at oracle.com Mon Apr 16 12:59:23 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 16 Apr 2018 13:59:23 +0100
Subject: 8201226 missing JNIEXPORT / JNICALL at some places in function
declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some
places in function declarations/implementations
In-Reply-To: <f6dbd54e78714305b78ecd3a3d232f11@sap.com>
References: <9bae15f406ed4e029233415e6a8032b8@sap.com>
<81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com>
<7c5e68c2a023490e96ce6452fbda1700@sap.com>
<c7f9df33-e9c8-2fcd-f8bd-df7f5a1e2494@oracle.com>
<9fff2e7e-06ac-54c1-8f66-33bff34ea621@oracle.com>
<f6dbd54e78714305b78ecd3a3d232f11@sap.com>
Message-ID: <c93c031a-2527-3d3e-369e-9f6274c2ad3b@oracle.com>
Hi Matthias, Phil,
The build of 32 bit Windows is broken because of mlib_image.dll. As
JNICALL modifier has been added to function declarations, they're
exported with a decorated name, for example _j2d_mlib_ImageCreate at 16.
The functions in this library are looked up by their name [1] and
therefore none can be found.
If you run tests in test/jdk/java/awt/image, for example
test/jdk/java/awt/image/mlib/MlibOpsTest.java, some of them fail because
ImagingLib is not available.
I'm working on a patch to fix it.
Regards,
Alexey
[1]
http://hg.openjdk.java.net/jdk/jdk/file/bc1c7e41e285/src/java.desktop/windows/native/libawt/windows/awt_Mlib.cpp#l60
On 13/04/2018 06:48, Baesken, Matthias wrote:
> Hi Phil/Alexey, thanks for adding the other lists .
>
>> Is this the current version of the change : http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ ?
> Yes.
>
> Best regards, Matthias
>
>
>> -----Original Message-----
>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com]
>> Sent: Donnerstag, 12. April 2018 23:53
>> To: Phil Race <philip.race at oracle.com>; Baesken, Matthias
>> <matthias.baesken at sap.com>; Alan Bateman <Alan.Bateman at oracle.com>;
>> Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
>> Cc: build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Doerr,
>> Martin <martin.doerr at sap.com>; 2d-dev <2d-dev at openjdk.java.net>;
>> hotspot-dev <hotspot-dev at openjdk.java.net>
>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>> some places in function declarations/implementations
>>
>>
>> On 12/04/2018 21:42, Phil Race wrote:
>>> How can JNIEXPORT be different between 32 bit & 64 bit ?
>>> I'm sure you saw compilation errors but I don't get why it failed for
>>> 32 only.
>>>
>>> JNICALL (_stdcall) may be unnecessary on 64 bit Windows but that doesn't
>>> explain why the 32 bit compiler would complain about inconsistent
>>> application
>>> of __declspec(dllexport) - ie JNIEXPORT.
>>>
>>> Or is that part (adding JNIEXPORT) pure clean up and the compilation
>>> errors were all down to JNICALL ?
>> Adding missing JNIEXPORT is for cleanup only.
>>
>> The compiler complained about mismatched JNICALL / non-JNICALL
>> declarations as the macro changes calling convention from the default
>> __cdecl? to __stdcall on 32 bit Windows.
>>
>> Another issue is that __stdcall decorates the functions: prefixes with
>> underscore and postfixes with @ + size of parameters. Because of the
>> decorations, classLoader.cpp can't lookup the required functions by name
>> from zip.dll and jimage.dll. The functions are exported but with
>> different name.
>>
>> I hope this information adds more details to the picture.
>>
>>> I was a bit puzzled at the removals I saw here :
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.deskto
>> p/share/native/libsplashscreen/splashscreen_impl.h.udiff.html
>>> .. I needed to look at the whole file to realise that you were
>>> removing a duplicate
>>> declaration.
>> That was tricky. I could have been mentioned in the review.
>>
>>
>> Regards,
>> Alexey
>>
>>> -phil.
>>>
>>> On 04/12/2018 04:04 AM, Baesken, Matthias wrote:
>>>> Hi? Alan , this is the up to date webrev .
>>>> However we want to add?? Alexey?? Ivanov? as additional? author .
>>>>
>>>>> As I read it, this changes the calling convention of these functions on
>>>>> 32-bit Windows but it will have no impact on 64-bit Windows (as
>>>>> __stdcall is ignored) or other platforms, is that correct?
>>>>>
>>>> The? change adds? JNIEXPORT?? at some places? where it is? ben
>>>> forgotten , for example :
>>>>
>>>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp.c.udiff.html
>>>>
>>>> This might have? potential? impact? on other platforms?? (fixes the
>>>> mismatches) .
>>>>
>>>> Best regards, Matthias
>>>>
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
>>>>> Sent: Donnerstag, 12. April 2018 12:54
>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
>>>>> Cc: build-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>; core-libs-dev at openjdk.java.net
>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>>>>> function
>>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>>>>> some places in function declarations/implementations
>>>>>
>>>>> Adding core-libs-dev as this is change code in libjava, libzip,
>>>>> libjimage, ...
>>>>>
>>>>> Can you confirm that this is the up to date webrev:
>>>>> ???? http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/
>>>>>
>>>>> As I read it, this changes the calling convention of these functions on
>>>>> 32-bit Windows but it will have no impact on 64-bit Windows (as
>>>>> __stdcall is ignored) or other platforms, is that correct?
>>>>>
>>>>> -Alan
>>>>>
>>>>>
>>>>> <SNIP>
From glaubitz at physik.fu-berlin.de Mon Apr 16 18:17:35 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 16 Apr 2018 20:17:35 +0200
Subject: Confusing Mercurial history - was: Re: Hotspot segfaulting on
Linux SPARC
In-Reply-To: <a7c616c3-830b-9411-f50e-cf4f4c6ddd27@physik.fu-berlin.de>
References: <a7c616c3-830b-9411-f50e-cf4f4c6ddd27@physik.fu-berlin.de>
Message-ID: <ee9f2ece-d0f9-a5ae-04be-d2290f9b0ce2@physik.fu-berlin.de>
On 04/16/2018 05:07 PM, John Paul Adrian Glaubitz wrote:
> I am trying to bisect the segefault I am seeing on linux-sparc.
So, I have tried dozens of revisions now and I can't find one that builds fine.
This is becoming really frustrating, especially since the history with Mercurial
seems completely random.
I would normally expect a changeset that was checked in in July to be included
in a revision that was checked in in August. I don't understand how one is supposed
to perform bi-secting with Mercurial if something as basic as a working history
doesn't work in Mercurial.
/frustrated
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From rkennke at redhat.com Mon Apr 16 18:36:28 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Mon, 16 Apr 2018 20:36:28 +0200
Subject: Confusing Mercurial history - was: Re: Hotspot segfaulting on
Linux SPARC
In-Reply-To: <ee9f2ece-d0f9-a5ae-04be-d2290f9b0ce2@physik.fu-berlin.de>
References: <a7c616c3-830b-9411-f50e-cf4f4c6ddd27@physik.fu-berlin.de>
<ee9f2ece-d0f9-a5ae-04be-d2290f9b0ce2@physik.fu-berlin.de>
Message-ID: <aff63590-e2b4-4271-f10c-e026a81c9c7e@redhat.com>
Am 16.04.2018 um 20:17 schrieb John Paul Adrian Glaubitz:
> On 04/16/2018 05:07 PM, John Paul Adrian Glaubitz wrote:
>> I am trying to bisect the segefault I am seeing on linux-sparc.
>
> So, I have tried dozens of revisions now and I can't find one that builds fine.
> This is becoming really frustrating, especially since the history with Mercurial
> seems completely random.
>
> I would normally expect a changeset that was checked in in July to be included
> in a revision that was checked in in August. I don't understand how one is supposed
> to perform bi-secting with Mercurial if something as basic as a working history
> doesn't work in Mercurial.
You're probably wrongly assuming that commit history is linear. It is
not. TBH, I don't really know how hg bisect works with branchy history.
It usually works fairly well in my experience. It will probably get
confused if you start out with two revision on different branches? Or
are you trying to bisect manually?
Here's some information around this stuff:
http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html#sec:undo:bisect
Cheers, Roman
From jcbeyler at google.com Mon Apr 16 20:43:33 2018
From: jcbeyler at google.com (JC Beyler)
Date: Mon, 16 Apr 2018 20:43:33 +0000
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
fast_path_end
In-Reply-To: <ec1a3e0e-ca9b-8668-b260-1fd3e612b7f7@oracle.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
<fca2bf81-0e8d-ffce-8203-080c07afb323@oracle.com>
<3AAB892A-CE21-492C-ABA2-182EF9316F06@oracle.com>
<CAF9BGBz-=JqbaJ37B5G35u3Ziei53fjhf=JMaWFd06WeZUCLfQ@mail.gmail.com>
<CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
<3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>
<CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>
<5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
<CAF9BGBxEPXLTiyD-xG_ECyveyW0PXQL0+-z7jkw3Rv4QrkkszQ@mail.gmail.com>
<ec1a3e0e-ca9b-8668-b260-1fd3e612b7f7@oracle.com>
Message-ID: <CAF9BGBy-LBKCwJHQPdAQ65VRcSFBwVkk9dm8MLC_nrefE_JdEw@mail.gmail.com>
Hi all,
I've left the mail thread from the hotspot-gc-dev below for tracking
purposes but will start a new request here.
- I'm trying to push a renaming of a TLAB field to make my work for JEP-331
<http://openjdk.java.net/jeps/331> easier
- There is an understanding that if JEP-331 does not make it, this might
be useless and I'll revert if that is what the community wants; however the
new name seems better anyway so perhaps not?
- The webrev renames a field used across the various back-ends and Graal
- The webrev is here:
http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.04/
Could I please get some feedback on this?
Thanks all for your help,
Jc
On Fri, Apr 13, 2018 at 2:37 AM Stefan Johansson <
stefan.johansson at oracle.com> wrote:
> Hi JC,
>
> I don't have a name, but I've looked at bit more at the failures and I
> think they are unrelated and one of the local compiler engineers agree.
>
> I also ran some local testing and was not able to get any error with you
> latest changes, but verified that it doens't work without the graal
> parts. So they seem good. It might still be good to switch this over to
> the general hotspot-dev list to let someone with Graal knowledge to look
> at the change and make sure everything is correct.
>
> Thanks,
> Stefan
>
>
> On 2018-04-12 17:26, JC Beyler wrote:
> > Hi Stefan,
> >
> > Thanks for testing :). I've renamed the bug title in the JBS and will
> > emit a new webrev shortly. Do you have the name of a compiler engineer
> > in mind or should I perhaps now move this conversation to the general
> > hotspot-dev mailing list and ask there?
> >
> > The alternative is to add the compiler-mailing list to this email thread
> > and ask there before sending to the general list. What do you think is
> best?
> >
> > Thanks for all your help,
> > Jc
> >
> > On Thu, Apr 12, 2018 at 2:09 AM Stefan Johansson
> > <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>>
> wrote:
> >
> >
> >
> > On 2018-04-11 17:48, JC Beyler wrote:
> > > Hi Stefan,
> > >
> > > Sorry about that, I must have missed adding the files or
> > something. Here
> > > is a webrev that added the changes for the SA file:
> > > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/
> > >
> > No problem, this looks good. I kicked of a run in our test system to
> > get
> > some more coverage and have tried to include some Graal testing. I'll
> > let you know the results once they are done.
> >
> > Please also update the bug title both in JBS and the changeset.
> >
> > Cheers,
> > Stefan
> >
> > > I changed the method name, which propagated a change to:
> > >
> >
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
> > >
> > > I tried testing your test file. It exists in my branch (if the
> > same) under:
> > > hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
> > >
> > > and interestingly (which generally means I did something wrong),
> it
> > > passed before/after the change so I could not verify that this is
> > a test
> > > showing that all is well in the world on my side. Any ideas of
> > what I
> > > did wrong?
> > >
> > > I did again test it for hotspot/jtreg/compiler/aot/ and
> > > hotspot/jtreg/serviceability/jvmti and it passes those.
> > >
> > > Thanks for all your help,
> > > Jc
> > >
> > >
> > >
> > > On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson
> > > <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>
> > <mailto:stefan.johansson at oracle.com
> > <mailto:stefan.johansson at oracle.com>>> wrote:
> > >
> > > Hi JC,
> > >
> > > On 2018-04-11 00:56, JC Beyler wrote:
> > > > Small update:
> > > >
> > > > Here is the fixed webrev for the '{' that were out of
> > alignment.
> > > This
> > > > passed release build JTREG
> > for hotspot/jtreg/compiler/jvmti (just
> > > to run
> > > > something as a smoke screen)
> > and hotspot/jtreg/compiler/aot/ (to
> > > test
> > > > Graal).
> > > > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
> > > >
> > > I think this looks better, I agree that leaving _end is
> > tempting to
> > > avoid a lot of change, but I think this will be better in the
> > long run.
> > >
> > > I still miss the changes to make the SA work. To see a
> > problem you
> > > can run:
> > > make CONF=fast run-test
> > > TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
> > >
> > > Cheers,
> > > Stefan
> > >
> > > > Let me know what you think,
> > > > Jc
> > > >
> > > > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler
> > <jcbeyler at google.com <mailto:jcbeyler at google.com>
> > > <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>
> > > > <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>
> > <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>>> wrote:
> > > >
> > > > Hi Karen and Stefan,
> > > >
> > > > @Stefan: Naming is hard :)
> > > > @Karen: thanks for the Graal comment, I fixed it in
> > the new
> > > webrev,
> > > > let me know what you think :)
> > > >
> > > > I think the naming convention suggested in this webrev
> > came from
> > > > conversations in for JEP-331 and I am actually
> relatively
> > > > indifferent to the final result (as long as we have
> > some form of
> > > > forward progress :)). To be honest, I'd also be happy
> > to just
> > > leave
> > > > _end as is for all architectures and Graal and have a
> new
> > > > _allocation_end. However, during initial reviews of
> > JEP-331
> > > it was
> > > > deemed complicated to understand:
> > > >
> > > > _end -> the _end or sampling end
> > > > _allocation_end -> end pointer for the last possible
> > allocation
> > > > hard_end -> allocation end + reserved space
> > > >
> > > > That is how this naming came up and why hard_end went
> to
> > > "reserved_end".
> > > >
> > > > I'm really indifferent, so I offer as a perusal:
> > > > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
> > > >
> > > > I noticed a few problems of alignement of '{' so I'll
> > go fix
> > > that.
> > > > Basically this webrev does the following:
> > > >
> > > > - Uses fast_path_end instead of end
> > > > - Reverts hard_end back to where it was
> > > > - Adds the changes to Graal; there is a bunch of
> > changes in Graal
> > > > because Graal still contains a bit of code doing
> > fasttlabrefills.
> > > >
> > > > Let me know what you think!
> > > >
> > > > Thanks,
> > > > Jc
> > > >
> > > >
> > > > On Tue, Apr 10, 2018 at 6:56 AM Karen Kinnear
> > > > <karen.kinnear at oracle.com
> > <mailto:karen.kinnear at oracle.com> <mailto:karen.kinnear at oracle.com
> > <mailto:karen.kinnear at oracle.com>>
> > > <mailto:karen.kinnear at oracle.com
> > <mailto:karen.kinnear at oracle.com> <mailto:karen.kinnear at oracle.com
> > <mailto:karen.kinnear at oracle.com>>>>
> > > wrote:
> > > >
> > > > Hi JC,
> > > >
> > > > A comment about Graal. The impact on Graal for this
> > > particular
> > > > change would be to break it - so you?ll need
> > > > to complete the Graal changes for this renaming.
> > That isn?t
> > > > optional or something that could be a follow-on. It
> > > > is not ok to break a feature, even an experimental
> > one.
> > > We will
> > > > discuss in the other thread potential phasing of
> > adding
> > > sampling.
> > > >
> > > > I did not do a thorough search -you can do that -
> > I did find
> > > > src/jdk.internal.vm.compiler/share/classes/
> > > >
> > >
> >
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> > > > public final int threadTlabOffset =
> > > > getFieldOffset("Thread::_tlab", Integer.class,
> > > > "ThreadLocalAllocBuffer");
> > > >
> > >
> >
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> > > > private final int
> > threadLocalAllocBufferStartOffset =
> > > > getFieldOffset("ThreadLocalAllocBuffer::_start",
> > > Integer.class,
> > > > "HeapWord*");
> > > >
> > >
> >
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> > > > private final int
> threadLocalAllocBufferEndOffset =
> > > > getFieldOffset("ThreadLocalAllocBuffer::_end",
> > Integer.class,
> > > > "HeapWord*");
> > > >
> > >
> >
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> > > > private final int
> threadLocalAllocBufferTopOffset =
> > > > getFieldOffset("ThreadLocalAllocBuffer::_top",
> > Integer.class,
> > > > "HeapWord*");
> > > >
> > >
> >
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> > > > private final int
> > threadLocalAllocBufferPfTopOffset =
> > > > getFieldOffset("ThreadLocalAllocBuffer::_pf_top",
> > > Integer.class,
> > > > "HeapWord*");
> > > >
> > >
> >
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> > > > private final int
> > > threadLocalAllocBufferSlowAllocationsOffset
> > > > =
> > getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
> > > > Integer.class, "unsigned");
> > > >
> > >
> >
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> > > > private final int
> > > threadLocalAllocBufferFastRefillWasteOffset
> > > > =
> > > getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
> > > > Integer.class, "unsigned");
> > > >
> > >
> >
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> > > > private final int
> > > threadLocalAllocBufferNumberOfRefillsOffset
> > > > =
> > > getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
> > > > Integer.class, "unsigned");
> > > >
> > >
> >
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> > > > private final int
> > > > threadLocalAllocBufferRefillWasteLimitOffset =
> > > >
> > getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
> > > > Integer.class, "size_t");
> > > >
> > >
> >
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> > > > private final int
> > > threadLocalAllocBufferDesiredSizeOffset =
> > > >
> > getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
> > > > Integer.class, "size_t");
> > > >
> > >
> >
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> > > > public final int tlabAlignmentReserve =
> > > >
> > >
> >
> getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
> > > > Integer.class, "size_t?);
> > > >
> > > > hope this helps,
> > > > Karen
> > > >
> > > >> On Apr 10, 2018, at 7:04 AM, Stefan Johansson
> > > >> <stefan.johansson at oracle.com
> > <mailto:stefan.johansson at oracle.com>
> > > <mailto:stefan.johansson at oracle.com
> > <mailto:stefan.johansson at oracle.com>>
> > > >> <mailto:stefan.johansson at oracle.com
> > <mailto:stefan.johansson at oracle.com>
> > > <mailto:stefan.johansson at oracle.com
> > <mailto:stefan.johansson at oracle.com>>>> wrote:
> > > >>
> > > >> Hi JC,
> > > >>
> > > >> I realize that the names have been discussed
> > before but I'm
> > > >> leaning towards suggesting something new. We
> > discussed this
> > > >> briefly here in the office and others might have
> > different
> > > >> opinions. One point that came up is that if we do
> > this
> > > change
> > > >> and change all usages of
> > JavaThread::tlab_end_offset() it
> > > >> would be good to make sure the new name is good.
> > To us
> > > >> _current_end is not very descriptive, but naming
> > is hard and
> > > >> the best we could come up with is _fast_path_end
> > which would
> > > >> give the code:
> > > >> cmpptr(end, Address(thread,
> > > >> JavaThread::tlab_fast_path_end_offset()));
> > > >> jcc(Assembler::above, slow_case);
> > > >>
> > > >> I think this reads pretty good and is fairly
> > clear. If we do
> > > >> this rename I think you can re-use _end in JEP-331
> > > instead of
> > > >> calling it _allocation_end. But that is a later
> > review :)
> > > >>
> > > >> Also, is there a good reason for renaming
> > hard_end() to
> > > >> reserved_end()?
> > > >>
> > > >> One additional thing, you need to update the SA
> > to reflect
> > > >> this change. I think the only place you need to
> > fix is in:
> > > >>
> > >
> >
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
> > > >>
> > > >> Thanks,
> > > >> Stefan
> > > >>
> > > >> On 2018-04-09 19:24, JC Beyler wrote:
> > > >>> Hi all,
> > > >>> Small pre-amble to this request:
> > > >>> In my work to try to get a heap sampler in
> > OpenJDK (via JEP
> > > >>> 331
> > > <https://bugs.openjdk.java.net/browse/JDK-8171119>), I'm
> > > >>> trying to reduce the footprint of my change so
> > that the
> > > >>> integration can be easier. I was told that
> > generally a JEP
> > > >>> webrev should be feature complete and go in
> at-once.
> > > However,
> > > >>> with the change touching quite a bit of various
> code
> > > pieces,
> > > >>> I was trying to figure out what could be
> > separated as not
> > > >>> "part of the feature".
> > > >>> I asked around and said that perhaps a solution
> > would be to
> > > >>> cut up the renaming of TLAB's end field that I
> > do in that
> > > >>> webrev. Because I'm renaming a field in TLAB
> used by
> > > various
> > > >>> backends for that work, I have to update every
> > architecture
> > > >>> dependent code to reflect it.
> > > >>> I entirely understand that perhaps this is not
> > in the
> > > habits
> > > >>> and very potentially might not be the way things
> are
> > > >>> generally done. If so, I apologize and let me
> > know if you
> > > >>> would not want this to go in separately :)
> > > >>> Final note: there is still a chance JEP-331 does
> > not go in.
> > > >>> If it does not, we can leave the new name in
> > place or I'll
> > > >>> happily revert it. I can even create an issue to
> > track this
> > > >>> if that makes it easier for all.
> > > >>> End of the pre-amble.
> > > >>> The 33-line change webrev in question is here:
> > > >>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
> > > >>> I fixed all the architectures and JVMCI and ran
> > a few
> > > sanity
> > > >>> tests to ensure I had not missed anything.
> > > >>> Thanks for your help and I hope this is not too
> much
> > > trouble,
> > > >>> Jc
> > > >>> Ps: there is a graal change that needs to happen
> > but I was
> > > >>> not sure who/where
> <https://teams.googleplex.com/u/where>
> > <https://teams.googleplex.com/u/where>
> > > <https://teams.googleplex.com/u/where>
> > > <https://teams.googleplex.com/u/where> to
> > > >>> ask about it. I was told it could happen in a
> > separate
> > > >>> webrev. Can anyone point me to the right
> direction?
> > > Should it
> > > >>> just be hotspot-compiler-dev?
> > > >
> > >
> >
>
From dean.long at oracle.com Mon Apr 16 22:29:11 2018
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Mon, 16 Apr 2018 15:29:11 -0700
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
fast_path_end
In-Reply-To: <CAF9BGBy-LBKCwJHQPdAQ65VRcSFBwVkk9dm8MLC_nrefE_JdEw@mail.gmail.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
<fca2bf81-0e8d-ffce-8203-080c07afb323@oracle.com>
<3AAB892A-CE21-492C-ABA2-182EF9316F06@oracle.com>
<CAF9BGBz-=JqbaJ37B5G35u3Ziei53fjhf=JMaWFd06WeZUCLfQ@mail.gmail.com>
<CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
<3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>
<CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>
<5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
<CAF9BGBxEPXLTiyD-xG_ECyveyW0PXQL0+-z7jkw3Rv4QrkkszQ@mail.gmail.com>
<ec1a3e0e-ca9b-8668-b260-1fd3e612b7f7@oracle.com>
<CAF9BGBy-LBKCwJHQPdAQ65VRcSFBwVkk9dm8MLC_nrefE_JdEw@mail.gmail.com>
Message-ID: <e6528c19-5691-1215-1ac5-0349801b79b5@oracle.com>
Hi JC.? Others might disagree, but I would vote "no" on doing this
renaming now, before the JEP, and even in the context of the JEP, I
don't think renaming the field requires renaming all the uses.? The
compiler code is only interested in the fast path, so it's implicitly
understood.? Also, if there is a fast_path_end(), then isn't it logical
to have fast_path_start() paired with it?? ("start" is already
overloaded, but nobody is suggesting adding
allocation_start()/current_start()/hard_start() are they?).? My opinion
is that it's fine the way it is.
dl
On 4/16/18 1:43 PM, JC Beyler wrote:
> Hi all,
>
> I've left the mail thread from the hotspot-gc-dev below for tracking
> purposes but will start a new request here.
>
> - I'm trying to push a renaming of a TLAB field to make my work for JEP-331
> <http://openjdk.java.net/jeps/331> easier
> - There is an understanding that if JEP-331 does not make it, this might
> be useless and I'll revert if that is what the community wants; however the
> new name seems better anyway so perhaps not?
>
> - The webrev renames a field used across the various back-ends and Graal
> - The webrev is here:
> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.04/
>
> Could I please get some feedback on this?
>
> Thanks all for your help,
> Jc
>
>
>
> On Fri, Apr 13, 2018 at 2:37 AM Stefan Johansson <
> stefan.johansson at oracle.com> wrote:
>
>> Hi JC,
>>
>> I don't have a name, but I've looked at bit more at the failures and I
>> think they are unrelated and one of the local compiler engineers agree.
>>
>> I also ran some local testing and was not able to get any error with you
>> latest changes, but verified that it doens't work without the graal
>> parts. So they seem good. It might still be good to switch this over to
>> the general hotspot-dev list to let someone with Graal knowledge to look
>> at the change and make sure everything is correct.
>>
>> Thanks,
>> Stefan
>>
>>
>> On 2018-04-12 17:26, JC Beyler wrote:
>>> Hi Stefan,
>>>
>>> Thanks for testing :). I've renamed the bug title in the JBS and will
>>> emit a new webrev shortly. Do you have the name of a compiler engineer
>>> in mind or should I perhaps now move this conversation to the general
>>> hotspot-dev mailing list and ask there?
>>>
>>> The alternative is to add the compiler-mailing list to this email thread
>>> and ask there before sending to the general list. What do you think is
>> best?
>>> Thanks for all your help,
>>> Jc
>>>
>>> On Thu, Apr 12, 2018 at 2:09 AM Stefan Johansson
>>> <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>>
>> wrote:
>>>
>>>
>>> On 2018-04-11 17:48, JC Beyler wrote:
>>> > Hi Stefan,
>>> >
>>> > Sorry about that, I must have missed adding the files or
>>> something. Here
>>> > is a webrev that added the changes for the SA file:
>>> > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/
>>> >
>>> No problem, this looks good. I kicked of a run in our test system to
>>> get
>>> some more coverage and have tried to include some Graal testing. I'll
>>> let you know the results once they are done.
>>>
>>> Please also update the bug title both in JBS and the changeset.
>>>
>>> Cheers,
>>> Stefan
>>>
>>> > I changed the method name, which propagated a change to:
>>> >
>>>
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
>>> >
>>> > I tried testing your test file. It exists in my branch (if the
>>> same) under:
>>> > hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
>>> >
>>> > and interestingly (which generally means I did something wrong),
>> it
>>> > passed before/after the change so I could not verify that this is
>>> a test
>>> > showing that all is well in the world on my side. Any ideas of
>>> what I
>>> > did wrong?
>>> >
>>> > I did again test it for hotspot/jtreg/compiler/aot/ and
>>> > hotspot/jtreg/serviceability/jvmti and it passes those.
>>> >
>>> > Thanks for all your help,
>>> > Jc
>>> >
>>> >
>>> >
>>> > On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson
>>> > <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>
>>> <mailto:stefan.johansson at oracle.com
>>> <mailto:stefan.johansson at oracle.com>>> wrote:
>>> >
>>> > Hi JC,
>>> >
>>> > On 2018-04-11 00:56, JC Beyler wrote:
>>> > > Small update:
>>> > >
>>> > > Here is the fixed webrev for the '{' that were out of
>>> alignment.
>>> > This
>>> > > passed release build JTREG
>>> for hotspot/jtreg/compiler/jvmti (just
>>> > to run
>>> > > something as a smoke screen)
>>> and hotspot/jtreg/compiler/aot/ (to
>>> > test
>>> > > Graal).
>>> > > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
>>> > >
>>> > I think this looks better, I agree that leaving _end is
>>> tempting to
>>> > avoid a lot of change, but I think this will be better in the
>>> long run.
>>> >
>>> > I still miss the changes to make the SA work. To see a
>>> problem you
>>> > can run:
>>> > make CONF=fast run-test
>>> > TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
>>> >
>>> > Cheers,
>>> > Stefan
>>> >
>>> > > Let me know what you think,
>>> > > Jc
>>> > >
>>> > > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler
>>> <jcbeyler at google.com <mailto:jcbeyler at google.com>
>>> > <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>
>>> > > <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>
>>> <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>>> wrote:
>>> > >
>>> > > Hi Karen and Stefan,
>>> > >
>>> > > @Stefan: Naming is hard :)
>>> > > @Karen: thanks for the Graal comment, I fixed it in
>>> the new
>>> > webrev,
>>> > > let me know what you think :)
>>> > >
>>> > > I think the naming convention suggested in this webrev
>>> came from
>>> > > conversations in for JEP-331 and I am actually
>> relatively
>>> > > indifferent to the final result (as long as we have
>>> some form of
>>> > > forward progress :)). To be honest, I'd also be happy
>>> to just
>>> > leave
>>> > > _end as is for all architectures and Graal and have a
>> new
>>> > > _allocation_end. However, during initial reviews of
>>> JEP-331
>>> > it was
>>> > > deemed complicated to understand:
>>> > >
>>> > > _end -> the _end or sampling end
>>> > > _allocation_end -> end pointer for the last possible
>>> allocation
>>> > > hard_end -> allocation end + reserved space
>>> > >
>>> > > That is how this naming came up and why hard_end went
>> to
>>> > "reserved_end".
>>> > >
>>> > > I'm really indifferent, so I offer as a perusal:
>>> > > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
>>> > >
>>> > > I noticed a few problems of alignement of '{' so I'll
>>> go fix
>>> > that.
>>> > > Basically this webrev does the following:
>>> > >
>>> > > - Uses fast_path_end instead of end
>>> > > - Reverts hard_end back to where it was
>>> > > - Adds the changes to Graal; there is a bunch of
>>> changes in Graal
>>> > > because Graal still contains a bit of code doing
>>> fasttlabrefills.
>>> > >
>>> > > Let me know what you think!
>>> > >
>>> > > Thanks,
>>> > > Jc
>>> > >
>>> > >
>>> > > On Tue, Apr 10, 2018 at 6:56 AM Karen Kinnear
>>> > > <karen.kinnear at oracle.com
>>> <mailto:karen.kinnear at oracle.com> <mailto:karen.kinnear at oracle.com
>>> <mailto:karen.kinnear at oracle.com>>
>>> > <mailto:karen.kinnear at oracle.com
>>> <mailto:karen.kinnear at oracle.com> <mailto:karen.kinnear at oracle.com
>>> <mailto:karen.kinnear at oracle.com>>>>
>>> > wrote:
>>> > >
>>> > > Hi JC,
>>> > >
>>> > > A comment about Graal. The impact on Graal for this
>>> > particular
>>> > > change would be to break it - so you?ll need
>>> > > to complete the Graal changes for this renaming.
>>> That isn?t
>>> > > optional or something that could be a follow-on. It
>>> > > is not ok to break a feature, even an experimental
>>> one.
>>> > We will
>>> > > discuss in the other thread potential phasing of
>>> adding
>>> > sampling.
>>> > >
>>> > > I did not do a thorough search -you can do that -
>>> I did find
>>> > > src/jdk.internal.vm.compiler/share/classes/
>>> > >
>>> >
>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> > > public final int threadTlabOffset =
>>> > > getFieldOffset("Thread::_tlab", Integer.class,
>>> > > "ThreadLocalAllocBuffer");
>>> > >
>>> >
>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> > > private final int
>>> threadLocalAllocBufferStartOffset =
>>> > > getFieldOffset("ThreadLocalAllocBuffer::_start",
>>> > Integer.class,
>>> > > "HeapWord*");
>>> > >
>>> >
>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> > > private final int
>> threadLocalAllocBufferEndOffset =
>>> > > getFieldOffset("ThreadLocalAllocBuffer::_end",
>>> Integer.class,
>>> > > "HeapWord*");
>>> > >
>>> >
>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> > > private final int
>> threadLocalAllocBufferTopOffset =
>>> > > getFieldOffset("ThreadLocalAllocBuffer::_top",
>>> Integer.class,
>>> > > "HeapWord*");
>>> > >
>>> >
>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> > > private final int
>>> threadLocalAllocBufferPfTopOffset =
>>> > > getFieldOffset("ThreadLocalAllocBuffer::_pf_top",
>>> > Integer.class,
>>> > > "HeapWord*");
>>> > >
>>> >
>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> > > private final int
>>> > threadLocalAllocBufferSlowAllocationsOffset
>>> > > =
>>> getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
>>> > > Integer.class, "unsigned");
>>> > >
>>> >
>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> > > private final int
>>> > threadLocalAllocBufferFastRefillWasteOffset
>>> > > =
>>> > getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
>>> > > Integer.class, "unsigned");
>>> > >
>>> >
>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> > > private final int
>>> > threadLocalAllocBufferNumberOfRefillsOffset
>>> > > =
>>> > getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
>>> > > Integer.class, "unsigned");
>>> > >
>>> >
>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> > > private final int
>>> > > threadLocalAllocBufferRefillWasteLimitOffset =
>>> > >
>>> getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
>>> > > Integer.class, "size_t");
>>> > >
>>> >
>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> > > private final int
>>> > threadLocalAllocBufferDesiredSizeOffset =
>>> > >
>>> getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
>>> > > Integer.class, "size_t");
>>> > >
>>> >
>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> > > public final int tlabAlignmentReserve =
>>> > >
>>> >
>>>
>> getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
>>> > > Integer.class, "size_t?);
>>> > >
>>> > > hope this helps,
>>> > > Karen
>>> > >
>>> > >> On Apr 10, 2018, at 7:04 AM, Stefan Johansson
>>> > >> <stefan.johansson at oracle.com
>>> <mailto:stefan.johansson at oracle.com>
>>> > <mailto:stefan.johansson at oracle.com
>>> <mailto:stefan.johansson at oracle.com>>
>>> > >> <mailto:stefan.johansson at oracle.com
>>> <mailto:stefan.johansson at oracle.com>
>>> > <mailto:stefan.johansson at oracle.com
>>> <mailto:stefan.johansson at oracle.com>>>> wrote:
>>> > >>
>>> > >> Hi JC,
>>> > >>
>>> > >> I realize that the names have been discussed
>>> before but I'm
>>> > >> leaning towards suggesting something new. We
>>> discussed this
>>> > >> briefly here in the office and others might have
>>> different
>>> > >> opinions. One point that came up is that if we do
>>> this
>>> > change
>>> > >> and change all usages of
>>> JavaThread::tlab_end_offset() it
>>> > >> would be good to make sure the new name is good.
>>> To us
>>> > >> _current_end is not very descriptive, but naming
>>> is hard and
>>> > >> the best we could come up with is _fast_path_end
>>> which would
>>> > >> give the code:
>>> > >> cmpptr(end, Address(thread,
>>> > >> JavaThread::tlab_fast_path_end_offset()));
>>> > >> jcc(Assembler::above, slow_case);
>>> > >>
>>> > >> I think this reads pretty good and is fairly
>>> clear. If we do
>>> > >> this rename I think you can re-use _end in JEP-331
>>> > instead of
>>> > >> calling it _allocation_end. But that is a later
>>> review :)
>>> > >>
>>> > >> Also, is there a good reason for renaming
>>> hard_end() to
>>> > >> reserved_end()?
>>> > >>
>>> > >> One additional thing, you need to update the SA
>>> to reflect
>>> > >> this change. I think the only place you need to
>>> fix is in:
>>> > >>
>>> >
>>>
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
>>> > >>
>>> > >> Thanks,
>>> > >> Stefan
>>> > >>
>>> > >> On 2018-04-09 19:24, JC Beyler wrote:
>>> > >>> Hi all,
>>> > >>> Small pre-amble to this request:
>>> > >>> In my work to try to get a heap sampler in
>>> OpenJDK (via JEP
>>> > >>> 331
>>> > <https://bugs.openjdk.java.net/browse/JDK-8171119>), I'm
>>> > >>> trying to reduce the footprint of my change so
>>> that the
>>> > >>> integration can be easier. I was told that
>>> generally a JEP
>>> > >>> webrev should be feature complete and go in
>> at-once.
>>> > However,
>>> > >>> with the change touching quite a bit of various
>> code
>>> > pieces,
>>> > >>> I was trying to figure out what could be
>>> separated as not
>>> > >>> "part of the feature".
>>> > >>> I asked around and said that perhaps a solution
>>> would be to
>>> > >>> cut up the renaming of TLAB's end field that I
>>> do in that
>>> > >>> webrev. Because I'm renaming a field in TLAB
>> used by
>>> > various
>>> > >>> backends for that work, I have to update every
>>> architecture
>>> > >>> dependent code to reflect it.
>>> > >>> I entirely understand that perhaps this is not
>>> in the
>>> > habits
>>> > >>> and very potentially might not be the way things
>> are
>>> > >>> generally done. If so, I apologize and let me
>>> know if you
>>> > >>> would not want this to go in separately :)
>>> > >>> Final note: there is still a chance JEP-331 does
>>> not go in.
>>> > >>> If it does not, we can leave the new name in
>>> place or I'll
>>> > >>> happily revert it. I can even create an issue to
>>> track this
>>> > >>> if that makes it easier for all.
>>> > >>> End of the pre-amble.
>>> > >>> The 33-line change webrev in question is here:
>>> > >>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
>>> > >>> I fixed all the architectures and JVMCI and ran
>>> a few
>>> > sanity
>>> > >>> tests to ensure I had not missed anything.
>>> > >>> Thanks for your help and I hope this is not too
>> much
>>> > trouble,
>>> > >>> Jc
>>> > >>> Ps: there is a graal change that needs to happen
>>> but I was
>>> > >>> not sure who/where
>> <https://teams.googleplex.com/u/where>
>>> <https://teams.googleplex.com/u/where>
>>> > <https://teams.googleplex.com/u/where>
>>> > <https://teams.googleplex.com/u/where> to
>>> > >>> ask about it. I was told it could happen in a
>>> separate
>>> > >>> webrev. Can anyone point me to the right
>> direction?
>>> > Should it
>>> > >>> just be hotspot-compiler-dev?
>>> > >
>>> >
>>>
From jcbeyler at google.com Mon Apr 16 23:42:38 2018
From: jcbeyler at google.com (JC Beyler)
Date: Mon, 16 Apr 2018 23:42:38 +0000
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
fast_path_end
In-Reply-To: <e6528c19-5691-1215-1ac5-0349801b79b5@oracle.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
<fca2bf81-0e8d-ffce-8203-080c07afb323@oracle.com>
<3AAB892A-CE21-492C-ABA2-182EF9316F06@oracle.com>
<CAF9BGBz-=JqbaJ37B5G35u3Ziei53fjhf=JMaWFd06WeZUCLfQ@mail.gmail.com>
<CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
<3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>
<CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>
<5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
<CAF9BGBxEPXLTiyD-xG_ECyveyW0PXQL0+-z7jkw3Rv4QrkkszQ@mail.gmail.com>
<ec1a3e0e-ca9b-8668-b260-1fd3e612b7f7@oracle.com>
<CAF9BGBy-LBKCwJHQPdAQ65VRcSFBwVkk9dm8MLC_nrefE_JdEw@mail.gmail.com>
<e6528c19-5691-1215-1ac5-0349801b79b5@oracle.com>
Message-ID: <CAF9BGBwBgyOoJTfJU_YmqYJgSZ+1985yx_sSMJC4wNJELw1XDQ@mail.gmail.com>
Hi Dean,
I think perhaps this is also an attempt to figure out the naming of all
this because naming (or renaming like here) is often the start of big
conversations :).
Originally, in the JEP-331 work, I had left the _end field as is and, by
doing so, this whole renaming webrev goes away. However, if we do that,
then the TLAB code contains:
_end: the fast path end, can be the allocation end or the to-be-sampled end
_allocation_end: the actual allocation end of the current TLAB
hard_end: _allocation_end + reserved space
With an early iteration of a webrev for JEP-331, a conversation occurred
about whether or not that was clear or not and it was determined that this
renaming was more clear:
_current_end: the fast path end
_allocation_end: the actual allocation end of the current TLAB
reserved_end: _allocation_end + reserved space
Because I'm trying to reduce the footprint of files changed, I pulled out
the renaming changes into this webrev. While talking about it with the GC
team, the renaming suggested became:
_fast_path_end: the fast path end
_allocation_end: the actual allocation end of the current TLAB
hard_end: _allocation_end + reserved space
Now, to be honest, any renaming or no renaming is fine by me. I like not
renaming the fields to not change the code of every backend and Graal; I
also like the fast_path_end rename due to it making the backend code easy
to read as mentioned in the GC mailing lis thread.
So there are two questions really:
- Should we rename the _end field and thus provoke the changes in this
webrev?
- If we do want to change the field, should/could it go in an initial
webrev or should it go in the JEP-331 webrev whenever/ifever it goes in?
And if we do wait, could we at least converge on a renaming now so that
this does not become a point of contention for that webrev's review?
If I read your answer correctly:
- You are saying that we should keep the _end field altogether; or at
least only rename the field not the methods to access it, thus reducing the
change scope.
- You are also saying to wait for the JEP-331 webrev's final iteration
and integrate it in one step
Have I understood your answer correctly?
Again, I am fine with renaming to whatever or not renaming at all. I just
am trying to get forward progress here :)
Thanks for your help!
Jc
On Mon, Apr 16, 2018 at 3:29 PM <dean.long at oracle.com> wrote:
> Hi JC. Others might disagree, but I would vote "no" on doing this
> renaming now, before the JEP, and even in the context of the JEP, I
> don't think renaming the field requires renaming all the uses. The
> compiler code is only interested in the fast path, so it's implicitly
> understood. Also, if there is a fast_path_end(), then isn't it logical
> to have fast_path_start() paired with it? ("start" is already
> overloaded, but nobody is suggesting adding
> allocation_start()/current_start()/hard_start() are they?). My opinion
> is that it's fine the way it is.
>
> dl
>
> On 4/16/18 1:43 PM, JC Beyler wrote:
> > Hi all,
> >
> > I've left the mail thread from the hotspot-gc-dev below for tracking
> > purposes but will start a new request here.
> >
> > - I'm trying to push a renaming of a TLAB field to make my work for
> JEP-331
> > <http://openjdk.java.net/jeps/331> easier
> > - There is an understanding that if JEP-331 does not make it, this
> might
> > be useless and I'll revert if that is what the community wants; however
> the
> > new name seems better anyway so perhaps not?
> >
> > - The webrev renames a field used across the various back-ends and Graal
> > - The webrev is here:
> > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.04/
> >
> > Could I please get some feedback on this?
> >
> > Thanks all for your help,
> > Jc
> >
> >
> >
> > On Fri, Apr 13, 2018 at 2:37 AM Stefan Johansson <
> > stefan.johansson at oracle.com> wrote:
> >
> >> Hi JC,
> >>
> >> I don't have a name, but I've looked at bit more at the failures and I
> >> think they are unrelated and one of the local compiler engineers agree.
> >>
> >> I also ran some local testing and was not able to get any error with you
> >> latest changes, but verified that it doens't work without the graal
> >> parts. So they seem good. It might still be good to switch this over to
> >> the general hotspot-dev list to let someone with Graal knowledge to look
> >> at the change and make sure everything is correct.
> >>
> >> Thanks,
> >> Stefan
> >>
> >>
> >> On 2018-04-12 17:26, JC Beyler wrote:
> >>> Hi Stefan,
> >>>
> >>> Thanks for testing :). I've renamed the bug title in the JBS and will
> >>> emit a new webrev shortly. Do you have the name of a compiler engineer
> >>> in mind or should I perhaps now move this conversation to the general
> >>> hotspot-dev mailing list and ask there?
> >>>
> >>> The alternative is to add the compiler-mailing list to this email
> thread
> >>> and ask there before sending to the general list. What do you think is
> >> best?
> >>> Thanks for all your help,
> >>> Jc
> >>>
> >>> On Thu, Apr 12, 2018 at 2:09 AM Stefan Johansson
> >>> <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>>
> >> wrote:
> >>>
> >>>
> >>> On 2018-04-11 17:48, JC Beyler wrote:
> >>> > Hi Stefan,
> >>> >
> >>> > Sorry about that, I must have missed adding the files or
> >>> something. Here
> >>> > is a webrev that added the changes for the SA file:
> >>> > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/
> >>> >
> >>> No problem, this looks good. I kicked of a run in our test system
> to
> >>> get
> >>> some more coverage and have tried to include some Graal testing.
> I'll
> >>> let you know the results once they are done.
> >>>
> >>> Please also update the bug title both in JBS and the changeset.
> >>>
> >>> Cheers,
> >>> Stefan
> >>>
> >>> > I changed the method name, which propagated a change to:
> >>> >
> >>>
> >>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
> >>> >
> >>> > I tried testing your test file. It exists in my branch (if the
> >>> same) under:
> >>> > hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
> >>> >
> >>> > and interestingly (which generally means I did something
> wrong),
> >> it
> >>> > passed before/after the change so I could not verify that this
> is
> >>> a test
> >>> > showing that all is well in the world on my side. Any ideas of
> >>> what I
> >>> > did wrong?
> >>> >
> >>> > I did again test it for hotspot/jtreg/compiler/aot/ and
> >>> > hotspot/jtreg/serviceability/jvmti and it passes those.
> >>> >
> >>> > Thanks for all your help,
> >>> > Jc
> >>> >
> >>> >
> >>> >
> >>> > On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson
> >>> > <stefan.johansson at oracle.com <mailto:
> stefan.johansson at oracle.com>
> >>> <mailto:stefan.johansson at oracle.com
> >>> <mailto:stefan.johansson at oracle.com>>> wrote:
> >>> >
> >>> > Hi JC,
> >>> >
> >>> > On 2018-04-11 00:56, JC Beyler wrote:
> >>> > > Small update:
> >>> > >
> >>> > > Here is the fixed webrev for the '{' that were out of
> >>> alignment.
> >>> > This
> >>> > > passed release build JTREG
> >>> for hotspot/jtreg/compiler/jvmti (just
> >>> > to run
> >>> > > something as a smoke screen)
> >>> and hotspot/jtreg/compiler/aot/ (to
> >>> > test
> >>> > > Graal).
> >>> > > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
> >>> > >
> >>> > I think this looks better, I agree that leaving _end is
> >>> tempting to
> >>> > avoid a lot of change, but I think this will be better in
> the
> >>> long run.
> >>> >
> >>> > I still miss the changes to make the SA work. To see a
> >>> problem you
> >>> > can run:
> >>> > make CONF=fast run-test
> >>> >
> TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
> >>> >
> >>> > Cheers,
> >>> > Stefan
> >>> >
> >>> > > Let me know what you think,
> >>> > > Jc
> >>> > >
> >>> > > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler
> >>> <jcbeyler at google.com <mailto:jcbeyler at google.com>
> >>> > <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>
> >>> > > <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com
> >
> >>> <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>>>
> wrote:
> >>> > >
> >>> > > Hi Karen and Stefan,
> >>> > >
> >>> > > @Stefan: Naming is hard :)
> >>> > > @Karen: thanks for the Graal comment, I fixed it in
> >>> the new
> >>> > webrev,
> >>> > > let me know what you think :)
> >>> > >
> >>> > > I think the naming convention suggested in this
> webrev
> >>> came from
> >>> > > conversations in for JEP-331 and I am actually
> >> relatively
> >>> > > indifferent to the final result (as long as we have
> >>> some form of
> >>> > > forward progress :)). To be honest, I'd also be
> happy
> >>> to just
> >>> > leave
> >>> > > _end as is for all architectures and Graal and have
> a
> >> new
> >>> > > _allocation_end. However, during initial reviews of
> >>> JEP-331
> >>> > it was
> >>> > > deemed complicated to understand:
> >>> > >
> >>> > > _end -> the _end or sampling end
> >>> > > _allocation_end -> end pointer for the last possible
> >>> allocation
> >>> > > hard_end -> allocation end + reserved space
> >>> > >
> >>> > > That is how this naming came up and why hard_end
> went
> >> to
> >>> > "reserved_end".
> >>> > >
> >>> > > I'm really indifferent, so I offer as a perusal:
> >>> > > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
> >>> > >
> >>> > > I noticed a few problems of alignement of '{' so
> I'll
> >>> go fix
> >>> > that.
> >>> > > Basically this webrev does the following:
> >>> > >
> >>> > > - Uses fast_path_end instead of end
> >>> > > - Reverts hard_end back to where it was
> >>> > > - Adds the changes to Graal; there is a bunch of
> >>> changes in Graal
> >>> > > because Graal still contains a bit of code doing
> >>> fasttlabrefills.
> >>> > >
> >>> > > Let me know what you think!
> >>> > >
> >>> > > Thanks,
> >>> > > Jc
> >>> > >
> >>> > >
> >>> > > On Tue, Apr 10, 2018 at 6:56 AM Karen Kinnear
> >>> > > <karen.kinnear at oracle.com
> >>> <mailto:karen.kinnear at oracle.com> <mailto:
> karen.kinnear at oracle.com
> >>> <mailto:karen.kinnear at oracle.com>>
> >>> > <mailto:karen.kinnear at oracle.com
> >>> <mailto:karen.kinnear at oracle.com> <mailto:
> karen.kinnear at oracle.com
> >>> <mailto:karen.kinnear at oracle.com>>>>
> >>> > wrote:
> >>> > >
> >>> > > Hi JC,
> >>> > >
> >>> > > A comment about Graal. The impact on Graal for
> this
> >>> > particular
> >>> > > change would be to break it - so you?ll need
> >>> > > to complete the Graal changes for this renaming.
> >>> That isn?t
> >>> > > optional or something that could be a
> follow-on. It
> >>> > > is not ok to break a feature, even an
> experimental
> >>> one.
> >>> > We will
> >>> > > discuss in the other thread potential phasing of
> >>> adding
> >>> > sampling.
> >>> > >
> >>> > > I did not do a thorough search -you can do that
> -
> >>> I did find
> >>> > > src/jdk.internal.vm.compiler/share/classes/
> >>> > >
> >>> >
> >>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>> > > public final int threadTlabOffset =
> >>> > > getFieldOffset("Thread::_tlab", Integer.class,
> >>> > > "ThreadLocalAllocBuffer");
> >>> > >
> >>> >
> >>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>> > > private final int
> >>> threadLocalAllocBufferStartOffset =
> >>> > > getFieldOffset("ThreadLocalAllocBuffer::_start",
> >>> > Integer.class,
> >>> > > "HeapWord*");
> >>> > >
> >>> >
> >>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>> > > private final int
> >> threadLocalAllocBufferEndOffset =
> >>> > > getFieldOffset("ThreadLocalAllocBuffer::_end",
> >>> Integer.class,
> >>> > > "HeapWord*");
> >>> > >
> >>> >
> >>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>> > > private final int
> >> threadLocalAllocBufferTopOffset =
> >>> > > getFieldOffset("ThreadLocalAllocBuffer::_top",
> >>> Integer.class,
> >>> > > "HeapWord*");
> >>> > >
> >>> >
> >>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>> > > private final int
> >>> threadLocalAllocBufferPfTopOffset =
> >>> > >
> getFieldOffset("ThreadLocalAllocBuffer::_pf_top",
> >>> > Integer.class,
> >>> > > "HeapWord*");
> >>> > >
> >>> >
> >>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>> > > private final int
> >>> > threadLocalAllocBufferSlowAllocationsOffset
> >>> > > =
> >>> getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
> >>> > > Integer.class, "unsigned");
> >>> > >
> >>> >
> >>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>> > > private final int
> >>> > threadLocalAllocBufferFastRefillWasteOffset
> >>> > > =
> >>> >
> getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
> >>> > > Integer.class, "unsigned");
> >>> > >
> >>> >
> >>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>> > > private final int
> >>> > threadLocalAllocBufferNumberOfRefillsOffset
> >>> > > =
> >>> >
> getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
> >>> > > Integer.class, "unsigned");
> >>> > >
> >>> >
> >>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>> > > private final int
> >>> > > threadLocalAllocBufferRefillWasteLimitOffset =
> >>> > >
> >>> getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
> >>> > > Integer.class, "size_t");
> >>> > >
> >>> >
> >>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>> > > private final int
> >>> > threadLocalAllocBufferDesiredSizeOffset =
> >>> > >
> >>> getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
> >>> > > Integer.class, "size_t");
> >>> > >
> >>> >
> >>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>> > > public final int tlabAlignmentReserve =
> >>> > >
> >>> >
> >>>
> >>
> getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
> >>> > > Integer.class, "size_t?);
> >>> > >
> >>> > > hope this helps,
> >>> > > Karen
> >>> > >
> >>> > >> On Apr 10, 2018, at 7:04 AM, Stefan Johansson
> >>> > >> <stefan.johansson at oracle.com
> >>> <mailto:stefan.johansson at oracle.com>
> >>> > <mailto:stefan.johansson at oracle.com
> >>> <mailto:stefan.johansson at oracle.com>>
> >>> > >> <mailto:stefan.johansson at oracle.com
> >>> <mailto:stefan.johansson at oracle.com>
> >>> > <mailto:stefan.johansson at oracle.com
> >>> <mailto:stefan.johansson at oracle.com>>>> wrote:
> >>> > >>
> >>> > >> Hi JC,
> >>> > >>
> >>> > >> I realize that the names have been discussed
> >>> before but I'm
> >>> > >> leaning towards suggesting something new. We
> >>> discussed this
> >>> > >> briefly here in the office and others might
> have
> >>> different
> >>> > >> opinions. One point that came up is that if we
> do
> >>> this
> >>> > change
> >>> > >> and change all usages of
> >>> JavaThread::tlab_end_offset() it
> >>> > >> would be good to make sure the new name is
> good.
> >>> To us
> >>> > >> _current_end is not very descriptive, but
> naming
> >>> is hard and
> >>> > >> the best we could come up with is
> _fast_path_end
> >>> which would
> >>> > >> give the code:
> >>> > >> cmpptr(end, Address(thread,
> >>> > >> JavaThread::tlab_fast_path_end_offset()));
> >>> > >> jcc(Assembler::above, slow_case);
> >>> > >>
> >>> > >> I think this reads pretty good and is fairly
> >>> clear. If we do
> >>> > >> this rename I think you can re-use _end in
> JEP-331
> >>> > instead of
> >>> > >> calling it _allocation_end. But that is a later
> >>> review :)
> >>> > >>
> >>> > >> Also, is there a good reason for renaming
> >>> hard_end() to
> >>> > >> reserved_end()?
> >>> > >>
> >>> > >> One additional thing, you need to update the SA
> >>> to reflect
> >>> > >> this change. I think the only place you need to
> >>> fix is in:
> >>> > >>
> >>> >
> >>>
> >>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
> >>> > >>
> >>> > >> Thanks,
> >>> > >> Stefan
> >>> > >>
> >>> > >> On 2018-04-09 19:24, JC Beyler wrote:
> >>> > >>> Hi all,
> >>> > >>> Small pre-amble to this request:
> >>> > >>> In my work to try to get a heap sampler in
> >>> OpenJDK (via JEP
> >>> > >>> 331
> >>> > <https://bugs.openjdk.java.net/browse/JDK-8171119>), I'm
> >>> > >>> trying to reduce the footprint of my change so
> >>> that the
> >>> > >>> integration can be easier. I was told that
> >>> generally a JEP
> >>> > >>> webrev should be feature complete and go in
> >> at-once.
> >>> > However,
> >>> > >>> with the change touching quite a bit of
> various
> >> code
> >>> > pieces,
> >>> > >>> I was trying to figure out what could be
> >>> separated as not
> >>> > >>> "part of the feature".
> >>> > >>> I asked around and said that perhaps a
> solution
> >>> would be to
> >>> > >>> cut up the renaming of TLAB's end field that I
> >>> do in that
> >>> > >>> webrev. Because I'm renaming a field in TLAB
> >> used by
> >>> > various
> >>> > >>> backends for that work, I have to update every
> >>> architecture
> >>> > >>> dependent code to reflect it.
> >>> > >>> I entirely understand that perhaps this is not
> >>> in the
> >>> > habits
> >>> > >>> and very potentially might not be the way
> things
> >> are
> >>> > >>> generally done. If so, I apologize and let me
> >>> know if you
> >>> > >>> would not want this to go in separately :)
> >>> > >>> Final note: there is still a chance JEP-331
> does
> >>> not go in.
> >>> > >>> If it does not, we can leave the new name in
> >>> place or I'll
> >>> > >>> happily revert it. I can even create an issue
> to
> >>> track this
> >>> > >>> if that makes it easier for all.
> >>> > >>> End of the pre-amble.
> >>> > >>> The 33-line change webrev in question is here:
> >>> > >>>
> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
> >>> > >>> I fixed all the architectures and JVMCI and
> ran
> >>> a few
> >>> > sanity
> >>> > >>> tests to ensure I had not missed anything.
> >>> > >>> Thanks for your help and I hope this is not
> too
> >> much
> >>> > trouble,
> >>> > >>> Jc
> >>> > >>> Ps: there is a graal change that needs to
> happen
> >>> but I was
> >>> > >>> not sure who/where
> <https://teams.googleplex.com/u/where>
> >> <https://teams.googleplex.com/u/where>
> >>> <https://teams.googleplex.com/u/where>
> >>> > <https://teams.googleplex.com/u/where>
> >>> > <https://teams.googleplex.com/u/where> to
> >>> > >>> ask about it. I was told it could happen in a
> >>> separate
> >>> > >>> webrev. Can anyone point me to the right
> >> direction?
> >>> > Should it
> >>> > >>> just be hotspot-compiler-dev?
> >>> > >
> >>> >
> >>>
>
>
From david.holmes at oracle.com Mon Apr 16 23:52:42 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Apr 2018 09:52:42 +1000
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <49cd1bbe-0243-d34e-7990-7e727e3e509a@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<2eee7977-9955-fd8b-9321-f2b7529f8c4b@redhat.com>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
<6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
<CAA-vtUwnVXnRPkT6Waw=q3SsV+J33TYUmY-3MM76QBYMZ9DqJg@mail.gmail.com>
<43f7de51-4fd9-3dac-2e23-f40ce3e7b4c0@physik.fu-berlin.de>
<3ea48b20-8d19-18f4-40e5-d8beb6c35461@physik.fu-berlin.de>
<49cd1bbe-0243-d34e-7990-7e727e3e509a@physik.fu-berlin.de>
Message-ID: <935e41ee-9618-24a8-b7e9-8a149e112006@oracle.com>
Hi Adrian,
On 16/04/2018 11:09 PM, John Paul Adrian Glaubitz wrote:
> On 04/16/2018 12:49 PM, John Paul Adrian Glaubitz wrote:
>> Ah, according to the bug report, this particular issue affects older
>> SPARC CPUs only. This explains why it happens on the UltraSPARC T1
>> but currently not on the SPARC T5.
>>
>> Will keep on digging! Thanks for the additional pointers.
>
> Ok, so the actual crash after working around JDK-8144448 now seems this
> one:
Unfortunately the bit you really need is missing:
#18 0xffff800101aec0a0 in signalHandler (sig=<optimized out>,
info=0xffff8001026d1fb0, uc=0xffff8001026d1fb0) at
/srv/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:4396
#19 <signal handler called>
#20 0xffff80010fbfd0c8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
It's the original fault that needs to be uncovered. All sorts of
weirdness can happen in attempting to do error reporting if you were in
an unexpected state to start with.
David
-----
>
> (gdb) bt
> #0? 0xffff8001006abb9c in __libc_signal_restore_set
> (set=0xffff8001026d0f28) at ../sysdeps/unix/sysv/linux/nptl-signals.h:80
> #1? __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:48
> #2? 0xffff8001006ad144 in __GI_abort () at abort.c:79
> #3? 0xffff800101aeefbc in os::abort (dump_core=<optimized out>,
> siginfo=0xffff8001026d1fb0, context=0xffff8001026d1fb0) at
> /srv/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:1423
> #4? 0xffff800101f0f38c in VMError::report_and_die
> (id=id at entry=-536870912, message=message at entry=0xffff80010205b260 "fatal
> error", detail_fmt=detail_fmt at entry=0xffff80010214f850 "LEAF method
> calling lock?", detail_args=detail_args at entry=0xffff8001026d1678,
> ??? thread=thread at entry=0xffff80010401a000, pc=pc at entry=0x0,
> siginfo=0x0, context=0x0, filename=0xffff80010214eec8
> "/srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp", lineno=985,
> size=0) at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1504
> #5? 0xffff800101f101c8 in VMError::report_and_die
> (thread=0xffff80010401a000, context=context at entry=0x0,
> filename=filename at entry=0xffff80010214eec8
> "/srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp",
> lineno=lineno at entry=985,
> ??? message=0xffff80010205b260 "fatal error",
> detail_fmt=detail_fmt at entry=0xffff80010214f850 "LEAF method calling
> lock?", detail_args=<optimized out>) at
> /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1244
> #6? 0xffff80010117e6c8 in report_fatal (file=0xffff80010214eec8
> "/srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp",
> line=line at entry=985, detail_fmt=0xffff80010214f850 "LEAF method calling
> lock?") at /srv/openjdk/hs/src/hotspot/share/utilities/debug.cpp:250
> #7? 0xffff800101e2ae10 in Thread::check_for_valid_safepoint_state
> (this=this at entry=0xffff80010401a000,
> potential_vm_operation=potential_vm_operation at entry=false) at
> /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:985
> #8? 0xffff800101e49394 in ThreadsSMRSupport::acquire_stable_list
> (is_ThreadsListSetter=false, self=0xffff80010401a000) at
> /srv/openjdk/hs/src/hotspot/share/runtime/threadSMR.cpp:629
> #9? ThreadsListHandle::ThreadsListHandle (this=0xffff8001026d1818,
> self=0xffff80010401a000) at
> /srv/openjdk/hs/src/hotspot/share/runtime/threadSMR.cpp:471
> #10 0xffff800101ae1af0 in
> JavaThreadIteratorWithHandle::JavaThreadIteratorWithHandle
> (this=0xffff8001026d1810) at
> /srv/openjdk/hs/src/hotspot/share/runtime/threadSMR.hpp:307
> #11 os::print_location (st=st at entry=0xffff8001023e3228 <VMError::log>,
> x=416, verbose=verbose at entry=false) at
> /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:1113
> #12 0xffff800101b02b3c in os::print_register_info
> (st=st at entry=0xffff8001023e3228 <VMError::log>,
> context=0xffff8001026d1fb0) at
> /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp:253
> #13 0xffff800101f0dfac in VMError::report
> (st=st at entry=0xffff8001023e3228 <VMError::log>,
> _verbose=_verbose at entry=true) at
> /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:748
> #14 0xffff800101f0f440 in VMError::report_and_die (id=id at entry=11,
> message=message at entry=0x0,
> detail_fmt=detail_fmt at entry=0xffff80010214c870 "%s",
> detail_args=detail_args at entry=0xffff8001026d1ce0,
> thread=thread at entry=0xffff80010401a000,
> ??? pc=pc at entry=0xffff80010fbfd0c8 "\300\\ ",
> siginfo=0xffff8001026d1fb0, context=0xffff8001026d1fb0, filename=0x0,
> lineno=0, size=0) at
> /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1405
> #15 0xffff800101f100b8 in VMError::report_and_die
> (thread=thread at entry=0xffff80010401a000, sig=sig at entry=11,
> pc=pc at entry=0xffff80010fbfd0c8 "\300\\ ",
> siginfo=siginfo at entry=0xffff8001026d1fb0,
> context=context at entry=0xffff8001026d1fb0, detail_fmt=0xffff80010214c870
> "%s")
> ??? at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1219
> #16 0xffff800101f10104 in VMError::report_and_die
> (thread=thread at entry=0xffff80010401a000, sig=sig at entry=11,
> pc=pc at entry=0xffff80010fbfd0c8 "\300\\ ",
> siginfo=siginfo at entry=0xffff8001026d1fb0,
> context=context at entry=0xffff8001026d1fb0)
> ??? at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1225
> #17 0xffff800101b058b4 in JVM_handle_linux_signal (sig=sig at entry=11,
> info=info at entry=0xffff8001026d1fb0,
> ucVoid=ucVoid at entry=0xffff8001026d1fb0,
> abort_if_unrecognized=abort_if_unrecognized at entry=1) at
> /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp:646
> #18 0xffff800101aec0a0 in signalHandler (sig=<optimized out>,
> info=0xffff8001026d1fb0, uc=0xffff8001026d1fb0) at
> /srv/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:4396
> #19 <signal handler called>
> #20 0xffff80010fbfd0c8 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)
>
From david.holmes at oracle.com Tue Apr 17 00:33:23 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Apr 2018 10:33:23 +1000
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <935e41ee-9618-24a8-b7e9-8a149e112006@oracle.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
<6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
<CAA-vtUwnVXnRPkT6Waw=q3SsV+J33TYUmY-3MM76QBYMZ9DqJg@mail.gmail.com>
<43f7de51-4fd9-3dac-2e23-f40ce3e7b4c0@physik.fu-berlin.de>
<3ea48b20-8d19-18f4-40e5-d8beb6c35461@physik.fu-berlin.de>
<49cd1bbe-0243-d34e-7990-7e727e3e509a@physik.fu-berlin.de>
<935e41ee-9618-24a8-b7e9-8a149e112006@oracle.com>
Message-ID: <7ebf0b4d-4e2a-f87e-be72-90d4e6490bf0@oracle.com>
On 17/04/2018 9:52 AM, David Holmes wrote:
> Hi Adrian,
>
> On 16/04/2018 11:09 PM, John Paul Adrian Glaubitz wrote:
>> On 04/16/2018 12:49 PM, John Paul Adrian Glaubitz wrote:
>>> Ah, according to the bug report, this particular issue affects older
>>> SPARC CPUs only. This explains why it happens on the UltraSPARC T1
>>> but currently not on the SPARC T5.
>>>
>>> Will keep on digging! Thanks for the additional pointers.
>>
>> Ok, so the actual crash after working around JDK-8144448 now seems
>> this one:
>
> Unfortunately the bit you really need is missing:
>
> #18 0xffff800101aec0a0 in signalHandler (sig=<optimized out>,
> info=0xffff8001026d1fb0, uc=0xffff8001026d1fb0) at
> /srv/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:4396
> #19 <signal handler called>
> #20 0xffff80010fbfd0c8 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> It's the original fault that needs to be uncovered. All sorts of
> weirdness can happen in attempting to do error reporting if you were in
> an unexpected state to start with.
Though also see:
https://bugs.openjdk.java.net/browse/JDK-8201592
which seems to be the same secondary crash - but can't comment on the
primary one.
David
> David
> -----
>
>>
>> (gdb) bt
>> #0? 0xffff8001006abb9c in __libc_signal_restore_set
>> (set=0xffff8001026d0f28) at ../sysdeps/unix/sysv/linux/nptl-signals.h:80
>> #1? __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:48
>> #2? 0xffff8001006ad144 in __GI_abort () at abort.c:79
>> #3? 0xffff800101aeefbc in os::abort (dump_core=<optimized out>,
>> siginfo=0xffff8001026d1fb0, context=0xffff8001026d1fb0) at
>> /srv/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:1423
>> #4? 0xffff800101f0f38c in VMError::report_and_die
>> (id=id at entry=-536870912, message=message at entry=0xffff80010205b260
>> "fatal error", detail_fmt=detail_fmt at entry=0xffff80010214f850 "LEAF
>> method calling lock?", detail_args=detail_args at entry=0xffff8001026d1678,
>> ???? thread=thread at entry=0xffff80010401a000, pc=pc at entry=0x0,
>> siginfo=0x0, context=0x0, filename=0xffff80010214eec8
>> "/srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp", lineno=985,
>> size=0) at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1504
>> #5? 0xffff800101f101c8 in VMError::report_and_die
>> (thread=0xffff80010401a000, context=context at entry=0x0,
>> filename=filename at entry=0xffff80010214eec8
>> "/srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp",
>> lineno=lineno at entry=985,
>> ???? message=0xffff80010205b260 "fatal error",
>> detail_fmt=detail_fmt at entry=0xffff80010214f850 "LEAF method calling
>> lock?", detail_args=<optimized out>) at
>> /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1244
>> #6? 0xffff80010117e6c8 in report_fatal (file=0xffff80010214eec8
>> "/srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp",
>> line=line at entry=985, detail_fmt=0xffff80010214f850 "LEAF method
>> calling lock?") at
>> /srv/openjdk/hs/src/hotspot/share/utilities/debug.cpp:250
>> #7? 0xffff800101e2ae10 in Thread::check_for_valid_safepoint_state
>> (this=this at entry=0xffff80010401a000,
>> potential_vm_operation=potential_vm_operation at entry=false) at
>> /srv/openjdk/hs/src/hotspot/share/runtime/thread.cpp:985
>> #8? 0xffff800101e49394 in ThreadsSMRSupport::acquire_stable_list
>> (is_ThreadsListSetter=false, self=0xffff80010401a000) at
>> /srv/openjdk/hs/src/hotspot/share/runtime/threadSMR.cpp:629
>> #9? ThreadsListHandle::ThreadsListHandle (this=0xffff8001026d1818,
>> self=0xffff80010401a000) at
>> /srv/openjdk/hs/src/hotspot/share/runtime/threadSMR.cpp:471
>> #10 0xffff800101ae1af0 in
>> JavaThreadIteratorWithHandle::JavaThreadIteratorWithHandle
>> (this=0xffff8001026d1810) at
>> /srv/openjdk/hs/src/hotspot/share/runtime/threadSMR.hpp:307
>> #11 os::print_location (st=st at entry=0xffff8001023e3228 <VMError::log>,
>> x=416, verbose=verbose at entry=false) at
>> /srv/openjdk/hs/src/hotspot/share/runtime/os.cpp:1113
>> #12 0xffff800101b02b3c in os::print_register_info
>> (st=st at entry=0xffff8001023e3228 <VMError::log>,
>> context=0xffff8001026d1fb0) at
>> /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp:253
>> #13 0xffff800101f0dfac in VMError::report
>> (st=st at entry=0xffff8001023e3228 <VMError::log>,
>> _verbose=_verbose at entry=true) at
>> /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:748
>> #14 0xffff800101f0f440 in VMError::report_and_die (id=id at entry=11,
>> message=message at entry=0x0,
>> detail_fmt=detail_fmt at entry=0xffff80010214c870 "%s",
>> detail_args=detail_args at entry=0xffff8001026d1ce0,
>> thread=thread at entry=0xffff80010401a000,
>> ???? pc=pc at entry=0xffff80010fbfd0c8 "\300\\ ",
>> siginfo=0xffff8001026d1fb0, context=0xffff8001026d1fb0, filename=0x0,
>> lineno=0, size=0) at
>> /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1405
>> #15 0xffff800101f100b8 in VMError::report_and_die
>> (thread=thread at entry=0xffff80010401a000, sig=sig at entry=11,
>> pc=pc at entry=0xffff80010fbfd0c8 "\300\\ ",
>> siginfo=siginfo at entry=0xffff8001026d1fb0,
>> context=context at entry=0xffff8001026d1fb0,
>> detail_fmt=0xffff80010214c870 "%s")
>> ???? at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1219
>> #16 0xffff800101f10104 in VMError::report_and_die
>> (thread=thread at entry=0xffff80010401a000, sig=sig at entry=11,
>> pc=pc at entry=0xffff80010fbfd0c8 "\300\\ ",
>> siginfo=siginfo at entry=0xffff8001026d1fb0,
>> context=context at entry=0xffff8001026d1fb0)
>> ???? at /srv/openjdk/hs/src/hotspot/share/utilities/vmError.cpp:1225
>> #17 0xffff800101b058b4 in JVM_handle_linux_signal (sig=sig at entry=11,
>> info=info at entry=0xffff8001026d1fb0,
>> ucVoid=ucVoid at entry=0xffff8001026d1fb0,
>> abort_if_unrecognized=abort_if_unrecognized at entry=1) at
>> /srv/openjdk/hs/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp:646
>> #18 0xffff800101aec0a0 in signalHandler (sig=<optimized out>,
>> info=0xffff8001026d1fb0, uc=0xffff8001026d1fb0) at
>> /srv/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:4396
>> #19 <signal handler called>
>> #20 0xffff80010fbfd0c8 in ?? ()
>> Backtrace stopped: previous frame identical to this frame (corrupt
>> stack?)
>> (gdb)
>>
From stefan.johansson at oracle.com Tue Apr 17 06:59:50 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Tue, 17 Apr 2018 08:59:50 +0200
Subject: RFR(S): 8200720: Print accumulated number of allocated bytes in
thread dump
In-Reply-To: <62D591F7-AA82-40A3-B518-53AD60DC97BE@sap.com>
References: <171FA571-AFEC-4E88-B681-D10F8DFD1639@sap.com>
<721b10fe-742a-4d4b-0b97-44258664a408@oracle.com>
<62D591F7-AA82-40A3-B518-53AD60DC97BE@sap.com>
Message-ID: <b37d4815-6035-39d6-e31d-f2481596d231@oracle.com>
Hi Gunter,
No problem, it's good to hear that the current accounting is sufficient.
The question regarding if this and other fields are desirable in the
thread dumps I will leave to the runtime and serviceability teams.
Thanks,
Stefan
On 2018-04-16 16:03, Haug, Gunter wrote:
> Hi Stefan,
>
> Thank you for your reply and sorry for being late with mine.
> Probably I made a poor choice with the field I took as an example. There is absolutely no reason to add a separate accounting mechanism for bytes allocated by a thread. We implemented our version many years ago, sorry that I didn't check this again. In this particular case we could just use the existing one and get rid of ours.
>
> However, as mentioned, we output more data (cpu time, number of defined classes, number of files opened, number of socks opened, number of bytes read/written via file and socket io and pthread-id) in the thread dump. The question is: is it desirable or even acceptable to add this information (or in fact any information) to the thread dump output?
>
> Thank you,
> Gunter
>
> ?On 06.04.18, 10:24, "hotspot-dev on behalf of Stefan Johansson" <hotspot-dev-bounces at openjdk.java.net on behalf of stefan.johansson at oracle.com> wrote:
>
> Hi Gunter,
>
> On 2018-04-05 12:28, Haug, Gunter wrote:
> > Hi,
> >
> > can I please have a review and a sponsor for the following enhancement:
> >
> > http://cr.openjdk.java.net/~ghaug/webrevs/8200720
> > https://bugs.openjdk.java.net/browse/JDK-8200720
> >
>
> There is already accounting of allocated bytes on Thread:
> jlong _allocated_bytes; // Cumulative number of bytes allocated on
> // the Java heap
>
> The value is updated at TLAB refills and allocations outside the TLAB,
> so it already includes the type allocations JC is mentioning. Any reason
> this can't be used instead of adding your new accounting?
>
> To include bytes allocated in the current TLAB you can call:
> Thread::cooked_allocated_bytes();
>
> Thanks,
> Stefan
>
> > We at SAP have extended the thread dumps (obtained by jstack or jcmd) by several fields providing thread specific information. These extensions are quite popular with our support team. With some knowledge of the architecture of the application, they often allow for quick and simple diagnosis of a running system. Therefore we would like to contribute these enhancements.
> >
> > I took the quite simple accumulated number of bytes allocated by a thread as an example. This only works with TLAB active. Provided it is known how the application should behave, a misbehaving thread can identified easily.
> >
> > There is no measurable overhead for this enhancement. However, it may be a problem that the format of the output is changed. Tools parsing the output may have to be changed.
> >
> > Here is an example of the output generated:
> >
> > ---------------------------------------------------------
> > "main" #1 prio=5 os_prio=31 allocated=243048448B tid=0x00007fca98000800 nid=0x1d03 waiting on condition [0x0000000109baa000]
> > java.lang.Thread.State: TIMED_WAITING (sleeping)
> > at java.lang.Thread.sleep(java.base/Native Method)
> > ...
> > ---------------------------------------------------------
> >
> > As mentioned above, we have a whole bunch of other enhancements to the thread dump similar to this one and would be willing to contribute them if there is any interest.
> >
> > Thanks and best regards,
> > Gunter
> >
>
>
From david.holmes at oracle.com Tue Apr 17 08:48:53 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Apr 2018 18:48:53 +1000
Subject: (M) RFR: 8200167: Validate more special case invocations
Message-ID: <27391c2a-fd5c-8133-8e31-b8b45db157ce@oracle.com>
Bug: https://bugs.openjdk.java.net/browse/JDK-8200167
webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev/
Credit to John Rose and Vladimir Ivanov for the form of the MH fix; and
to Tobias Hartmann for the C1 fix. Their help was very much appreciated
(and needed!).
tl;dr version: there are some places where badly formed interface method
calls (which are not detected by the verifier) were missing runtime
checks on the type of the receiver. Similar issues have been fixed in
the past and this was a remaining hole in relation to invokespecial
semantics and interface calls via MethodHandles. It also turned out
there was an issue in C1 that affected direct invokespecial calls.
Description of changes:
- src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java
Added a new form LF_INVSPECIAL_IFC for invokespecial of interface methods.
- src/java.base/share/classes/java/lang/invoke/MethodHandles.java
Renamed callerClass parameter to boundCallerClass, where it originates
from findBoundCallerClass. The name "callerClass" is misleading because
most of the time it is NULL!
In getDirectMethodCommon, pass the actual caller class (lookupClass) to
DirectMethodHandle.make. And correct the comment about restrictReceiver.
- src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
DirectMethodHandle.make now takes a callerClass parameter (which may be
null).
DirectMethodHandle make "receiver" parameter is renamed "refc" as it is
not the receiver (it's the resolved type of the method holder ie REFC).
The Special subclass now takes a "checkClass" parameter which is either
refc, or callerClass. This is what we will check the receiver against.
In preparedLambdaForm we switch from LF_INVSPECIAL to LF_INVSPECIAL_IFC
if the target method is in an interface.
In makePreparedLambdaForm we augment the needsReceiverCheck test to
include LF_INVSPECIAL_IFC. (So we will not be doing a new receiver type
check on all invokespecials, just those involving interface methods.)
Added DMH.checkReceiver which is overridden by both the Special and
Interface subclasses.
- src/hotspot/share/c1/c1_Canonicalizer.cpp
Don't optimize away the checkcast when it is an invokespecial receiver
check.
- test/jdk/java/lang/invoke/SpecialInterfaceCall.java
(I've moved this test back and forth between hotspot/runtime and
j.l.invoke as it spans direct calls and MH calls. But I think on balance
it lands better here.)
The test sets up direct interface method calls for which invokespecial
is generated by javac, and similarly it creates MethodHandles with
invokespecial semantics. The should-not-throw cases are trivial. The
should-throw cases involve MH wizardry.
The test is broken into three parts to check the behaviour on first use
(when the method has to be initially resolved); on second use (to test
we don't use the cpcache in a way that is invalid); and again after
forcing JIT compilation of the calls.
The test is run 5 times to exercise the interpreter (yes the multiple
runs internal to the test are redundant in this case, but it's much
simpler to just run it all than try to work out what needs to be run);
the three variants of using C1, plus a C2 only run.
---
Testing:
- the new test of course
- hotspot/runtime/*
- hotspot/compiler/jsr292
- jdk/java/lang/invoke
- hs tiers 1 and 2
- jdk tiers 1, 2 and 3
Plus some related closed tests.
Thanks,
David
-----
From glaubitz at physik.fu-berlin.de Tue Apr 17 09:14:15 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 17 Apr 2018 11:14:15 +0200
Subject: Confusing Mercurial history - was: Re: Hotspot segfaulting on
Linux SPARC
In-Reply-To: <aff63590-e2b4-4271-f10c-e026a81c9c7e@redhat.com>
References: <a7c616c3-830b-9411-f50e-cf4f4c6ddd27@physik.fu-berlin.de>
<ee9f2ece-d0f9-a5ae-04be-d2290f9b0ce2@physik.fu-berlin.de>
<aff63590-e2b4-4271-f10c-e026a81c9c7e@redhat.com>
Message-ID: <4ca87e99-1612-fa67-43ff-d63486e1adf4@physik.fu-berlin.de>
Hi Roman!
On 04/16/2018 08:36 PM, Roman Kennke wrote:
>> I would normally expect a changeset that was checked in in July to be included
>> in a revision that was checked in in August. I don't understand how one is supposed
>> to perform bi-secting with Mercurial if something as basic as a working history
>> doesn't work in Mercurial.
>
> You're probably wrongly assuming that commit history is linear. It is
> not. TBH, I don't really know how hg bisect works with branchy history.
> It usually works fairly well in my experience. It will probably get
> confused if you start out with two revision on different branches? Or
> are you trying to bisect manually?
Yes, I am aware that the commit history is not linear. However, I am quite
sure that the revision 46931 previously contained the revisions 46667
and 46668 in the past but now it doesn't which is what confuses me.
> Here's some information around this stuff:
> http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html#sec:undo:bisect
I have found this guide as well and followed through it. However, in order
to start bisecting, I need to find a good revision first which is already
where I failed.
I tried many different revisions around 46931. But those either contained
the bug I am now seeing or they were missing various other changes which
are necessary to fix the build on linux-sparc.
I have successfully bisected large codebases like QEMU with git in the past
successfully but I am completely failing at that with Mercurial. I think
I will try a git mirror of the OpenJDK repository next because I am not
sure whether I am just using Mercurial wrong or whether bisecting there
is so much more difficult as compared to git.
For what is worth, I have also tried older versions of binutils and the
kernel to make sure that the crash that I am seeing on linux-sparc is
just not an artifact.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From glaubitz at physik.fu-berlin.de Tue Apr 17 09:18:44 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 17 Apr 2018 11:18:44 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <935e41ee-9618-24a8-b7e9-8a149e112006@oracle.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<f460911a-5cbe-ff9d-a516-99befb37ce35@oracle.com>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
<6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
<CAA-vtUwnVXnRPkT6Waw=q3SsV+J33TYUmY-3MM76QBYMZ9DqJg@mail.gmail.com>
<43f7de51-4fd9-3dac-2e23-f40ce3e7b4c0@physik.fu-berlin.de>
<3ea48b20-8d19-18f4-40e5-d8beb6c35461@physik.fu-berlin.de>
<49cd1bbe-0243-d34e-7990-7e727e3e509a@physik.fu-berlin.de>
<935e41ee-9618-24a8-b7e9-8a149e112006@oracle.com>
Message-ID: <0b11cd34-57a4-54d9-e2b8-3e59e68794ce@physik.fu-berlin.de>
On 04/17/2018 01:52 AM, David Holmes wrote:
>> Ok, so the actual crash after working around JDK-8144448 now seems this one:
>
> Unfortunately the bit you really need is missing:
>
> #18 0xffff800101aec0a0 in signalHandler (sig=<optimized out>, info=0xffff8001026d1fb0, uc=0xffff8001026d1fb0) at /srv/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:4396
> #19 <signal handler called>
> #20 0xffff80010fbfd0c8 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> It's the original fault that needs to be uncovered. All sorts of weirdness can happen in attempting to do error reporting if you were in an unexpected state to start with.
I already assumed that the backtrace is incomplete. Unfortunately, it won't
let me perform any further unwinding of the stack to be able to see the
rest of the story :(.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From stefan.karlsson at oracle.com Tue Apr 17 09:34:01 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 17 Apr 2018 11:34:01 +0200
Subject: Confusing Mercurial history - was: Re: Hotspot segfaulting on
Linux SPARC
In-Reply-To: <4ca87e99-1612-fa67-43ff-d63486e1adf4@physik.fu-berlin.de>
References: <a7c616c3-830b-9411-f50e-cf4f4c6ddd27@physik.fu-berlin.de>
<ee9f2ece-d0f9-a5ae-04be-d2290f9b0ce2@physik.fu-berlin.de>
<aff63590-e2b4-4271-f10c-e026a81c9c7e@redhat.com>
<4ca87e99-1612-fa67-43ff-d63486e1adf4@physik.fu-berlin.de>
Message-ID: <dc1d323e-2647-e80a-1f28-e00d79a5f50a@oracle.com>
On 2018-04-17 11:14, John Paul Adrian Glaubitz wrote:
> Hi Roman!
>
> On 04/16/2018 08:36 PM, Roman Kennke wrote:
>>> I would normally expect a changeset that was checked in in July to be
>>> included
>>> in a revision that was checked in in August. I don't understand how
>>> one is supposed
>>> to perform bi-secting with Mercurial if something as basic as a
>>> working history
>>> doesn't work in Mercurial.
>>
>> You're probably wrongly assuming that commit history is linear. It is
>> not. TBH, I don't really know how hg bisect works with branchy history.
>> It usually works fairly well in my experience. It will probably get
>> confused if you start out with two revision on different branches? Or
>> are you trying to bisect manually?
>
> Yes, I am aware that the commit history is not linear. However, I am quite
> sure that the revision 46931 previously contained the revisions 46667
> and 46668 in the past but now it doesn't which is what confuses me.
As I Severin said, these numbers are your local numbers and might not at
all match what I have in my copy of jdk/hs. However, if we assume that
they are the same, I get this:
hg log -r 'reverse(0::46931)' --graph
o changeset: 46931:6e1b59330482
| parent: 46253:f7daf2e39cc8
| user: glaubitz
| date: Mon Aug 21 15:17:21 2017 +0200
| summary: 8186433: Compiler flag -arch=sparc should not be passed
on linux-sparc
|
o changeset: 46253:f7daf2e39cc8
| parent: 46250:3041c580db2a
| user: bobv
| date: Mon Aug 21 12:08:03 2017 -0400
| summary: 8186115: libelf still referenced after 8172670
Where the parent of 46931 is 46253.
And hg log -r '46668::46931'
gives back nothing indicating that 46668 is not a ancestor of 46931.
You can also find the first common ancestor of the two change sets:
hg log -r 'ancestor(46667,46931)'
changeset: 45825:4fa7bd62eb84
parent: 45761:9ef5029b247b
user: alanb
date: Wed Jul 05 13:25:45 2017 +0100
summary: 8183503: Update hotspot tests to allow for unique test
classes directory
Can you share the SHA number for your 46668 change, and maybe the summry
line as well?
StefanK
>
>> Here's some information around this stuff:
>> http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html#sec:undo:bisect
>>
>
> I have found this guide as well and followed through it. However, in order
> to start bisecting, I need to find a good revision first which is already
> where I failed.
>
> I tried many different revisions around 46931. But those either contained
> the bug I am now seeing or they were missing various other changes which
> are necessary to fix the build on linux-sparc.
>
> I have successfully bisected large codebases like QEMU with git in the past
> successfully but I am completely failing at that with Mercurial. I think
> I will try a git mirror of the OpenJDK repository next because I am not
> sure whether I am just using Mercurial wrong or whether bisecting there
> is so much more difficult as compared to git.
>
> For what is worth, I have also tried older versions of binutils and the
> kernel to make sure that the crash that I am seeing on linux-sparc is
> just not an artifact.
>
> Adrian
>
From glaubitz at physik.fu-berlin.de Tue Apr 17 09:41:32 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 17 Apr 2018 11:41:32 +0200
Subject: Confusing Mercurial history - was: Re: Hotspot segfaulting on
Linux SPARC
In-Reply-To: <dc1d323e-2647-e80a-1f28-e00d79a5f50a@oracle.com>
References: <a7c616c3-830b-9411-f50e-cf4f4c6ddd27@physik.fu-berlin.de>
<ee9f2ece-d0f9-a5ae-04be-d2290f9b0ce2@physik.fu-berlin.de>
<aff63590-e2b4-4271-f10c-e026a81c9c7e@redhat.com>
<4ca87e99-1612-fa67-43ff-d63486e1adf4@physik.fu-berlin.de>
<dc1d323e-2647-e80a-1f28-e00d79a5f50a@oracle.com>
Message-ID: <853b79ef-18e9-7ffd-0297-6086302c547e@physik.fu-berlin.de>
On 04/17/2018 11:34 AM, Stefan Karlsson wrote:
> As I Severin said, these numbers are your local numbers and might not at all match what I have in my copy of jdk/hs. However, if we assume that they are the same, I get this:
I actually checked the revision numbers in the remote repository:
> http://hg.openjdk.java.net/jdk/hs/rev/f5a564180f37 is 46668
> http://hg.openjdk.java.net/jdk/hs/rev/ff7b9f61209e is 46667
> http://hg.openjdk.java.net/jdk/hs/rev/6e1b59330482 is 46931
The revision numbers match my local repository checkout.
> hg log -r 'reverse(0::46931)' --graph
>
> o? changeset:?? 46931:6e1b59330482
> |? parent:????? 46253:f7daf2e39cc8
> |? user:??????? glaubitz
> |? date:??????? Mon Aug 21 15:17:21 2017 +0200
> |? summary:???? 8186433: Compiler flag -arch=sparc should not be passed on linux-sparc
> |
> o? changeset:?? 46253:f7daf2e39cc8
> |? parent:????? 46250:3041c580db2a
> |? user:??????? bobv
> |? date:??????? Mon Aug 21 12:08:03 2017 -0400
> |? summary:???? 8186115: libelf still referenced after 8172670
>
> Where the parent of 46931 is 46253.
>
> And hg log -r '46668::46931'
>
> gives back nothing indicating that 46668 is not a ancestor of 46931.
Ok, that's odd. I don't understand how one is supposed to perform bisecting
then.
> You can also find the first common ancestor of the two change sets:
>
> hg log -r 'ancestor(46667,46931)'
> changeset:?? 45825:4fa7bd62eb84
> parent:????? 45761:9ef5029b247b
> user:??????? alanb
> date:??????? Wed Jul 05 13:25:45 2017 +0100
> summary:???? 8183503: Update hotspot tests to allow for unique test classes directory
>
> Can you share the SHA number for your 46668 change, and maybe the summry line as well?
That would be:
changeset 46668:f5a564180f37
8182165: The header atomic_linux_sparc.inline.hpp should be named atomic_linux_sparc.hpp
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From stefan.karlsson at oracle.com Tue Apr 17 09:57:18 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 17 Apr 2018 11:57:18 +0200
Subject: Confusing Mercurial history - was: Re: Hotspot segfaulting on
Linux SPARC
In-Reply-To: <853b79ef-18e9-7ffd-0297-6086302c547e@physik.fu-berlin.de>
References: <a7c616c3-830b-9411-f50e-cf4f4c6ddd27@physik.fu-berlin.de>
<ee9f2ece-d0f9-a5ae-04be-d2290f9b0ce2@physik.fu-berlin.de>
<aff63590-e2b4-4271-f10c-e026a81c9c7e@redhat.com>
<4ca87e99-1612-fa67-43ff-d63486e1adf4@physik.fu-berlin.de>
<dc1d323e-2647-e80a-1f28-e00d79a5f50a@oracle.com>
<853b79ef-18e9-7ffd-0297-6086302c547e@physik.fu-berlin.de>
Message-ID: <243ba6c3-032a-4faa-a0b6-2454114c3752@oracle.com>
On 2018-04-17 11:41, John Paul Adrian Glaubitz wrote:
> On 04/17/2018 11:34 AM, Stefan Karlsson wrote:
>> As I Severin said, these numbers are your local numbers and might not
>> at all match what I have in my copy of jdk/hs. However, if we assume
>> that they are the same, I get this:
>
> I actually checked the revision numbers in the remote repository:
>
>> http://hg.openjdk.java.net/jdk/hs/rev/f5a564180f37 is 46668
>> http://hg.openjdk.java.net/jdk/hs/rev/ff7b9f61209e is 46667
>> http://hg.openjdk.java.net/jdk/hs/rev/6e1b59330482 is 46931
>
> The revision numbers match my local repository checkout.
Good. This matches what I have.
>
>> hg log -r 'reverse(0::46931)' --graph
>>
>> o? changeset:?? 46931:6e1b59330482
>> |? parent:????? 46253:f7daf2e39cc8
>> |? user:??????? glaubitz
>> |? date:??????? Mon Aug 21 15:17:21 2017 +0200
>> |? summary:???? 8186433: Compiler flag -arch=sparc should not be
>> passed on linux-sparc
>> |
>> o? changeset:?? 46253:f7daf2e39cc8
>> |? parent:????? 46250:3041c580db2a
>> |? user:??????? bobv
>> |? date:??????? Mon Aug 21 12:08:03 2017 -0400
>> |? summary:???? 8186115: libelf still referenced after 8172670
>>
>> Where the parent of 46931 is 46253.
>>
>> And hg log -r '46668::46931'
>>
>> gives back nothing indicating that 46668 is not a ancestor of 46931.
>
> Ok, that's odd. I don't understand how one is supposed to perform bisecting
> then.
That means that there's nothing to bisect between 46668 and 46931. 46931
is not built on top of 46668. They were merged at a later point. You
need to follow the DAG when bisecting.
StefanK
>
>> You can also find the first common ancestor of the two change sets:
>>
>> hg log -r 'ancestor(46667,46931)'
>> changeset:?? 45825:4fa7bd62eb84
>> parent:????? 45761:9ef5029b247b
>> user:??????? alanb
>> date:??????? Wed Jul 05 13:25:45 2017 +0100
>> summary:???? 8183503: Update hotspot tests to allow for unique test
>> classes directory
>>
>> Can you share the SHA number for your 46668 change, and maybe the
>> summry line as well?
> That would be:
>
> changeset 46668:f5a564180f37
> 8182165: The header atomic_linux_sparc.inline.hpp should be named
> atomic_linux_sparc.hpp
>
> Adrian
>
From per.liden at oracle.com Tue Apr 17 12:38:35 2018
From: per.liden at oracle.com (Per Liden)
Date: Tue, 17 Apr 2018 14:38:35 +0200
Subject: RFR: 8201647: Make initial clearing of CHeapBitMap optional
Message-ID: <336cf9d0-0c71-0a01-8c4f-51103c39acc3@oracle.com>
CHeapBitMap objects will by default clear the underlying bitmap during
construction. In ZGC we don't want mark bitmaps to be cleared on
construction, since we instead do this lazily during concurrent marking.
This patch adds a "bool clear = true" argument to CHeapBitMap's
constructor to be able to opt-out of this behavior.
Bug: https://bugs.openjdk.java.net/browse/JDK-8201647
Webrev: http://cr.openjdk.java.net/~pliden/8201647/webrev.0
/Per
From stefan.karlsson at oracle.com Tue Apr 17 12:41:55 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 17 Apr 2018 14:41:55 +0200
Subject: RFR: 8201647: Make initial clearing of CHeapBitMap optional
In-Reply-To: <336cf9d0-0c71-0a01-8c4f-51103c39acc3@oracle.com>
References: <336cf9d0-0c71-0a01-8c4f-51103c39acc3@oracle.com>
Message-ID: <dd99170e-6798-b211-8c20-13ff66a95683@oracle.com>
Looks good.
StefanK
On 2018-04-17 14:38, Per Liden wrote:
> CHeapBitMap objects will by default clear the underlying bitmap during
> construction. In ZGC we don't want mark bitmaps to be cleared on
> construction, since we instead do this lazily during concurrent marking.
>
> This patch adds a "bool clear = true" argument to CHeapBitMap's
> constructor to be able to opt-out of this behavior.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201647
> Webrev: http://cr.openjdk.java.net/~pliden/8201647/webrev.0
>
> /Per
From per.liden at oracle.com Tue Apr 17 12:49:42 2018
From: per.liden at oracle.com (Per Liden)
Date: Tue, 17 Apr 2018 14:49:42 +0200
Subject: RFR: 8201647: Make initial clearing of CHeapBitMap optional
In-Reply-To: <dd99170e-6798-b211-8c20-13ff66a95683@oracle.com>
References: <336cf9d0-0c71-0a01-8c4f-51103c39acc3@oracle.com>
<dd99170e-6798-b211-8c20-13ff66a95683@oracle.com>
Message-ID: <2aefb556-cfa7-8104-0698-b408acd68775@oracle.com>
Thanks Stefan!
/Per
On 04/17/2018 02:41 PM, Stefan Karlsson wrote:
> Looks good.
>
> StefanK
>
> On 2018-04-17 14:38, Per Liden wrote:
>> CHeapBitMap objects will by default clear the underlying bitmap during
>> construction. In ZGC we don't want mark bitmaps to be cleared on
>> construction, since we instead do this lazily during concurrent marking.
>>
>> This patch adds a "bool clear = true" argument to CHeapBitMap's
>> constructor to be able to opt-out of this behavior.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201647
>> Webrev: http://cr.openjdk.java.net/~pliden/8201647/webrev.0
>>
>> /Per
From kim.barrett at oracle.com Tue Apr 17 12:57:31 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 17 Apr 2018 08:57:31 -0400
Subject: RFR: 8201647: Make initial clearing of CHeapBitMap optional
In-Reply-To: <336cf9d0-0c71-0a01-8c4f-51103c39acc3@oracle.com>
References: <336cf9d0-0c71-0a01-8c4f-51103c39acc3@oracle.com>
Message-ID: <CFCCD73F-79CD-4DB5-A093-FCEC1403B2B2@oracle.com>
> On Apr 17, 2018, at 8:38 AM, Per Liden <per.liden at oracle.com> wrote:
>
> CHeapBitMap objects will by default clear the underlying bitmap during construction. In ZGC we don't want mark bitmaps to be cleared on construction, since we instead do this lazily during concurrent marking.
>
> This patch adds a "bool clear = true" argument to CHeapBitMap's constructor to be able to opt-out of this behavior.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201647
> Webrev: http://cr.openjdk.java.net/~pliden/8201647/webrev.0
>
> /Per
Looks good.
From thomas.schatzl at oracle.com Tue Apr 17 12:58:31 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 17 Apr 2018 14:58:31 +0200
Subject: RFR: 8201647: Make initial clearing of CHeapBitMap optional
In-Reply-To: <336cf9d0-0c71-0a01-8c4f-51103c39acc3@oracle.com>
References: <336cf9d0-0c71-0a01-8c4f-51103c39acc3@oracle.com>
Message-ID: <1523969911.2369.6.camel@oracle.com>
Hi,
On Tue, 2018-04-17 at 14:38 +0200, Per Liden wrote:
> CHeapBitMap objects will by default clear the underlying bitmap
> during construction. In ZGC we don't want mark bitmaps to be cleared
> on construction, since we instead do this lazily during concurrent
> marking.
>
> This patch adds a "bool clear = true" argument to CHeapBitMap's
> constructor to be able to opt-out of this behavior.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201647
> Webrev: http://cr.openjdk.java.net/~pliden/8201647/webrev.0
>
> /Per
looks good.
Thomas
From stuart.monteith at linaro.org Tue Apr 17 13:17:29 2018
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Tue, 17 Apr 2018 14:17:29 +0100
Subject: RFR: 8201647: Make initial clearing of CHeapBitMap optional
In-Reply-To: <336cf9d0-0c71-0a01-8c4f-51103c39acc3@oracle.com>
References: <336cf9d0-0c71-0a01-8c4f-51103c39acc3@oracle.com>
Message-ID: <CAEGA6kZt3hyg1j5yCzvMs--rHymuNSruvNkV9_VDW3pOqWu0LQ@mail.gmail.com>
Not that I'm a reviewer, but that looks good to me.
On 17 April 2018 at 13:38, Per Liden <per.liden at oracle.com> wrote:
> CHeapBitMap objects will by default clear the underlying bitmap during
> construction. In ZGC we don't want mark bitmaps to be cleared on
> construction, since we instead do this lazily during concurrent marking.
>
> This patch adds a "bool clear = true" argument to CHeapBitMap's constructor
> to be able to opt-out of this behavior.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201647
> Webrev: http://cr.openjdk.java.net/~pliden/8201647/webrev.0
>
> /Per
From christoph.langer at sap.com Tue Apr 17 14:48:28 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 17 Apr 2018 14:48:28 +0000
Subject: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
Message-ID: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
Hi,
can you please review a fix proposal for defaultStream::write(const char* s, size_t len).
Bug: https://bugs.openjdk.java.net/browse/JDK-8201649
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201649.0/
I have seen occurrences of truncated buffers which don't need to happen.
Thanks and best regards
Christoph
From glaubitz at physik.fu-berlin.de Tue Apr 17 15:23:34 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 17 Apr 2018 17:23:34 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <7ebf0b4d-4e2a-f87e-be72-90d4e6490bf0@oracle.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<c2d2a3c6-86d3-3e0d-d6fd-18fde4e6c5cc@redhat.com>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
<6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
<CAA-vtUwnVXnRPkT6Waw=q3SsV+J33TYUmY-3MM76QBYMZ9DqJg@mail.gmail.com>
<43f7de51-4fd9-3dac-2e23-f40ce3e7b4c0@physik.fu-berlin.de>
<3ea48b20-8d19-18f4-40e5-d8beb6c35461@physik.fu-berlin.de>
<49cd1bbe-0243-d34e-7990-7e727e3e509a@physik.fu-berlin.de>
<935e41ee-9618-24a8-b7e9-8a149e112006@oracle.com>
<7ebf0b4d-4e2a-f87e-be72-90d4e6490bf0@oracle.com>
Message-ID: <27273295-9d1b-a8a6-851b-a60705d5c27e@physik.fu-berlin.de>
On 04/17/2018 02:33 AM, David Holmes wrote:
> Though also see:
>
> https://bugs.openjdk.java.net/browse/JDK-8201592
>
> which seems to be the same secondary crash - but can't comment on the primary one.
This seems to be theculprit: http://hg.openjdk.java.net/jdk/hs/rev/0ce0ac68ace7
And this is a potential fix, although I need to perform more testing:
diff --git a/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp b/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
index ef4ae04c119..958833305d9 100644
--- a/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
+++ b/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
@@ -373,7 +373,7 @@ inline static bool checkOverflow(sigcontext* uc,
}
inline static bool checkPollingPage(address pc, address fault, address* stub) {
- if (fault == os::get_polling_page()) {
+ if (os::is_poll_address(fault)) {
*stub = SharedRuntime::get_poll_stub(pc);
return true;
}
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From ChrisPhi at LGonQn.Org Tue Apr 17 15:46:32 2018
From: ChrisPhi at LGonQn.Org (Chris Phillips)
Date: Tue, 17 Apr 2018 11:46:32 -0400
Subject: [11]RFR(S): 8201509: Zero : S390x (S390 and not _LP64) atomic_copy64
inline assembler is wrong.
Message-ID: <2061faf8-b9f3-4559-4774-d55f450e0de8@LGonQn.Org>
Hi,
Please review this small but significant change to Zero only code
related to S390 (31bit) Zero self-build failures.
Bug: https://bugs.openjdk.java.net/browse/JDK-8201509
webrev: http://cr.openjdk.java.net/~chrisphi/JDK-8201509/webrev.1
Cheers!
Chris Phillips @ Red Hat in T.O.
From thomas.stuefe at gmail.com Tue Apr 17 15:48:33 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 17 Apr 2018 17:48:33 +0200
Subject: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
In-Reply-To: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
References: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
Message-ID: <CAA-vtUz48xUdXQzDEAuS2JDdnis7n2pAjfJ52dgFkhKskNoX9Q@mail.gmail.com>
Hi Christoph,
I do not understand jio_print() at all. I think it is just wrong: if a
vfprintf hook is set, it prints to the defaultStream::output_stream(),
otherwise to defaultStream::output_fd()? Isnt that the same? Compare
this to jio_vfprintf(), which does the same logic, but correctly
prints to the vfprintf hook if it is set.
I would propose to get rid of jio_print() altogether and replace the
few callers of it (all in ostream.cpp) with this:
jio_printf("%s", string);
which does the same, but correctly.
Best Regards, Thomas
On Tue, Apr 17, 2018 at 4:48 PM, Langer, Christoph
<christoph.langer at sap.com> wrote:
> Hi,
>
> can you please review a fix proposal for defaultStream::write(const char* s, size_t len).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201649
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201649.0/
>
> I have seen occurrences of truncated buffers which don't need to happen.
>
> Thanks and best regards
> Christoph
>
From coleen.phillimore at oracle.com Tue Apr 17 16:02:15 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 17 Apr 2018 12:02:15 -0400
Subject: RFR (M) 8201556: Disallow reading oops in ClassLoaderData if unloading
Message-ID: <c22b8e6c-69e4-34bf-11d2-cc75c30204b8@oracle.com>
Summary: Move class_loader oop to an OopHandle, and assert that holder
is alive when getting class_loader.
open webrev at http://cr.openjdk.java.net/~coleenp/8201556.01/webrev
bug link https://bugs.openjdk.java.net/browse/JDK-8201556
Tested with mach5 tiers 1-7.
Thanks,
Coleen
From shade at redhat.com Tue Apr 17 16:04:18 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 17 Apr 2018 18:04:18 +0200
Subject: [8u-dev] RFR (S) JDK-8165489: Missing G1 barrier in
Unsafe_GetObjectVolatile
In-Reply-To: <d2dda517-c90f-ef67-38d5-c60c2eb102dd@oracle.com>
References: <53443eaa-fbbd-1238-b4c5-6373e43535ca@redhat.com>
<20180416134127.GA2862@vimes>
<c75bb567-be47-1f56-7fad-058627b6386b@redhat.com>
<d2dda517-c90f-ef67-38d5-c60c2eb102dd@oracle.com>
Message-ID: <e2b41392-e9f6-373a-2d9f-1a170f3a5f43@redhat.com>
OK, trying again with copying hotspot-dev at .
-Aleksey
On 04/16/2018 11:55 PM, David Holmes wrote:
> On 17/04/2018 12:05 AM, Aleksey Shipilev wrote:
>> Resending with better subject line, hopefully HS reviewers would see it.
>
> You need to send to hotspot alias to get a code review.
>
> David
>
>> -Aleksey
>>
>> On 04/16/2018 03:41 PM, Rob McKenna wrote:
>>> This change requires a codereview. As one hasn't been explicitly
>>> requested in the subject line, then HS reviewers may overlook this
>>> email.
>>>
>>> ???? -Rob
>>>
>>> On 13/04/18 18:45, Aleksey Shipilev wrote:
>>>> Hi,
>>>>
>>>> Please approve this fix for 8u. This improves G1 stability in 8u, and provides the base for
>>>> Shenandoah JDK 8 backport that piggybacks on G1 pre-barriers. The fix does not apply cleanly,
>>>> because there is also Unsafe_GetObject140 that needs fixing too.
>>>>
>>>> JDK 9 bug:
>>>> ?? https://bugs.openjdk.java.net/browse/JDK-8165489
>>>>
>>>> JDK 9 fix:
>>>> ?? http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a696583f5ddb
>>>>
>>>> JDK 8u fix:
>>>> ?? http://cr.openjdk.java.net/~shade/8165489-8u/webrev.01/
>>>>
>>>> Testing: x86_64 build, Shenandoah tests
>>>>
>>>> Thanks,
>>>> -Aleksey
>>
>>
From jesper.wilhelmsson at oracle.com Tue Apr 17 16:18:37 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Tue, 17 Apr 2018 18:18:37 +0200
Subject: jdk/jdk OPEN for HotSpot pushes (Re: Merging jdk/hs with jdk/jdk)
In-Reply-To: <952F85EF-BB76-4645-AC05-F843DB83881B@oracle.com>
References: <8819CAD3-AF29-463E-8A76-14440CF37D2B@oracle.com>
<952F85EF-BB76-4645-AC05-F843DB83881B@oracle.com>
Message-ID: <EEA812F6-693C-41D9-87B4-5F66B478F9DB@oracle.com>
Hi all,
The final jdk/hs integration has landed in jdk/jdk. jdk/jdk is now open for regular hotspot pushes.
These pages are still relevant for anyone pushing a hotspot change:
https://wiki.openjdk.java.net/display/HotSpot/How+to+work+with+HotSpot
https://wiki.openjdk.java.net/display/HotSpot/Pushing+a+HotSpot+change
I should update them though to say jdk/jdk instead of jdk/hs now.
Have a nice day!
/Jesper
> On 6 Apr 2018, at 02:37, jesper.wilhelmsson at oracle.com wrote:
>
> Hi all,
>
> I've gotten only positive feedback on this suggestion. The next step
> is to propose a date and outline the steps needed to go through with
> this change.
>
> The proposed date is April 12 (Thursday next week).
>
> The steps are:
>
> 1. jdk/hs is closed for pushes at 8 pm PST on April 12. This is when
> the hotspot nightly takes the snapshot of jdk/hs and starts the nightly
> tests. Please note that this is a hard deadline as the system is
> automated and will take the snapshot on time.
>
> 2. The Thursday snapshot will then be sent through the regular product
> integration testing (PIT) which runs over the weekend.
>
> 3. On Friday, April 13, the hotspot nightly and the hotspot CI (post
> integration testing) will be reconfigured to look at jdk/jdk.
>
> 4. The goal is to get the PIT analysis done by Wednesday, April 18.
> At this point the PIT snapshot will be pushed to jdk/jdk.
>
> 5. Once the PIT snapshot has been pushed to jdk/jdk, the jdk/jdk
> repository will be open for hotspot changes.
>
> In order to minimize the risk of merge conflicts when pushing the
> PIT snapshot to jdk/jdk, we will not open for hotspot changes
> until after the snapshot has been pushed.
>
> It is important that everyone that has a new change in the snapshot
> are available on Monday / Tuesday (April 16-17) to handle any
> problems that might arise as a result of the change. If you know that
> you will not be available these days, make sure someone else can
> cover your change, or hold your push until after the merge is done.
>
> Thanks,
> /Jesper
>
>
>> On 14 Mar 2018, at 22:00, jesper.wilhelmsson at oracle.com <mailto:jesper.wilhelmsson at oracle.com> wrote:
>>
>> All,
>>
>> Over the last couple of years we have left behind a graph of
>> integration forests where each component in the JVM had its own
>> line of development. Today all HotSpot development is done in the
>> same repository, jdk/hs [1]. As a result of merging we have seen
>> several positive effects, ranging from less confusion around
>> where and how to do things, and reduced time for fixes to
>> propagate, to significantly better cooperation between the
>> components, and improved quality of the product. We would like to
>> improve further and therefore we suggest to merge jdk/hs into
>> jdk/jdk [2].
>>
>> As before, we expect this change to build a stronger team spirit
>> between the merged areas, and contribute to less confusion -
>> especially around ramp down phases and similar. We also expect
>> further improvements in quality as changes that cause problems in
>> a different area are found faster and can be dealt with
>> immediately.
>>
>> In the same way as we did in the past, we suggest to try this out
>> as an experiment for at least two weeks (giving us some time to
>> adapt in case of issues). Monitoring and evaluation of the new
>> structure will take place continuously, with an option to revert
>> back if things do not work out. The experiment would keep going
>> for at least a few months, after which we will evaluate it and
>> depending on the results consider making it the new standard. If
>> so, the jdk/hs forest will eventually be retired. As part of this
>> merge we can also retire the newly setup submit-hs [3] repository
>> and do all testing using the submit repo based on jdk/jdk [4].
>>
>> Much like what we have done in the past we would leave the jdk/hs
>> forest around until we see if the experiment works out. We would
>> also lock it down so that no accidental pushes are made to
>> it. Once the jdk/hs forest is locked down, any work in flight
>> based on it would have to be rebased on jdk/jdk.
>>
>> We tried this approach during the last few months of JDK 10
>> development and it worked out fine there.
>>
>> Please let us know if you have any feedback or questions!
>>
>> Thanks,
>> /Jesper
>>
>> [1] http://hg.openjdk.java.net/jdk/hs <http://hg.openjdk.java.net/jdk/hs> <http://hg.openjdk.java.net/jdk/hs <http://hg.openjdk.java.net/jdk/hs>>
>> [2] http://hg.openjdk.java.net/jdk/jdk <http://hg.openjdk.java.net/jdk/jdk> <http://hg.openjdk.java.net/jdk/jdk <http://hg.openjdk.java.net/jdk/jdk>>
>> [3] http://hg.openjdk.java.net/jdk/submit-hs <http://hg.openjdk.java.net/jdk/submit-hs> <http://hg.openjdk.java.net/jdk/submit-hs <http://hg.openjdk.java.net/jdk/submit-hs>>
>> [4] http://hg.openjdk.java.net/jdk/submit <http://hg.openjdk.java.net/jdk/submit> <http://hg.openjdk.java.net/jdk/submit <http://hg.openjdk.java.net/jdk/submit>>
From vladimir.kozlov at oracle.com Tue Apr 17 16:53:49 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 17 Apr 2018 09:53:49 -0700
Subject: 8185505: AArch64: Port AOT
In-Reply-To: <57767253-4826-e5b4-d142-7990d7114704@redhat.com>
References: <b439eaf0-e026-7ff8-e832-3717368027e4@redhat.com>
<AM5PR0802MB2449400467C4E4042C3C6A6390B00@AM5PR0802MB2449.eurprd08.prod.outlook.com>
<57767253-4826-e5b4-d142-7990d7114704@redhat.com>
Message-ID: <4626be6e-7927-a8ad-dead-1c3a4fca3ec9@oracle.com>
On 4/16/18 2:03 AM, Andrew Haley wrote:
> On 04/16/2018 09:53 AM, Ningsheng Jian wrote:
>> I can see both the jdk patch and Graal PR contain changes of AArch64Assembler.java and AArch64MacroAssembler.java, but the changes looks somewhat different. How will they be synced?
>
> The changes to Graal in JDK do no more than allow OpenJDK to build. They
> are not called by anything, and will disappear at the next Graal import.
>
>> I noticed that in make/hotspot/lib/JvmFeatures.gmk line ~144, there's:
>>
>> JVM_EXCLUDE_FILES += \
>> compiledIC_aot_x86_64.cpp
>>
>> Do you want to add compiledIC_aot_aarch64.cpp to that list?
>
> I don't really know what this does, so I have no idea.
It was done when we did not support/build AOT on Win and MacOS. It also work when AOT is disabled in build: configure
--disable-aot
We have to exclude to AOT files to avoid build failure because they do not have #ifdef INCLUDE_AOT.
I think compiledIC_aot_aarch64.cpp should be added to exclude list too. And you can test you code with --disable-aot
Vladimir
>
>> I also found that _immutable_PIC and its getters/setters are in the INCLUDE_AOT block, but some of their uses are not:
>>
>> src/hotspot/cpu/aarch64/compiledIC_aarch64.cpp:
>>
>> 61 if (cbuf.immutable_PIC()) {
>>
>> src/hotspot/share/jvmci/jvmciCodeInstaller.cpp:
>>
>> 594 buffer.set_immutable_PIC(_immutable_pic_compilation);
>> 628 buffer.set_immutable_PIC(_immutable_pic_compilation);
>
> Thank you. For the sake of consistency I will change it.
>
From kim.barrett at oracle.com Tue Apr 17 18:20:32 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 17 Apr 2018 14:20:32 -0400
Subject: RFR (M) 8201556: Disallow reading oops in ClassLoaderData if
unloading
In-Reply-To: <c22b8e6c-69e4-34bf-11d2-cc75c30204b8@oracle.com>
References: <c22b8e6c-69e4-34bf-11d2-cc75c30204b8@oracle.com>
Message-ID: <4B8BE39B-8FE8-4A13-B3E3-E183834DC499@oracle.com>
> On Apr 17, 2018, at 12:02 PM, coleen.phillimore at oracle.com wrote:
>
> Summary: Move class_loader oop to an OopHandle, and assert that holder is alive when getting class_loader.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8201556.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8201556
>
> Tested with mach5 tiers 1-7.
>
> Thanks,
> Coleen
------------------------------------------------------------------------------
src/hotspot/share/classfile/classLoaderData.hpp
86 static ClassLoaderData* add_to_graph(Handle class_laoder, bool anonymous);
s/laoder/loader/
------------------------------------------------------------------------------
src/hotspot/share/classfile/classLoaderData.hpp
411 Klass* class_loader_klass() const { return _class_loader_klass; }
412 Symbol* class_loader_name() const { return _class_loader_name; }
Maybe assert that the member being read has been set, since the
initialization happens sometime after construction. Or will that
maybe not work because of the annoying null-class-loader?
------------------------------------------------------------------------------
src/hotspot/share/classfile/classLoaderData.cpp
942 p2i(this), p2i((void *)_class_loader.ptr_raw()), loader_name());
Why is there a (void*) cast on the class loader ptr?
------------------------------------------------------------------------------
src/hotspot/share/oops/klass.hpp
640 bool is_loader_alive(BoolObjectClosure* is_alive) const { return !class_loader_data()->is_unloading(); }
Is this just so you can defer updating is_loader_alive callers to
another RFE?
------------------------------------------------------------------------------
From coleen.phillimore at oracle.com Tue Apr 17 19:37:09 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 17 Apr 2018 15:37:09 -0400
Subject: RFR (M) 8201556: Disallow reading oops in ClassLoaderData if
unloading
In-Reply-To: <4B8BE39B-8FE8-4A13-B3E3-E183834DC499@oracle.com>
References: <c22b8e6c-69e4-34bf-11d2-cc75c30204b8@oracle.com>
<4B8BE39B-8FE8-4A13-B3E3-E183834DC499@oracle.com>
Message-ID: <8c5c97a7-430a-4e85-fe62-6041e95d42a2@oracle.com>
On 4/17/18 2:20 PM, Kim Barrett wrote:
>> On Apr 17, 2018, at 12:02 PM, coleen.phillimore at oracle.com wrote:
>>
>> Summary: Move class_loader oop to an OopHandle, and assert that holder is alive when getting class_loader.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8201556.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8201556
>>
>> Tested with mach5 tiers 1-7.
>>
>> Thanks,
>> Coleen
> ------------------------------------------------------------------------------
> src/hotspot/share/classfile/classLoaderData.hpp
> 86 static ClassLoaderData* add_to_graph(Handle class_laoder, bool anonymous);
>
> s/laoder/loader/
Thanks!
>
> ------------------------------------------------------------------------------
> src/hotspot/share/classfile/classLoaderData.hpp
> 411 Klass* class_loader_klass() const { return _class_loader_klass; }
> 412 Symbol* class_loader_name() const { return _class_loader_name; }
>
> Maybe assert that the member being read has been set, since the
> initialization happens sometime after construction. Or will that
> maybe not work because of the annoying null-class-loader?
It's null if the class loader is null, so I can't really assert it.
>
> ------------------------------------------------------------------------------
> src/hotspot/share/classfile/classLoaderData.cpp
> 942 p2i(this), p2i((void *)_class_loader.ptr_raw()), loader_name());
>
> Why is there a (void*) cast on the class loader ptr?
It was there.? I've removed the cast and am recompiling it.
>
> ------------------------------------------------------------------------------
> src/hotspot/share/oops/klass.hpp
> 640 bool is_loader_alive(BoolObjectClosure* is_alive) const { return !class_loader_data()->is_unloading(); }
>
> Is this just so you can defer updating is_loader_alive callers to
> another RFE?
Yes, see (please review!) this RFR:
RFR (M) 8201537: Remove is_alive closure from Klass::is_loader_alive()
This one should be first, and I'll merge these two lines to remove the
BoolObjectClosure.
Thanks!
Coleen
> ------------------------------------------------------------------------------
>
From glaubitz at physik.fu-berlin.de Tue Apr 17 19:48:33 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 17 Apr 2018 21:48:33 +0200
Subject: RFR: 8201616: Hotspot crashes on linux-sparc after 8189941
Message-ID: <485f9cdd-5deb-b59e-bcdf-9938606d98af@physik.fu-berlin.de>
Hi!
After having rebuilt OpenJDK several dozen times over several days and bisecting
for several hours today, I finally found the culprit for the segfault I am seeing
on linux-sparc which is JDK-8189941 [1].
Looking at the SPARC-specific changes [2], I noticed the change in os_solaris_sparc.cpp
to use os::is_poll_address() instead of os::get_polling_page() when a SIGSEGV is caught
which was missing in os_linux_sparc.cpp.
Thus, I made that change to os_linux_sparc.cpp as well:
diff --git a/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp b/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
--- a/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
+++ b/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
@@ -374,7 +374,7 @@
}
inline static bool checkPollingPage(address pc, address fault, address* stub) {
- if (fault == os::get_polling_page()) {
+ if (os::is_poll_address(fault)) {
*stub = SharedRuntime::get_poll_stub(pc);
return true;
}
And voila, the crash is gone \o/.
Please review the change in [3] and invite me over a cold one at next FOSDEM :-).
Cheers,
Adrian
> [1] http://hg.openjdk.java.net/jdk/jdk/rev/0ce0ac68ace7
> [2] http://hg.openjdk.java.net/jdk/jdk/rev/0ce0ac68ace7#l39.1
> [3] http://cr.openjdk.java.net/~glaubitz/8201616/webrev.00/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From kim.barrett at oracle.com Tue Apr 17 19:50:11 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 17 Apr 2018 15:50:11 -0400
Subject: RFR (M) 8201556: Disallow reading oops in ClassLoaderData if
unloading
In-Reply-To: <8c5c97a7-430a-4e85-fe62-6041e95d42a2@oracle.com>
References: <c22b8e6c-69e4-34bf-11d2-cc75c30204b8@oracle.com>
<4B8BE39B-8FE8-4A13-B3E3-E183834DC499@oracle.com>
<8c5c97a7-430a-4e85-fe62-6041e95d42a2@oracle.com>
Message-ID: <FCE05308-A3B4-43E3-8BE4-84C06BC71FDE@oracle.com>
> On Apr 17, 2018, at 3:37 PM, coleen.phillimore at oracle.com wrote:
>
>
>
> On 4/17/18 2:20 PM, Kim Barrett wrote:
>>> On Apr 17, 2018, at 12:02 PM, coleen.phillimore at oracle.com wrote:
>>>
>>> Summary: Move class_loader oop to an OopHandle, and assert that holder is alive when getting class_loader.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8201556.01/webrev
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8201556
>>>
>>> Tested with mach5 tiers 1-7.
>>>
>>> Thanks,
>>> Coleen
>> ------------------------------------------------------------------------------
>> src/hotspot/share/classfile/classLoaderData.hpp
>> 86 static ClassLoaderData* add_to_graph(Handle class_laoder, bool anonymous);
>>
>> s/laoder/loader/
>
> Thanks!
>>
>> ------------------------------------------------------------------------------
>> src/hotspot/share/classfile/classLoaderData.hpp
>> 411 Klass* class_loader_klass() const { return _class_loader_klass; }
>> 412 Symbol* class_loader_name() const { return _class_loader_name; }
>>
>> Maybe assert that the member being read has been set, since the
>> initialization happens sometime after construction. Or will that
>> maybe not work because of the annoying null-class-loader?
>
> It's null if the class loader is null, so I can't really assert it.
>>
>> ------------------------------------------------------------------------------
>> src/hotspot/share/classfile/classLoaderData.cpp
>> 942 p2i(this), p2i((void *)_class_loader.ptr_raw()), loader_name());
>>
>> Why is there a (void*) cast on the class loader ptr?
>
> It was there. I've removed the cast and am recompiling it.
>>
>> ------------------------------------------------------------------------------
>> src/hotspot/share/oops/klass.hpp
>> 640 bool is_loader_alive(BoolObjectClosure* is_alive) const { return !class_loader_data()->is_unloading(); }
>>
>> Is this just so you can defer updating is_loader_alive callers to
>> another RFE?
>
> Yes, see (please review!) this RFR:
>
> RFR (M) 8201537: Remove is_alive closure from Klass::is_loader_alive()
>
> This one should be first, and I'll merge these two lines to remove the BoolObjectClosure.
>
> Thanks!
> Coleen
>> ------------------------------------------------------------------------------
Based on those answers, looks good.
From thomas.stuefe at gmail.com Tue Apr 17 20:17:08 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 17 Apr 2018 22:17:08 +0200
Subject: RFR: 8201616: Hotspot crashes on linux-sparc after 8189941
In-Reply-To: <485f9cdd-5deb-b59e-bcdf-9938606d98af@physik.fu-berlin.de>
References: <485f9cdd-5deb-b59e-bcdf-9938606d98af@physik.fu-berlin.de>
Message-ID: <CAA-vtUy1a2CMoA_JGN6HuKyi_BXs+N9DrbmSYEgquK-_5PNbrg@mail.gmail.com>
Good catch! Proposed fix is fine.
You earned that beer :)
..Thomas
On Tue, Apr 17, 2018 at 9:48 PM, John Paul Adrian Glaubitz
<glaubitz at physik.fu-berlin.de> wrote:
> Hi!
>
> After having rebuilt OpenJDK several dozen times over several days and bisecting
> for several hours today, I finally found the culprit for the segfault I am seeing
> on linux-sparc which is JDK-8189941 [1].
>
> Looking at the SPARC-specific changes [2], I noticed the change in os_solaris_sparc.cpp
> to use os::is_poll_address() instead of os::get_polling_page() when a SIGSEGV is caught
> which was missing in os_linux_sparc.cpp.
>
> Thus, I made that change to os_linux_sparc.cpp as well:
>
> diff --git a/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp b/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
> --- a/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
> +++ b/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
> @@ -374,7 +374,7 @@
> }
>
> inline static bool checkPollingPage(address pc, address fault, address* stub) {
> - if (fault == os::get_polling_page()) {
> + if (os::is_poll_address(fault)) {
> *stub = SharedRuntime::get_poll_stub(pc);
> return true;
> }
>
> And voila, the crash is gone \o/.
>
> Please review the change in [3] and invite me over a cold one at next FOSDEM :-).
>
> Cheers,
> Adrian
>
>> [1] http://hg.openjdk.java.net/jdk/jdk/rev/0ce0ac68ace7
>> [2] http://hg.openjdk.java.net/jdk/jdk/rev/0ce0ac68ace7#l39.1
>> [3] http://cr.openjdk.java.net/~glaubitz/8201616/webrev.00/
>
> --
> .''`. John Paul Adrian Glaubitz
> : :' : Debian Developer - glaubitz at debian.org
> `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From vladimir.kozlov at oracle.com Tue Apr 17 20:28:36 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 17 Apr 2018 13:28:36 -0700
Subject: RFR: 8201616: Hotspot crashes on linux-sparc after 8189941
In-Reply-To: <485f9cdd-5deb-b59e-bcdf-9938606d98af@physik.fu-berlin.de>
References: <485f9cdd-5deb-b59e-bcdf-9938606d98af@physik.fu-berlin.de>
Message-ID: <c3b3ca55-492e-c138-00cd-8b6823f51c9f@oracle.com>
Looks good. Thank you for tracking this down.
Regards,
Vladimir
On 4/17/18 12:48 PM, John Paul Adrian Glaubitz wrote:
> Hi!
>
> After having rebuilt OpenJDK several dozen times over several days and bisecting
> for several hours today, I finally found the culprit for the segfault I am seeing
> on linux-sparc which is JDK-8189941 [1].
>
> Looking at the SPARC-specific changes [2], I noticed the change in os_solaris_sparc.cpp
> to use os::is_poll_address() instead of os::get_polling_page() when a SIGSEGV is caught
> which was missing in os_linux_sparc.cpp.
>
> Thus, I made that change to os_linux_sparc.cpp as well:
>
> diff --git a/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp b/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
> --- a/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
> +++ b/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
> @@ -374,7 +374,7 @@
> }
>
> inline static bool checkPollingPage(address pc, address fault, address* stub) {
> - if (fault == os::get_polling_page()) {
> + if (os::is_poll_address(fault)) {
> *stub = SharedRuntime::get_poll_stub(pc);
> return true;
> }
>
> And voila, the crash is gone \o/.
>
> Please review the change in [3] and invite me over a cold one at next FOSDEM :-).
>
> Cheers,
> Adrian
>
>> [1] http://hg.openjdk.java.net/jdk/jdk/rev/0ce0ac68ace7
>> [2] http://hg.openjdk.java.net/jdk/jdk/rev/0ce0ac68ace7#l39.1
>> [3] http://cr.openjdk.java.net/~glaubitz/8201616/webrev.00/
>
From david.holmes at oracle.com Tue Apr 17 21:05:01 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Apr 2018 07:05:01 +1000
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <27273295-9d1b-a8a6-851b-a60705d5c27e@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<5f354d2a-2dec-3f60-0f20-3d6533258cf0@oracle.com>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
<6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
<CAA-vtUwnVXnRPkT6Waw=q3SsV+J33TYUmY-3MM76QBYMZ9DqJg@mail.gmail.com>
<43f7de51-4fd9-3dac-2e23-f40ce3e7b4c0@physik.fu-berlin.de>
<3ea48b20-8d19-18f4-40e5-d8beb6c35461@physik.fu-berlin.de>
<49cd1bbe-0243-d34e-7990-7e727e3e509a@physik.fu-berlin.de>
<935e41ee-9618-24a8-b7e9-8a149e112006@oracle.com>
<7ebf0b4d-4e2a-f87e-be72-90d4e6490bf0@oracle.com>
<27273295-9d1b-a8a6-851b-a60705d5c27e@physik.fu-berlin.de>
Message-ID: <43e06d17-aba3-5110-1692-96cd061f0c14@oracle.com>
On 18/04/2018 1:23 AM, John Paul Adrian Glaubitz wrote:
> On 04/17/2018 02:33 AM, David Holmes wrote:
>> Though also see:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8201592
>>
>> which seems to be the same secondary crash - but can't comment on the
>> primary one.
> This seems to be theculprit:
> http://hg.openjdk.java.net/jdk/hs/rev/0ce0ac68ace7
So you can run okay with -XX:-ThreadLocalHandshakes ?
David
> And this is a potential fix, although I need to perform more testing:
>
> diff --git a/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
> b/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
> index ef4ae04c119..958833305d9 100644
> --- a/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
> +++ b/src/hotspot/os_cpu/linux_sparc/os_linux_sparc.cpp
> @@ -373,7 +373,7 @@ inline static bool checkOverflow(sigcontext* uc,
> ?}
>
> ?inline static bool checkPollingPage(address pc, address fault,
> address* stub) {
> -? if (fault == os::get_polling_page()) {
> +? if (os::is_poll_address(fault)) {
> ???? *stub = SharedRuntime::get_poll_stub(pc);
> ???? return true;
> ?? }
>
> Adrian
>
From glaubitz at physik.fu-berlin.de Tue Apr 17 21:08:12 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 17 Apr 2018 23:08:12 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <43e06d17-aba3-5110-1692-96cd061f0c14@oracle.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<d4fcc9e9-cb2e-1a4c-2b7a-4d3d577e6ce5@redhat.com>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
<6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
<CAA-vtUwnVXnRPkT6Waw=q3SsV+J33TYUmY-3MM76QBYMZ9DqJg@mail.gmail.com>
<43f7de51-4fd9-3dac-2e23-f40ce3e7b4c0@physik.fu-berlin.de>
<3ea48b20-8d19-18f4-40e5-d8beb6c35461@physik.fu-berlin.de>
<49cd1bbe-0243-d34e-7990-7e727e3e509a@physik.fu-berlin.de>
<935e41ee-9618-24a8-b7e9-8a149e112006@oracle.com>
<7ebf0b4d-4e2a-f87e-be72-90d4e6490bf0@oracle.com>
<27273295-9d1b-a8a6-851b-a60705d5c27e@physik.fu-berlin.de>
<43e06d17-aba3-5110-1692-96cd061f0c14@oracle.com>
Message-ID: <6690f389-9f49-6ce4-c957-5f64e52afd69@physik.fu-berlin.de>
On 04/17/2018 11:05 PM, David Holmes wrote:
>> This seems to be theculprit: http://hg.openjdk.java.net/jdk/hs/rev/0ce0ac68ace7
>
> So you can run okay with -XX:-ThreadLocalHandshakes ?
A HellWorld runs fine although I don't know whether that verifies anything:
glaubitz at deb4g:/srv/glaubitz$ hs/build/linux-sparcv9-normal-server-release/jdk/bin/java -XX:-ThreadLocalHandshakes HelloWorld
Hello, World
glaubitz at deb4g:/srv/glaubitz$
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From david.holmes at oracle.com Tue Apr 17 21:17:08 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Apr 2018 07:17:08 +1000
Subject: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
In-Reply-To: <CAA-vtUz48xUdXQzDEAuS2JDdnis7n2pAjfJ52dgFkhKskNoX9Q@mail.gmail.com>
References: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
<CAA-vtUz48xUdXQzDEAuS2JDdnis7n2pAjfJ52dgFkhKskNoX9Q@mail.gmail.com>
Message-ID: <b65af851-d138-42b2-847a-fd6650a1767b@oracle.com>
On 18/04/2018 1:48 AM, Thomas St?fe wrote:
> Hi Christoph,
>
> I do not understand jio_print() at all. I think it is just wrong: if a
> vfprintf hook is set, it prints to the defaultStream::output_stream(),
> otherwise to defaultStream::output_fd()? Isnt that the same? Compare
> this to jio_vfprintf(), which does the same logic, but correctly
> prints to the vfprintf hook if it is set.
If there is a hook it does a formatted print: jio_print -> jio_fprintf
-> jio_vfprintf -> Arguments::vfprintf_hook()
else it does a raw write.
Now why it does this is another matter. I have no idea. But I wouldn't
suggest changing it just because I don't know why it's done the way it is.
David
> I would propose to get rid of jio_print() altogether and replace the
> few callers of it (all in ostream.cpp) with this:
>
> jio_printf("%s", string);
>
> which does the same, but correctly.
>
> Best Regards, Thomas
>
> On Tue, Apr 17, 2018 at 4:48 PM, Langer, Christoph
> <christoph.langer at sap.com> wrote:
>> Hi,
>>
>> can you please review a fix proposal for defaultStream::write(const char* s, size_t len).
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201649
>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201649.0/
>>
>> I have seen occurrences of truncated buffers which don't need to happen.
>>
>> Thanks and best regards
>> Christoph
>>
From vladimir.kozlov at oracle.com Tue Apr 17 23:12:00 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 17 Apr 2018 16:12:00 -0700
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
fast_path_end
In-Reply-To: <CAF9BGBwBgyOoJTfJU_YmqYJgSZ+1985yx_sSMJC4wNJELw1XDQ@mail.gmail.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
<fca2bf81-0e8d-ffce-8203-080c07afb323@oracle.com>
<3AAB892A-CE21-492C-ABA2-182EF9316F06@oracle.com>
<CAF9BGBz-=JqbaJ37B5G35u3Ziei53fjhf=JMaWFd06WeZUCLfQ@mail.gmail.com>
<CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
<3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>
<CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>
<5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
<CAF9BGBxEPXLTiyD-xG_ECyveyW0PXQL0+-z7jkw3Rv4QrkkszQ@mail.gmail.com>
<ec1a3e0e-ca9b-8668-b260-1fd3e612b7f7@oracle.com>
<CAF9BGBy-LBKCwJHQPdAQ65VRcSFBwVkk9dm8MLC_nrefE_JdEw@mail.gmail.com>
<e6528c19-5691-1215-1ac5-0349801b79b5@oracle.com>
<CAF9BGBwBgyOoJTfJU_YmqYJgSZ+1985yx_sSMJC4wNJELw1XDQ@mail.gmail.com>
Message-ID: <e63675e1-d693-cd25-75b2-32b593e266a2@oracle.com>
Hi JC,
Yes, from the beginning such changes should be discussed on common hotspot-dev list since all
Hotspot's parts are affected.
Graal specific question could be send to hotspot-compiler-dev list with [Graal] in subject.
I looked on JEP's changes http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.02/ to understand how
it works.
Few questions about proposed JEP changes so I can understand it.
You introducing new TLAB end for sampling and adjust it so that allocations in JITed code and
Interpreter it will trigger slow path allocation where you do sampling. Right?
Do all changes to _end, _actual_end and other TLAB fields happen during slow allocation?
I am concern about concurrent accesses to these fields from other threads if you have them (I don't
see).
Renaming. I am fine with renaming if it helps to understand code better. I agree with proposed
changes to fields name:
_current_end
_allocation_end
But, as Dean, I would suggest to keep names of access functions. This way we can say that allocation
code in Interpreter and JITed code stay the same.
You may need only new method to access _allocation_end in places which look for real end of TLAB.
Regards,
Vladimir
On 4/16/18 4:42 PM, JC Beyler wrote:
> Hi Dean,
>
> I think perhaps this is also an attempt to figure out the naming of all
> this because naming (or renaming like here) is often the start of big
> conversations :).
>
> Originally, in the JEP-331 work, I had left the _end field as is and, by
> doing so, this whole renaming webrev goes away. However, if we do that,
> then the TLAB code contains:
>
> _end: the fast path end, can be the allocation end or the to-be-sampled end
> _allocation_end: the actual allocation end of the current TLAB
> hard_end: _allocation_end + reserved space
>
> With an early iteration of a webrev for JEP-331, a conversation occurred
> about whether or not that was clear or not and it was determined that this
> renaming was more clear:
>
> _current_end: the fast path end
> _allocation_end: the actual allocation end of the current TLAB
> reserved_end: _allocation_end + reserved space
>
> Because I'm trying to reduce the footprint of files changed, I pulled out
> the renaming changes into this webrev. While talking about it with the GC
> team, the renaming suggested became:
>
> _fast_path_end: the fast path end
> _allocation_end: the actual allocation end of the current TLAB
> hard_end: _allocation_end + reserved space
>
> Now, to be honest, any renaming or no renaming is fine by me. I like not
> renaming the fields to not change the code of every backend and Graal; I
> also like the fast_path_end rename due to it making the backend code easy
> to read as mentioned in the GC mailing lis thread.
>
> So there are two questions really:
> - Should we rename the _end field and thus provoke the changes in this
> webrev?
> - If we do want to change the field, should/could it go in an initial
> webrev or should it go in the JEP-331 webrev whenever/ifever it goes in?
> And if we do wait, could we at least converge on a renaming now so that
> this does not become a point of contention for that webrev's review?
>
> If I read your answer correctly:
> - You are saying that we should keep the _end field altogether; or at
> least only rename the field not the methods to access it, thus reducing the
> change scope.
> - You are also saying to wait for the JEP-331 webrev's final iteration
> and integrate it in one step
>
> Have I understood your answer correctly?
>
> Again, I am fine with renaming to whatever or not renaming at all. I just
> am trying to get forward progress here :)
>
> Thanks for your help!
> Jc
>
> On Mon, Apr 16, 2018 at 3:29 PM <dean.long at oracle.com> wrote:
>
>> Hi JC. Others might disagree, but I would vote "no" on doing this
>> renaming now, before the JEP, and even in the context of the JEP, I
>> don't think renaming the field requires renaming all the uses. The
>> compiler code is only interested in the fast path, so it's implicitly
>> understood. Also, if there is a fast_path_end(), then isn't it logical
>> to have fast_path_start() paired with it? ("start" is already
>> overloaded, but nobody is suggesting adding
>> allocation_start()/current_start()/hard_start() are they?). My opinion
>> is that it's fine the way it is.
>>
>> dl
>>
>> On 4/16/18 1:43 PM, JC Beyler wrote:
>>> Hi all,
>>>
>>> I've left the mail thread from the hotspot-gc-dev below for tracking
>>> purposes but will start a new request here.
>>>
>>> - I'm trying to push a renaming of a TLAB field to make my work for
>> JEP-331
>>> <http://openjdk.java.net/jeps/331> easier
>>> - There is an understanding that if JEP-331 does not make it, this
>> might
>>> be useless and I'll revert if that is what the community wants; however
>> the
>>> new name seems better anyway so perhaps not?
>>>
>>> - The webrev renames a field used across the various back-ends and Graal
>>> - The webrev is here:
>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.04/
>>>
>>> Could I please get some feedback on this?
>>>
>>> Thanks all for your help,
>>> Jc
>>>
>>>
>>>
>>> On Fri, Apr 13, 2018 at 2:37 AM Stefan Johansson <
>>> stefan.johansson at oracle.com> wrote:
>>>
>>>> Hi JC,
>>>>
>>>> I don't have a name, but I've looked at bit more at the failures and I
>>>> think they are unrelated and one of the local compiler engineers agree.
>>>>
>>>> I also ran some local testing and was not able to get any error with you
>>>> latest changes, but verified that it doens't work without the graal
>>>> parts. So they seem good. It might still be good to switch this over to
>>>> the general hotspot-dev list to let someone with Graal knowledge to look
>>>> at the change and make sure everything is correct.
>>>>
>>>> Thanks,
>>>> Stefan
>>>>
>>>>
>>>> On 2018-04-12 17:26, JC Beyler wrote:
>>>>> Hi Stefan,
>>>>>
>>>>> Thanks for testing :). I've renamed the bug title in the JBS and will
>>>>> emit a new webrev shortly. Do you have the name of a compiler engineer
>>>>> in mind or should I perhaps now move this conversation to the general
>>>>> hotspot-dev mailing list and ask there?
>>>>>
>>>>> The alternative is to add the compiler-mailing list to this email
>> thread
>>>>> and ask there before sending to the general list. What do you think is
>>>> best?
>>>>> Thanks for all your help,
>>>>> Jc
>>>>>
>>>>> On Thu, Apr 12, 2018 at 2:09 AM Stefan Johansson
>>>>> <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 2018-04-11 17:48, JC Beyler wrote:
>>>>> > Hi Stefan,
>>>>> >
>>>>> > Sorry about that, I must have missed adding the files or
>>>>> something. Here
>>>>> > is a webrev that added the changes for the SA file:
>>>>> > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/
>>>>> >
>>>>> No problem, this looks good. I kicked of a run in our test system
>> to
>>>>> get
>>>>> some more coverage and have tried to include some Graal testing.
>> I'll
>>>>> let you know the results once they are done.
>>>>>
>>>>> Please also update the bug title both in JBS and the changeset.
>>>>>
>>>>> Cheers,
>>>>> Stefan
>>>>>
>>>>> > I changed the method name, which propagated a change to:
>>>>> >
>>>>>
>>>>
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
>>>>> >
>>>>> > I tried testing your test file. It exists in my branch (if the
>>>>> same) under:
>>>>> > hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
>>>>> >
>>>>> > and interestingly (which generally means I did something
>> wrong),
>>>> it
>>>>> > passed before/after the change so I could not verify that this
>> is
>>>>> a test
>>>>> > showing that all is well in the world on my side. Any ideas of
>>>>> what I
>>>>> > did wrong?
>>>>> >
>>>>> > I did again test it for hotspot/jtreg/compiler/aot/ and
>>>>> > hotspot/jtreg/serviceability/jvmti and it passes those.
>>>>> >
>>>>> > Thanks for all your help,
>>>>> > Jc
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson
>>>>> > <stefan.johansson at oracle.com <mailto:
>> stefan.johansson at oracle.com>
>>>>> <mailto:stefan.johansson at oracle.com
>>>>> <mailto:stefan.johansson at oracle.com>>> wrote:
>>>>> >
>>>>> > Hi JC,
>>>>> >
>>>>> > On 2018-04-11 00:56, JC Beyler wrote:
>>>>> > > Small update:
>>>>> > >
>>>>> > > Here is the fixed webrev for the '{' that were out of
>>>>> alignment.
>>>>> > This
>>>>> > > passed release build JTREG
>>>>> for hotspot/jtreg/compiler/jvmti (just
>>>>> > to run
>>>>> > > something as a smoke screen)
>>>>> and hotspot/jtreg/compiler/aot/ (to
>>>>> > test
>>>>> > > Graal).
>>>>> > > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
>>>>> > >
>>>>> > I think this looks better, I agree that leaving _end is
>>>>> tempting to
>>>>> > avoid a lot of change, but I think this will be better in
>> the
>>>>> long run.
>>>>> >
>>>>> > I still miss the changes to make the SA work. To see a
>>>>> problem you
>>>>> > can run:
>>>>> > make CONF=fast run-test
>>>>> >
>> TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
>>>>> >
>>>>> > Cheers,
>>>>> > Stefan
>>>>> >
>>>>> > > Let me know what you think,
>>>>> > > Jc
>>>>> > >
>>>>> > > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler
>>>>> <jcbeyler at google.com <mailto:jcbeyler at google.com>
>>>>> > <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>
>>>>> > > <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com
>>>
>>>>> <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>>>
>> wrote:
>>>>> > >
>>>>> > > Hi Karen and Stefan,
>>>>> > >
>>>>> > > @Stefan: Naming is hard :)
>>>>> > > @Karen: thanks for the Graal comment, I fixed it in
>>>>> the new
>>>>> > webrev,
>>>>> > > let me know what you think :)
>>>>> > >
>>>>> > > I think the naming convention suggested in this
>> webrev
>>>>> came from
>>>>> > > conversations in for JEP-331 and I am actually
>>>> relatively
>>>>> > > indifferent to the final result (as long as we have
>>>>> some form of
>>>>> > > forward progress :)). To be honest, I'd also be
>> happy
>>>>> to just
>>>>> > leave
>>>>> > > _end as is for all architectures and Graal and have
>> a
>>>> new
>>>>> > > _allocation_end. However, during initial reviews of
>>>>> JEP-331
>>>>> > it was
>>>>> > > deemed complicated to understand:
>>>>> > >
>>>>> > > _end -> the _end or sampling end
>>>>> > > _allocation_end -> end pointer for the last possible
>>>>> allocation
>>>>> > > hard_end -> allocation end + reserved space
>>>>> > >
>>>>> > > That is how this naming came up and why hard_end
>> went
>>>> to
>>>>> > "reserved_end".
>>>>> > >
>>>>> > > I'm really indifferent, so I offer as a perusal:
>>>>> > > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
>>>>> > >
>>>>> > > I noticed a few problems of alignement of '{' so
>> I'll
>>>>> go fix
>>>>> > that.
>>>>> > > Basically this webrev does the following:
>>>>> > >
>>>>> > > - Uses fast_path_end instead of end
>>>>> > > - Reverts hard_end back to where it was
>>>>> > > - Adds the changes to Graal; there is a bunch of
>>>>> changes in Graal
>>>>> > > because Graal still contains a bit of code doing
>>>>> fasttlabrefills.
>>>>> > >
>>>>> > > Let me know what you think!
>>>>> > >
>>>>> > > Thanks,
>>>>> > > Jc
>>>>> > >
>>>>> > >
>>>>> > > On Tue, Apr 10, 2018 at 6:56 AM Karen Kinnear
>>>>> > > <karen.kinnear at oracle.com
>>>>> <mailto:karen.kinnear at oracle.com> <mailto:
>> karen.kinnear at oracle.com
>>>>> <mailto:karen.kinnear at oracle.com>>
>>>>> > <mailto:karen.kinnear at oracle.com
>>>>> <mailto:karen.kinnear at oracle.com> <mailto:
>> karen.kinnear at oracle.com
>>>>> <mailto:karen.kinnear at oracle.com>>>>
>>>>> > wrote:
>>>>> > >
>>>>> > > Hi JC,
>>>>> > >
>>>>> > > A comment about Graal. The impact on Graal for
>> this
>>>>> > particular
>>>>> > > change would be to break it - so you?ll need
>>>>> > > to complete the Graal changes for this renaming.
>>>>> That isn?t
>>>>> > > optional or something that could be a
>> follow-on. It
>>>>> > > is not ok to break a feature, even an
>> experimental
>>>>> one.
>>>>> > We will
>>>>> > > discuss in the other thread potential phasing of
>>>>> adding
>>>>> > sampling.
>>>>> > >
>>>>> > > I did not do a thorough search -you can do that
>> -
>>>>> I did find
>>>>> > > src/jdk.internal.vm.compiler/share/classes/
>>>>> > >
>>>>> >
>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>> > > public final int threadTlabOffset =
>>>>> > > getFieldOffset("Thread::_tlab", Integer.class,
>>>>> > > "ThreadLocalAllocBuffer");
>>>>> > >
>>>>> >
>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>> > > private final int
>>>>> threadLocalAllocBufferStartOffset =
>>>>> > > getFieldOffset("ThreadLocalAllocBuffer::_start",
>>>>> > Integer.class,
>>>>> > > "HeapWord*");
>>>>> > >
>>>>> >
>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>> > > private final int
>>>> threadLocalAllocBufferEndOffset =
>>>>> > > getFieldOffset("ThreadLocalAllocBuffer::_end",
>>>>> Integer.class,
>>>>> > > "HeapWord*");
>>>>> > >
>>>>> >
>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>> > > private final int
>>>> threadLocalAllocBufferTopOffset =
>>>>> > > getFieldOffset("ThreadLocalAllocBuffer::_top",
>>>>> Integer.class,
>>>>> > > "HeapWord*");
>>>>> > >
>>>>> >
>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>> > > private final int
>>>>> threadLocalAllocBufferPfTopOffset =
>>>>> > >
>> getFieldOffset("ThreadLocalAllocBuffer::_pf_top",
>>>>> > Integer.class,
>>>>> > > "HeapWord*");
>>>>> > >
>>>>> >
>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>> > > private final int
>>>>> > threadLocalAllocBufferSlowAllocationsOffset
>>>>> > > =
>>>>> getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
>>>>> > > Integer.class, "unsigned");
>>>>> > >
>>>>> >
>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>> > > private final int
>>>>> > threadLocalAllocBufferFastRefillWasteOffset
>>>>> > > =
>>>>> >
>> getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
>>>>> > > Integer.class, "unsigned");
>>>>> > >
>>>>> >
>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>> > > private final int
>>>>> > threadLocalAllocBufferNumberOfRefillsOffset
>>>>> > > =
>>>>> >
>> getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
>>>>> > > Integer.class, "unsigned");
>>>>> > >
>>>>> >
>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>> > > private final int
>>>>> > > threadLocalAllocBufferRefillWasteLimitOffset =
>>>>> > >
>>>>> getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
>>>>> > > Integer.class, "size_t");
>>>>> > >
>>>>> >
>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>> > > private final int
>>>>> > threadLocalAllocBufferDesiredSizeOffset =
>>>>> > >
>>>>> getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
>>>>> > > Integer.class, "size_t");
>>>>> > >
>>>>> >
>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>> > > public final int tlabAlignmentReserve =
>>>>> > >
>>>>> >
>>>>>
>>>>
>> getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
>>>>> > > Integer.class, "size_t?);
>>>>> > >
>>>>> > > hope this helps,
>>>>> > > Karen
>>>>> > >
>>>>> > >> On Apr 10, 2018, at 7:04 AM, Stefan Johansson
>>>>> > >> <stefan.johansson at oracle.com
>>>>> <mailto:stefan.johansson at oracle.com>
>>>>> > <mailto:stefan.johansson at oracle.com
>>>>> <mailto:stefan.johansson at oracle.com>>
>>>>> > >> <mailto:stefan.johansson at oracle.com
>>>>> <mailto:stefan.johansson at oracle.com>
>>>>> > <mailto:stefan.johansson at oracle.com
>>>>> <mailto:stefan.johansson at oracle.com>>>> wrote:
>>>>> > >>
>>>>> > >> Hi JC,
>>>>> > >>
>>>>> > >> I realize that the names have been discussed
>>>>> before but I'm
>>>>> > >> leaning towards suggesting something new. We
>>>>> discussed this
>>>>> > >> briefly here in the office and others might
>> have
>>>>> different
>>>>> > >> opinions. One point that came up is that if we
>> do
>>>>> this
>>>>> > change
>>>>> > >> and change all usages of
>>>>> JavaThread::tlab_end_offset() it
>>>>> > >> would be good to make sure the new name is
>> good.
>>>>> To us
>>>>> > >> _current_end is not very descriptive, but
>> naming
>>>>> is hard and
>>>>> > >> the best we could come up with is
>> _fast_path_end
>>>>> which would
>>>>> > >> give the code:
>>>>> > >> cmpptr(end, Address(thread,
>>>>> > >> JavaThread::tlab_fast_path_end_offset()));
>>>>> > >> jcc(Assembler::above, slow_case);
>>>>> > >>
>>>>> > >> I think this reads pretty good and is fairly
>>>>> clear. If we do
>>>>> > >> this rename I think you can re-use _end in
>> JEP-331
>>>>> > instead of
>>>>> > >> calling it _allocation_end. But that is a later
>>>>> review :)
>>>>> > >>
>>>>> > >> Also, is there a good reason for renaming
>>>>> hard_end() to
>>>>> > >> reserved_end()?
>>>>> > >>
>>>>> > >> One additional thing, you need to update the SA
>>>>> to reflect
>>>>> > >> this change. I think the only place you need to
>>>>> fix is in:
>>>>> > >>
>>>>> >
>>>>>
>>>>
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
>>>>> > >>
>>>>> > >> Thanks,
>>>>> > >> Stefan
>>>>> > >>
>>>>> > >> On 2018-04-09 19:24, JC Beyler wrote:
>>>>> > >>> Hi all,
>>>>> > >>> Small pre-amble to this request:
>>>>> > >>> In my work to try to get a heap sampler in
>>>>> OpenJDK (via JEP
>>>>> > >>> 331
>>>>> > <https://bugs.openjdk.java.net/browse/JDK-8171119>), I'm
>>>>> > >>> trying to reduce the footprint of my change so
>>>>> that the
>>>>> > >>> integration can be easier. I was told that
>>>>> generally a JEP
>>>>> > >>> webrev should be feature complete and go in
>>>> at-once.
>>>>> > However,
>>>>> > >>> with the change touching quite a bit of
>> various
>>>> code
>>>>> > pieces,
>>>>> > >>> I was trying to figure out what could be
>>>>> separated as not
>>>>> > >>> "part of the feature".
>>>>> > >>> I asked around and said that perhaps a
>> solution
>>>>> would be to
>>>>> > >>> cut up the renaming of TLAB's end field that I
>>>>> do in that
>>>>> > >>> webrev. Because I'm renaming a field in TLAB
>>>> used by
>>>>> > various
>>>>> > >>> backends for that work, I have to update every
>>>>> architecture
>>>>> > >>> dependent code to reflect it.
>>>>> > >>> I entirely understand that perhaps this is not
>>>>> in the
>>>>> > habits
>>>>> > >>> and very potentially might not be the way
>> things
>>>> are
>>>>> > >>> generally done. If so, I apologize and let me
>>>>> know if you
>>>>> > >>> would not want this to go in separately :)
>>>>> > >>> Final note: there is still a chance JEP-331
>> does
>>>>> not go in.
>>>>> > >>> If it does not, we can leave the new name in
>>>>> place or I'll
>>>>> > >>> happily revert it. I can even create an issue
>> to
>>>>> track this
>>>>> > >>> if that makes it easier for all.
>>>>> > >>> End of the pre-amble.
>>>>> > >>> The 33-line change webrev in question is here:
>>>>> > >>>
>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
>>>>> > >>> I fixed all the architectures and JVMCI and
>> ran
>>>>> a few
>>>>> > sanity
>>>>> > >>> tests to ensure I had not missed anything.
>>>>> > >>> Thanks for your help and I hope this is not
>> too
>>>> much
>>>>> > trouble,
>>>>> > >>> Jc
>>>>> > >>> Ps: there is a graal change that needs to
>> happen
>>>>> but I was
>>>>> > >>> not sure who/where
>> <https://teams.googleplex.com/u/where>
>>>> <https://teams.googleplex.com/u/where>
>>>>> <https://teams.googleplex.com/u/where>
>>>>> > <https://teams.googleplex.com/u/where>
>>>>> > <https://teams.googleplex.com/u/where> to
>>>>> > >>> ask about it. I was told it could happen in a
>>>>> separate
>>>>> > >>> webrev. Can anyone point me to the right
>>>> direction?
>>>>> > Should it
>>>>> > >>> just be hotspot-compiler-dev?
>>>>> > >
>>>>> >
>>>>>
>>
>>
From dean.long at oracle.com Tue Apr 17 23:23:56 2018
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Tue, 17 Apr 2018 16:23:56 -0700
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
fast_path_end
In-Reply-To: <CAF9BGBwBgyOoJTfJU_YmqYJgSZ+1985yx_sSMJC4wNJELw1XDQ@mail.gmail.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
<fca2bf81-0e8d-ffce-8203-080c07afb323@oracle.com>
<3AAB892A-CE21-492C-ABA2-182EF9316F06@oracle.com>
<CAF9BGBz-=JqbaJ37B5G35u3Ziei53fjhf=JMaWFd06WeZUCLfQ@mail.gmail.com>
<CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
<3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>
<CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>
<5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
<CAF9BGBxEPXLTiyD-xG_ECyveyW0PXQL0+-z7jkw3Rv4QrkkszQ@mail.gmail.com>
<ec1a3e0e-ca9b-8668-b260-1fd3e612b7f7@oracle.com>
<CAF9BGBy-LBKCwJHQPdAQ65VRcSFBwVkk9dm8MLC_nrefE_JdEw@mail.gmail.com>
<e6528c19-5691-1215-1ac5-0349801b79b5@oracle.com>
<CAF9BGBwBgyOoJTfJU_YmqYJgSZ+1985yx_sSMJC4wNJELw1XDQ@mail.gmail.com>
Message-ID: <c6e1503c-5ea1-4774-7dc1-3aa3c4868f14@oracle.com>
On 4/16/18 4:42 PM, JC Beyler wrote:
> If I read your answer correctly:
> ? ?- You are saying that we should keep the _end field altogether; or
> at least only rename the field not the methods to access it, thus
> reducing the change scope.
> ? ? ?- You are also saying to wait for the JEP-331 webrev's final
> iteration and integrate it in one step
Yes, my suggestion is to not rename access methods now, and try to avoid
it in the future.? I'm OK with renaming the field(s), but I don't have a
strong opinion on what the new names should be.
dl
From jcbeyler at google.com Tue Apr 17 23:51:12 2018
From: jcbeyler at google.com (JC Beyler)
Date: Tue, 17 Apr 2018 23:51:12 +0000
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
fast_path_end
In-Reply-To: <e63675e1-d693-cd25-75b2-32b593e266a2@oracle.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
<fca2bf81-0e8d-ffce-8203-080c07afb323@oracle.com>
<3AAB892A-CE21-492C-ABA2-182EF9316F06@oracle.com>
<CAF9BGBz-=JqbaJ37B5G35u3Ziei53fjhf=JMaWFd06WeZUCLfQ@mail.gmail.com>
<CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
<3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>
<CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>
<5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
<CAF9BGBxEPXLTiyD-xG_ECyveyW0PXQL0+-z7jkw3Rv4QrkkszQ@mail.gmail.com>
<ec1a3e0e-ca9b-8668-b260-1fd3e612b7f7@oracle.com>
<CAF9BGBy-LBKCwJHQPdAQ65VRcSFBwVkk9dm8MLC_nrefE_JdEw@mail.gmail.com>
<e6528c19-5691-1215-1ac5-0349801b79b5@oracle.com>
<CAF9BGBwBgyOoJTfJU_YmqYJgSZ+1985yx_sSMJC4wNJELw1XDQ@mail.gmail.com>
<e63675e1-d693-cd25-75b2-32b593e266a2@oracle.com>
Message-ID: <CAF9BGBz3g4yXMjf9TxrqLdMbfaswoa3U13qYTEUtv-mZCDMd8Q@mail.gmail.com>
Hi Vladimir and Dean,
@Dean: seems that Vladimir is in agreement with you for renaming just the
field and not the method names so ack to your answer that came at the same
time :)
> Yes, from the beginning such changes should be discussed on common
> hotspot-dev list since all
> Hotspot's parts are affected.
>
Sorry, being new to the scene, most of the conversation had been going on
in serviceability-dev.
>
> Graal specific question could be send to hotspot-compiler-dev list with
> [Graal] in subject.
>
> I looked on JEP's changes
> http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.02/ to understand how
> it works.
>
> Few questions about proposed JEP changes so I can understand it.
>
> You introducing new TLAB end for sampling and adjust it so that
> allocations in JITed code and
> Interpreter it will trigger slow path allocation where you do sampling.
> Right?
>
Yes that is correct; if sampling is enabled of course. Btw, this is the current
webrev <http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.15/>.
>
> Do all changes to _end, _actual_end and other TLAB fields happen during
> slow allocation?
>
Yes, to that effect, with Robbin's help, we finalized deprecating the
FastTLabRefill via JDK-8194084
<https://bugs.openjdk.java.net/browse/JDK-8194084>. Seems like I/we missed
that Graal does this as well. I filed GRAAL-64
<https://bugs.openjdk.java.net/browse/GRAAL-64> to not forget that Graal
would need to get that fixed.
>
> I am concern about concurrent accesses to these fields from other threads
> if you have them (I don't
> see).
>
Yes that is why we deprecated the FastTlabRefill. Other threads should not
be changing the thread local data structure so I don't see an issue there.
The major issue was that the fast paths could change the tlab without going
via the slowpath.
I had a fix to detect this issue but removed it once JDK-8194084 was done;
Graal was missed in that work so that is why if sampling were enabled with
Graal, there is a chance things would break currently. That will get fixed
via GRAAL-64 <https://bugs.openjdk.java.net/browse/GRAAL-64> whether it is
rendering the code also obsolete and going to the slowpath or whether it is
adding my fix again to detect a fastpath TLAB reallocation happened.
>
> Renaming. I am fine with renaming if it helps to understand code better. I
> agree with proposed
> changes to fields name:
>
> _current_end
> _allocation_end
>
> But, as Dean, I would suggest to keep names of access functions. This way
> we can say that allocation
> code in Interpreter and JITed code stay the same.
>
Sounds good to me, then in that case, this webrev will disappear, which
also makes me happy, since it simplifies a lot of things (and reduces code
change).
>
> You may need only new method to access _allocation_end in places which
> look for real end of TLAB.
>
I think I like better not to add it. If no one is using it, there should be
no reason to add it? By not adding it, it also makes any future wish to
have it a nice indicator of: hey why do you want to see this? Same as
hard_end btw which is not visible. Am I missing something?
So to summarize, the current consensus:
- _end can be renamed either to _current_end or _fast_path_end; that is
still up to a vote and choice :)
- the access method end() and tlab_end_offset() remain the same to not
modify JIT/interpreter codes
If all agree to this, then the consequences are:
- JDK-8201326 becomes useless
- The work for JEP-331 becomes smaller in terms of file changes
- I'll still be needing a decision on the renaming of the TLAB _end field
(current suggestions are _current_end and _fast_path_end).
Thanks for your help!
Jc
>
> Regards,
> Vladimir
>
> On 4/16/18 4:42 PM, JC Beyler wrote:
> > Hi Dean,
> >
> > I think perhaps this is also an attempt to figure out the naming of all
> > this because naming (or renaming like here) is often the start of big
> > conversations :).
> >
> > Originally, in the JEP-331 work, I had left the _end field as is and, by
> > doing so, this whole renaming webrev goes away. However, if we do that,
> > then the TLAB code contains:
> >
> > _end: the fast path end, can be the allocation end or the to-be-sampled
> end
> > _allocation_end: the actual allocation end of the current TLAB
> > hard_end: _allocation_end + reserved space
> >
> > With an early iteration of a webrev for JEP-331, a conversation occurred
> > about whether or not that was clear or not and it was determined that
> this
> > renaming was more clear:
> >
> > _current_end: the fast path end
> > _allocation_end: the actual allocation end of the current TLAB
> > reserved_end: _allocation_end + reserved space
> >
> > Because I'm trying to reduce the footprint of files changed, I pulled out
> > the renaming changes into this webrev. While talking about it with the GC
> > team, the renaming suggested became:
> >
> > _fast_path_end: the fast path end
> > _allocation_end: the actual allocation end of the current TLAB
> > hard_end: _allocation_end + reserved space
> >
> > Now, to be honest, any renaming or no renaming is fine by me. I like not
> > renaming the fields to not change the code of every backend and Graal; I
> > also like the fast_path_end rename due to it making the backend code easy
> > to read as mentioned in the GC mailing lis thread.
> >
> > So there are two questions really:
> > - Should we rename the _end field and thus provoke the changes in
> this
> > webrev?
> > - If we do want to change the field, should/could it go in an initial
> > webrev or should it go in the JEP-331 webrev whenever/ifever it goes in?
> > And if we do wait, could we at least converge on a renaming now so that
> > this does not become a point of contention for that webrev's review?
> >
> > If I read your answer correctly:
> > - You are saying that we should keep the _end field altogether; or
> at
> > least only rename the field not the methods to access it, thus reducing
> the
> > change scope.
> > - You are also saying to wait for the JEP-331 webrev's final
> iteration
> > and integrate it in one step
> >
> > Have I understood your answer correctly?
> >
> > Again, I am fine with renaming to whatever or not renaming at all. I just
> > am trying to get forward progress here :)
> >
> > Thanks for your help!
> > Jc
> >
> > On Mon, Apr 16, 2018 at 3:29 PM <dean.long at oracle.com> wrote:
> >
> >> Hi JC. Others might disagree, but I would vote "no" on doing this
> >> renaming now, before the JEP, and even in the context of the JEP, I
> >> don't think renaming the field requires renaming all the uses. The
> >> compiler code is only interested in the fast path, so it's implicitly
> >> understood. Also, if there is a fast_path_end(), then isn't it logical
> >> to have fast_path_start() paired with it? ("start" is already
> >> overloaded, but nobody is suggesting adding
> >> allocation_start()/current_start()/hard_start() are they?). My opinion
> >> is that it's fine the way it is.
> >>
> >> dl
> >>
> >> On 4/16/18 1:43 PM, JC Beyler wrote:
> >>> Hi all,
> >>>
> >>> I've left the mail thread from the hotspot-gc-dev below for tracking
> >>> purposes but will start a new request here.
> >>>
> >>> - I'm trying to push a renaming of a TLAB field to make my work for
> >> JEP-331
> >>> <http://openjdk.java.net/jeps/331> easier
> >>> - There is an understanding that if JEP-331 does not make it, this
> >> might
> >>> be useless and I'll revert if that is what the community wants; however
> >> the
> >>> new name seems better anyway so perhaps not?
> >>>
> >>> - The webrev renames a field used across the various back-ends and
> Graal
> >>> - The webrev is here:
> >>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.04/
> >>>
> >>> Could I please get some feedback on this?
> >>>
> >>> Thanks all for your help,
> >>> Jc
> >>>
> >>>
> >>>
> >>> On Fri, Apr 13, 2018 at 2:37 AM Stefan Johansson <
> >>> stefan.johansson at oracle.com> wrote:
> >>>
> >>>> Hi JC,
> >>>>
> >>>> I don't have a name, but I've looked at bit more at the failures and I
> >>>> think they are unrelated and one of the local compiler engineers
> agree.
> >>>>
> >>>> I also ran some local testing and was not able to get any error with
> you
> >>>> latest changes, but verified that it doens't work without the graal
> >>>> parts. So they seem good. It might still be good to switch this over
> to
> >>>> the general hotspot-dev list to let someone with Graal knowledge to
> look
> >>>> at the change and make sure everything is correct.
> >>>>
> >>>> Thanks,
> >>>> Stefan
> >>>>
> >>>>
> >>>> On 2018-04-12 17:26, JC Beyler wrote:
> >>>>> Hi Stefan,
> >>>>>
> >>>>> Thanks for testing :). I've renamed the bug title in the JBS and will
> >>>>> emit a new webrev shortly. Do you have the name of a compiler
> engineer
> >>>>> in mind or should I perhaps now move this conversation to the general
> >>>>> hotspot-dev mailing list and ask there?
> >>>>>
> >>>>> The alternative is to add the compiler-mailing list to this email
> >> thread
> >>>>> and ask there before sending to the general list. What do you think
> is
> >>>> best?
> >>>>> Thanks for all your help,
> >>>>> Jc
> >>>>>
> >>>>> On Thu, Apr 12, 2018 at 2:09 AM Stefan Johansson
> >>>>> <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>>
> >>>> wrote:
> >>>>>
> >>>>>
> >>>>> On 2018-04-11 17:48, JC Beyler wrote:
> >>>>> > Hi Stefan,
> >>>>> >
> >>>>> > Sorry about that, I must have missed adding the files or
> >>>>> something. Here
> >>>>> > is a webrev that added the changes for the SA file:
> >>>>> > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/
> >>>>> >
> >>>>> No problem, this looks good. I kicked of a run in our test
> system
> >> to
> >>>>> get
> >>>>> some more coverage and have tried to include some Graal
> testing.
> >> I'll
> >>>>> let you know the results once they are done.
> >>>>>
> >>>>> Please also update the bug title both in JBS and the changeset.
> >>>>>
> >>>>> Cheers,
> >>>>> Stefan
> >>>>>
> >>>>> > I changed the method name, which propagated a change to:
> >>>>> >
> >>>>>
> >>>>
> >>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
> >>>>> >
> >>>>> > I tried testing your test file. It exists in my branch (if
> the
> >>>>> same) under:
> >>>>> > hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
> >>>>> >
> >>>>> > and interestingly (which generally means I did something
> >> wrong),
> >>>> it
> >>>>> > passed before/after the change so I could not verify that
> this
> >> is
> >>>>> a test
> >>>>> > showing that all is well in the world on my side. Any ideas
> of
> >>>>> what I
> >>>>> > did wrong?
> >>>>> >
> >>>>> > I did again test it for hotspot/jtreg/compiler/aot/ and
> >>>>> > hotspot/jtreg/serviceability/jvmti and it passes those.
> >>>>> >
> >>>>> > Thanks for all your help,
> >>>>> > Jc
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>> > On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson
> >>>>> > <stefan.johansson at oracle.com <mailto:
> >> stefan.johansson at oracle.com>
> >>>>> <mailto:stefan.johansson at oracle.com
> >>>>> <mailto:stefan.johansson at oracle.com>>> wrote:
> >>>>> >
> >>>>> > Hi JC,
> >>>>> >
> >>>>> > On 2018-04-11 00:56, JC Beyler wrote:
> >>>>> > > Small update:
> >>>>> > >
> >>>>> > > Here is the fixed webrev for the '{' that were out of
> >>>>> alignment.
> >>>>> > This
> >>>>> > > passed release build JTREG
> >>>>> for hotspot/jtreg/compiler/jvmti (just
> >>>>> > to run
> >>>>> > > something as a smoke screen)
> >>>>> and hotspot/jtreg/compiler/aot/ (to
> >>>>> > test
> >>>>> > > Graal).
> >>>>> > >
> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
> >>>>> > >
> >>>>> > I think this looks better, I agree that leaving _end is
> >>>>> tempting to
> >>>>> > avoid a lot of change, but I think this will be better
> in
> >> the
> >>>>> long run.
> >>>>> >
> >>>>> > I still miss the changes to make the SA work. To see a
> >>>>> problem you
> >>>>> > can run:
> >>>>> > make CONF=fast run-test
> >>>>> >
> >> TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
> >>>>> >
> >>>>> > Cheers,
> >>>>> > Stefan
> >>>>> >
> >>>>> > > Let me know what you think,
> >>>>> > > Jc
> >>>>> > >
> >>>>> > > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler
> >>>>> <jcbeyler at google.com <mailto:jcbeyler at google.com>
> >>>>> > <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com
> >>
> >>>>> > > <mailto:jcbeyler at google.com <mailto:
> jcbeyler at google.com
> >>>
> >>>>> <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>>>
> >> wrote:
> >>>>> > >
> >>>>> > > Hi Karen and Stefan,
> >>>>> > >
> >>>>> > > @Stefan: Naming is hard :)
> >>>>> > > @Karen: thanks for the Graal comment, I fixed it
> in
> >>>>> the new
> >>>>> > webrev,
> >>>>> > > let me know what you think :)
> >>>>> > >
> >>>>> > > I think the naming convention suggested in this
> >> webrev
> >>>>> came from
> >>>>> > > conversations in for JEP-331 and I am actually
> >>>> relatively
> >>>>> > > indifferent to the final result (as long as we
> have
> >>>>> some form of
> >>>>> > > forward progress :)). To be honest, I'd also be
> >> happy
> >>>>> to just
> >>>>> > leave
> >>>>> > > _end as is for all architectures and Graal and
> have
> >> a
> >>>> new
> >>>>> > > _allocation_end. However, during initial reviews
> of
> >>>>> JEP-331
> >>>>> > it was
> >>>>> > > deemed complicated to understand:
> >>>>> > >
> >>>>> > > _end -> the _end or sampling end
> >>>>> > > _allocation_end -> end pointer for the last
> possible
> >>>>> allocation
> >>>>> > > hard_end -> allocation end + reserved space
> >>>>> > >
> >>>>> > > That is how this naming came up and why hard_end
> >> went
> >>>> to
> >>>>> > "reserved_end".
> >>>>> > >
> >>>>> > > I'm really indifferent, so I offer as a perusal:
> >>>>> > >
> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
> >>>>> > >
> >>>>> > > I noticed a few problems of alignement of '{' so
> >> I'll
> >>>>> go fix
> >>>>> > that.
> >>>>> > > Basically this webrev does the following:
> >>>>> > >
> >>>>> > > - Uses fast_path_end instead of end
> >>>>> > > - Reverts hard_end back to where it was
> >>>>> > > - Adds the changes to Graal; there is a bunch of
> >>>>> changes in Graal
> >>>>> > > because Graal still contains a bit of code doing
> >>>>> fasttlabrefills.
> >>>>> > >
> >>>>> > > Let me know what you think!
> >>>>> > >
> >>>>> > > Thanks,
> >>>>> > > Jc
> >>>>> > >
> >>>>> > >
> >>>>> > > On Tue, Apr 10, 2018 at 6:56 AM Karen Kinnear
> >>>>> > > <karen.kinnear at oracle.com
> >>>>> <mailto:karen.kinnear at oracle.com> <mailto:
> >> karen.kinnear at oracle.com
> >>>>> <mailto:karen.kinnear at oracle.com>>
> >>>>> > <mailto:karen.kinnear at oracle.com
> >>>>> <mailto:karen.kinnear at oracle.com> <mailto:
> >> karen.kinnear at oracle.com
> >>>>> <mailto:karen.kinnear at oracle.com>>>>
> >>>>> > wrote:
> >>>>> > >
> >>>>> > > Hi JC,
> >>>>> > >
> >>>>> > > A comment about Graal. The impact on Graal
> for
> >> this
> >>>>> > particular
> >>>>> > > change would be to break it - so you?ll need
> >>>>> > > to complete the Graal changes for this
> renaming.
> >>>>> That isn?t
> >>>>> > > optional or something that could be a
> >> follow-on. It
> >>>>> > > is not ok to break a feature, even an
> >> experimental
> >>>>> one.
> >>>>> > We will
> >>>>> > > discuss in the other thread potential
> phasing of
> >>>>> adding
> >>>>> > sampling.
> >>>>> > >
> >>>>> > > I did not do a thorough search -you can do
> that
> >> -
> >>>>> I did find
> >>>>> > > src/jdk.internal.vm.compiler/share/classes/
> >>>>> > >
> >>>>> >
> >>>>>
> >>>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>> > > public final int threadTlabOffset =
> >>>>> > > getFieldOffset("Thread::_tlab",
> Integer.class,
> >>>>> > > "ThreadLocalAllocBuffer");
> >>>>> > >
> >>>>> >
> >>>>>
> >>>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>> > > private final int
> >>>>> threadLocalAllocBufferStartOffset =
> >>>>> > >
> getFieldOffset("ThreadLocalAllocBuffer::_start",
> >>>>> > Integer.class,
> >>>>> > > "HeapWord*");
> >>>>> > >
> >>>>> >
> >>>>>
> >>>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>> > > private final int
> >>>> threadLocalAllocBufferEndOffset =
> >>>>> > >
> getFieldOffset("ThreadLocalAllocBuffer::_end",
> >>>>> Integer.class,
> >>>>> > > "HeapWord*");
> >>>>> > >
> >>>>> >
> >>>>>
> >>>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>> > > private final int
> >>>> threadLocalAllocBufferTopOffset =
> >>>>> > >
> getFieldOffset("ThreadLocalAllocBuffer::_top",
> >>>>> Integer.class,
> >>>>> > > "HeapWord*");
> >>>>> > >
> >>>>> >
> >>>>>
> >>>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>> > > private final int
> >>>>> threadLocalAllocBufferPfTopOffset =
> >>>>> > >
> >> getFieldOffset("ThreadLocalAllocBuffer::_pf_top",
> >>>>> > Integer.class,
> >>>>> > > "HeapWord*");
> >>>>> > >
> >>>>> >
> >>>>>
> >>>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>> > > private final int
> >>>>> > threadLocalAllocBufferSlowAllocationsOffset
> >>>>> > > =
> >>>>> getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
> >>>>> > > Integer.class, "unsigned");
> >>>>> > >
> >>>>> >
> >>>>>
> >>>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>> > > private final int
> >>>>> > threadLocalAllocBufferFastRefillWasteOffset
> >>>>> > > =
> >>>>> >
> >> getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
> >>>>> > > Integer.class, "unsigned");
> >>>>> > >
> >>>>> >
> >>>>>
> >>>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>> > > private final int
> >>>>> > threadLocalAllocBufferNumberOfRefillsOffset
> >>>>> > > =
> >>>>> >
> >> getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
> >>>>> > > Integer.class, "unsigned");
> >>>>> > >
> >>>>> >
> >>>>>
> >>>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>> > > private final int
> >>>>> > > threadLocalAllocBufferRefillWasteLimitOffset
> =
> >>>>> > >
> >>>>> getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
> >>>>> > > Integer.class, "size_t");
> >>>>> > >
> >>>>> >
> >>>>>
> >>>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>> > > private final int
> >>>>> > threadLocalAllocBufferDesiredSizeOffset =
> >>>>> > >
> >>>>> getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
> >>>>> > > Integer.class, "size_t");
> >>>>> > >
> >>>>> >
> >>>>>
> >>>>
> >>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>> > > public final int tlabAlignmentReserve =
> >>>>> > >
> >>>>> >
> >>>>>
> >>>>
> >>
> getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
> >>>>> > > Integer.class, "size_t?);
> >>>>> > >
> >>>>> > > hope this helps,
> >>>>> > > Karen
> >>>>> > >
> >>>>> > >> On Apr 10, 2018, at 7:04 AM, Stefan
> Johansson
> >>>>> > >> <stefan.johansson at oracle.com
> >>>>> <mailto:stefan.johansson at oracle.com>
> >>>>> > <mailto:stefan.johansson at oracle.com
> >>>>> <mailto:stefan.johansson at oracle.com>>
> >>>>> > >> <mailto:stefan.johansson at oracle.com
> >>>>> <mailto:stefan.johansson at oracle.com>
> >>>>> > <mailto:stefan.johansson at oracle.com
> >>>>> <mailto:stefan.johansson at oracle.com>>>> wrote:
> >>>>> > >>
> >>>>> > >> Hi JC,
> >>>>> > >>
> >>>>> > >> I realize that the names have been discussed
> >>>>> before but I'm
> >>>>> > >> leaning towards suggesting something new. We
> >>>>> discussed this
> >>>>> > >> briefly here in the office and others might
> >> have
> >>>>> different
> >>>>> > >> opinions. One point that came up is that if
> we
> >> do
> >>>>> this
> >>>>> > change
> >>>>> > >> and change all usages of
> >>>>> JavaThread::tlab_end_offset() it
> >>>>> > >> would be good to make sure the new name is
> >> good.
> >>>>> To us
> >>>>> > >> _current_end is not very descriptive, but
> >> naming
> >>>>> is hard and
> >>>>> > >> the best we could come up with is
> >> _fast_path_end
> >>>>> which would
> >>>>> > >> give the code:
> >>>>> > >> cmpptr(end, Address(thread,
> >>>>> > >> JavaThread::tlab_fast_path_end_offset()));
> >>>>> > >> jcc(Assembler::above, slow_case);
> >>>>> > >>
> >>>>> > >> I think this reads pretty good and is fairly
> >>>>> clear. If we do
> >>>>> > >> this rename I think you can re-use _end in
> >> JEP-331
> >>>>> > instead of
> >>>>> > >> calling it _allocation_end. But that is a
> later
> >>>>> review :)
> >>>>> > >>
> >>>>> > >> Also, is there a good reason for renaming
> >>>>> hard_end() to
> >>>>> > >> reserved_end()?
> >>>>> > >>
> >>>>> > >> One additional thing, you need to update
> the SA
> >>>>> to reflect
> >>>>> > >> this change. I think the only place you
> need to
> >>>>> fix is in:
> >>>>> > >>
> >>>>> >
> >>>>>
> >>>>
> >>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
> >>>>> > >>
> >>>>> > >> Thanks,
> >>>>> > >> Stefan
> >>>>> > >>
> >>>>> > >> On 2018-04-09 19:24, JC Beyler wrote:
> >>>>> > >>> Hi all,
> >>>>> > >>> Small pre-amble to this request:
> >>>>> > >>> In my work to try to get a heap sampler in
> >>>>> OpenJDK (via JEP
> >>>>> > >>> 331
> >>>>> > <https://bugs.openjdk.java.net/browse/JDK-8171119>),
> I'm
> >>>>> > >>> trying to reduce the footprint of my
> change so
> >>>>> that the
> >>>>> > >>> integration can be easier. I was told that
> >>>>> generally a JEP
> >>>>> > >>> webrev should be feature complete and go in
> >>>> at-once.
> >>>>> > However,
> >>>>> > >>> with the change touching quite a bit of
> >> various
> >>>> code
> >>>>> > pieces,
> >>>>> > >>> I was trying to figure out what could be
> >>>>> separated as not
> >>>>> > >>> "part of the feature".
> >>>>> > >>> I asked around and said that perhaps a
> >> solution
> >>>>> would be to
> >>>>> > >>> cut up the renaming of TLAB's end field
> that I
> >>>>> do in that
> >>>>> > >>> webrev. Because I'm renaming a field in
> TLAB
> >>>> used by
> >>>>> > various
> >>>>> > >>> backends for that work, I have to update
> every
> >>>>> architecture
> >>>>> > >>> dependent code to reflect it.
> >>>>> > >>> I entirely understand that perhaps this is
> not
> >>>>> in the
> >>>>> > habits
> >>>>> > >>> and very potentially might not be the way
> >> things
> >>>> are
> >>>>> > >>> generally done. If so, I apologize and let
> me
> >>>>> know if you
> >>>>> > >>> would not want this to go in separately :)
> >>>>> > >>> Final note: there is still a chance JEP-331
> >> does
> >>>>> not go in.
> >>>>> > >>> If it does not, we can leave the new name
> in
> >>>>> place or I'll
> >>>>> > >>> happily revert it. I can even create an
> issue
> >> to
> >>>>> track this
> >>>>> > >>> if that makes it easier for all.
> >>>>> > >>> End of the pre-amble.
> >>>>> > >>> The 33-line change webrev in question is
> here:
> >>>>> > >>>
> >> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
> >>>>> > >>> I fixed all the architectures and JVMCI and
> >> ran
> >>>>> a few
> >>>>> > sanity
> >>>>> > >>> tests to ensure I had not missed anything.
> >>>>> > >>> Thanks for your help and I hope this is not
> >> too
> >>>> much
> >>>>> > trouble,
> >>>>> > >>> Jc
> >>>>> > >>> Ps: there is a graal change that needs to
> >> happen
> >>>>> but I was
> >>>>> > >>> not sure who/where
> <https://teams.googleplex.com/u/where>
> >> <https://teams.googleplex.com/u/where>
> >>>> <https://teams.googleplex.com/u/where>
> >>>>> <https://teams.googleplex.com/u/where>
> >>>>> > <https://teams.googleplex.com/u/where>
> >>>>> > <https://teams.googleplex.com/u/where> to
> >>>>> > >>> ask about it. I was told it could happen
> in a
> >>>>> separate
> >>>>> > >>> webrev. Can anyone point me to the right
> >>>> direction?
> >>>>> > Should it
> >>>>> > >>> just be hotspot-compiler-dev?
> >>>>> > >
> >>>>> >
> >>>>>
> >>
> >>
>
From vladimir.kozlov at oracle.com Wed Apr 18 00:02:24 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 17 Apr 2018 17:02:24 -0700
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
fast_path_end
In-Reply-To: <CAF9BGBz3g4yXMjf9TxrqLdMbfaswoa3U13qYTEUtv-mZCDMd8Q@mail.gmail.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
<fca2bf81-0e8d-ffce-8203-080c07afb323@oracle.com>
<3AAB892A-CE21-492C-ABA2-182EF9316F06@oracle.com>
<CAF9BGBz-=JqbaJ37B5G35u3Ziei53fjhf=JMaWFd06WeZUCLfQ@mail.gmail.com>
<CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
<3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>
<CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>
<5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
<CAF9BGBxEPXLTiyD-xG_ECyveyW0PXQL0+-z7jkw3Rv4QrkkszQ@mail.gmail.com>
<ec1a3e0e-ca9b-8668-b260-1fd3e612b7f7@oracle.com>
<CAF9BGBy-LBKCwJHQPdAQ65VRcSFBwVkk9dm8MLC_nrefE_JdEw@mail.gmail.com>
<e6528c19-5691-1215-1ac5-0349801b79b5@oracle.com>
<CAF9BGBwBgyOoJTfJU_YmqYJgSZ+1985yx_sSMJC4wNJELw1XDQ@mail.gmail.com>
<e63675e1-d693-cd25-75b2-32b593e266a2@oracle.com>
<CAF9BGBz3g4yXMjf9TxrqLdMbfaswoa3U13qYTEUtv-mZCDMd8Q@mail.gmail.com>
Message-ID: <735b3949-d9cd-3d37-ebb4-f59ee61f18ad@oracle.com>
> I think I like better not to add it. If no one is using it, there should be
> no reason to add it? By not adding it, it also makes any future wish to
> have it a nice indicator of: hey why do you want to see this? Same as
> hard_end btw which is not visible. Am I missing something?
I say "may" ;)
You don't need new function if there is no use.
>
> So to summarize, the current consensus:
> - _end can be renamed either to _current_end or _fast_path_end; that is
> still up to a vote and choice :)
Please, use _current_end. I was thinking about _sample_end but it does not reflect double usage.
> - the access method end() and tlab_end_offset() remain the same to not
> modify JIT/interpreter codes
>
> If all agree to this, then the consequences are:
> - JDK-8201326 becomes useless
> - The work for JEP-331 becomes smaller in terms of file changes
> - I'll still be needing a decision on the renaming of the TLAB _end field
> (current suggestions are _current_end and _fast_path_end).
Sounds good to me.
Thanks,
Vladimir
On 4/17/18 4:51 PM, JC Beyler wrote:
> Hi Vladimir and Dean,
>
> @Dean: seems that Vladimir is in agreement with you for renaming just the
> field and not the method names so ack to your answer that came at the same
> time :)
>
>
>> Yes, from the beginning such changes should be discussed on common
>> hotspot-dev list since all
>> Hotspot's parts are affected.
>>
>
> Sorry, being new to the scene, most of the conversation had been going on
> in serviceability-dev.
>
>
>>
>> Graal specific question could be send to hotspot-compiler-dev list with
>> [Graal] in subject.
>>
>> I looked on JEP's changes
>> http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.02/ to understand how
>> it works.
>>
>> Few questions about proposed JEP changes so I can understand it.
>>
>> You introducing new TLAB end for sampling and adjust it so that
>> allocations in JITed code and
>> Interpreter it will trigger slow path allocation where you do sampling.
>> Right?
>>
>
> Yes that is correct; if sampling is enabled of course. Btw, this is the current
> webrev <http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.15/>.
>
>
>>
>> Do all changes to _end, _actual_end and other TLAB fields happen during
>> slow allocation?
>>
>
> Yes, to that effect, with Robbin's help, we finalized deprecating the
> FastTLabRefill via JDK-8194084
> <https://bugs.openjdk.java.net/browse/JDK-8194084>. Seems like I/we missed
> that Graal does this as well. I filed GRAAL-64
> <https://bugs.openjdk.java.net/browse/GRAAL-64> to not forget that Graal
> would need to get that fixed.
>
>
>
>>
>> I am concern about concurrent accesses to these fields from other threads
>> if you have them (I don't
>> see).
>>
>
> Yes that is why we deprecated the FastTlabRefill. Other threads should not
> be changing the thread local data structure so I don't see an issue there.
> The major issue was that the fast paths could change the tlab without going
> via the slowpath.
>
> I had a fix to detect this issue but removed it once JDK-8194084 was done;
> Graal was missed in that work so that is why if sampling were enabled with
> Graal, there is a chance things would break currently. That will get fixed
> via GRAAL-64 <https://bugs.openjdk.java.net/browse/GRAAL-64> whether it is
> rendering the code also obsolete and going to the slowpath or whether it is
> adding my fix again to detect a fastpath TLAB reallocation happened.
>
>
>>
>> Renaming. I am fine with renaming if it helps to understand code better. I
>> agree with proposed
>> changes to fields name:
>>
>> _current_end
>> _allocation_end
>>
>> But, as Dean, I would suggest to keep names of access functions. This way
>> we can say that allocation
>> code in Interpreter and JITed code stay the same.
>>
>
> Sounds good to me, then in that case, this webrev will disappear, which
> also makes me happy, since it simplifies a lot of things (and reduces code
> change).
>
>
>>
>> You may need only new method to access _allocation_end in places which
>> look for real end of TLAB.
>>
>
> I think I like better not to add it. If no one is using it, there should be
> no reason to add it? By not adding it, it also makes any future wish to
> have it a nice indicator of: hey why do you want to see this? Same as
> hard_end btw which is not visible. Am I missing something?
>
> So to summarize, the current consensus:
> - _end can be renamed either to _current_end or _fast_path_end; that is
> still up to a vote and choice :)
> - the access method end() and tlab_end_offset() remain the same to not
> modify JIT/interpreter codes
>
> If all agree to this, then the consequences are:
> - JDK-8201326 becomes useless
> - The work for JEP-331 becomes smaller in terms of file changes
> - I'll still be needing a decision on the renaming of the TLAB _end field
> (current suggestions are _current_end and _fast_path_end).
>
> Thanks for your help!
> Jc
>
>
>>
>> Regards,
>> Vladimir
>>
>> On 4/16/18 4:42 PM, JC Beyler wrote:
>>> Hi Dean,
>>>
>>> I think perhaps this is also an attempt to figure out the naming of all
>>> this because naming (or renaming like here) is often the start of big
>>> conversations :).
>>>
>>> Originally, in the JEP-331 work, I had left the _end field as is and, by
>>> doing so, this whole renaming webrev goes away. However, if we do that,
>>> then the TLAB code contains:
>>>
>>> _end: the fast path end, can be the allocation end or the to-be-sampled
>> end
>>> _allocation_end: the actual allocation end of the current TLAB
>>> hard_end: _allocation_end + reserved space
>>>
>>> With an early iteration of a webrev for JEP-331, a conversation occurred
>>> about whether or not that was clear or not and it was determined that
>> this
>>> renaming was more clear:
>>>
>>> _current_end: the fast path end
>>> _allocation_end: the actual allocation end of the current TLAB
>>> reserved_end: _allocation_end + reserved space
>>>
>>> Because I'm trying to reduce the footprint of files changed, I pulled out
>>> the renaming changes into this webrev. While talking about it with the GC
>>> team, the renaming suggested became:
>>>
>>> _fast_path_end: the fast path end
>>> _allocation_end: the actual allocation end of the current TLAB
>>> hard_end: _allocation_end + reserved space
>>>
>>> Now, to be honest, any renaming or no renaming is fine by me. I like not
>>> renaming the fields to not change the code of every backend and Graal; I
>>> also like the fast_path_end rename due to it making the backend code easy
>>> to read as mentioned in the GC mailing lis thread.
>>>
>>> So there are two questions really:
>>> - Should we rename the _end field and thus provoke the changes in
>> this
>>> webrev?
>>> - If we do want to change the field, should/could it go in an initial
>>> webrev or should it go in the JEP-331 webrev whenever/ifever it goes in?
>>> And if we do wait, could we at least converge on a renaming now so that
>>> this does not become a point of contention for that webrev's review?
>>>
>>> If I read your answer correctly:
>>> - You are saying that we should keep the _end field altogether; or
>> at
>>> least only rename the field not the methods to access it, thus reducing
>> the
>>> change scope.
>>> - You are also saying to wait for the JEP-331 webrev's final
>> iteration
>>> and integrate it in one step
>>>
>>> Have I understood your answer correctly?
>>>
>>> Again, I am fine with renaming to whatever or not renaming at all. I just
>>> am trying to get forward progress here :)
>>>
>>> Thanks for your help!
>>> Jc
>>>
>>> On Mon, Apr 16, 2018 at 3:29 PM <dean.long at oracle.com> wrote:
>>>
>>>> Hi JC. Others might disagree, but I would vote "no" on doing this
>>>> renaming now, before the JEP, and even in the context of the JEP, I
>>>> don't think renaming the field requires renaming all the uses. The
>>>> compiler code is only interested in the fast path, so it's implicitly
>>>> understood. Also, if there is a fast_path_end(), then isn't it logical
>>>> to have fast_path_start() paired with it? ("start" is already
>>>> overloaded, but nobody is suggesting adding
>>>> allocation_start()/current_start()/hard_start() are they?). My opinion
>>>> is that it's fine the way it is.
>>>>
>>>> dl
>>>>
>>>> On 4/16/18 1:43 PM, JC Beyler wrote:
>>>>> Hi all,
>>>>>
>>>>> I've left the mail thread from the hotspot-gc-dev below for tracking
>>>>> purposes but will start a new request here.
>>>>>
>>>>> - I'm trying to push a renaming of a TLAB field to make my work for
>>>> JEP-331
>>>>> <http://openjdk.java.net/jeps/331> easier
>>>>> - There is an understanding that if JEP-331 does not make it, this
>>>> might
>>>>> be useless and I'll revert if that is what the community wants; however
>>>> the
>>>>> new name seems better anyway so perhaps not?
>>>>>
>>>>> - The webrev renames a field used across the various back-ends and
>> Graal
>>>>> - The webrev is here:
>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.04/
>>>>>
>>>>> Could I please get some feedback on this?
>>>>>
>>>>> Thanks all for your help,
>>>>> Jc
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Apr 13, 2018 at 2:37 AM Stefan Johansson <
>>>>> stefan.johansson at oracle.com> wrote:
>>>>>
>>>>>> Hi JC,
>>>>>>
>>>>>> I don't have a name, but I've looked at bit more at the failures and I
>>>>>> think they are unrelated and one of the local compiler engineers
>> agree.
>>>>>>
>>>>>> I also ran some local testing and was not able to get any error with
>> you
>>>>>> latest changes, but verified that it doens't work without the graal
>>>>>> parts. So they seem good. It might still be good to switch this over
>> to
>>>>>> the general hotspot-dev list to let someone with Graal knowledge to
>> look
>>>>>> at the change and make sure everything is correct.
>>>>>>
>>>>>> Thanks,
>>>>>> Stefan
>>>>>>
>>>>>>
>>>>>> On 2018-04-12 17:26, JC Beyler wrote:
>>>>>>> Hi Stefan,
>>>>>>>
>>>>>>> Thanks for testing :). I've renamed the bug title in the JBS and will
>>>>>>> emit a new webrev shortly. Do you have the name of a compiler
>> engineer
>>>>>>> in mind or should I perhaps now move this conversation to the general
>>>>>>> hotspot-dev mailing list and ask there?
>>>>>>>
>>>>>>> The alternative is to add the compiler-mailing list to this email
>>>> thread
>>>>>>> and ask there before sending to the general list. What do you think
>> is
>>>>>> best?
>>>>>>> Thanks for all your help,
>>>>>>> Jc
>>>>>>>
>>>>>>> On Thu, Apr 12, 2018 at 2:09 AM Stefan Johansson
>>>>>>> <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 2018-04-11 17:48, JC Beyler wrote:
>>>>>>> > Hi Stefan,
>>>>>>> >
>>>>>>> > Sorry about that, I must have missed adding the files or
>>>>>>> something. Here
>>>>>>> > is a webrev that added the changes for the SA file:
>>>>>>> > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/
>>>>>>> >
>>>>>>> No problem, this looks good. I kicked of a run in our test
>> system
>>>> to
>>>>>>> get
>>>>>>> some more coverage and have tried to include some Graal
>> testing.
>>>> I'll
>>>>>>> let you know the results once they are done.
>>>>>>>
>>>>>>> Please also update the bug title both in JBS and the changeset.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Stefan
>>>>>>>
>>>>>>> > I changed the method name, which propagated a change to:
>>>>>>> >
>>>>>>>
>>>>>>
>>>>
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
>>>>>>> >
>>>>>>> > I tried testing your test file. It exists in my branch (if
>> the
>>>>>>> same) under:
>>>>>>> > hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
>>>>>>> >
>>>>>>> > and interestingly (which generally means I did something
>>>> wrong),
>>>>>> it
>>>>>>> > passed before/after the change so I could not verify that
>> this
>>>> is
>>>>>>> a test
>>>>>>> > showing that all is well in the world on my side. Any ideas
>> of
>>>>>>> what I
>>>>>>> > did wrong?
>>>>>>> >
>>>>>>> > I did again test it for hotspot/jtreg/compiler/aot/ and
>>>>>>> > hotspot/jtreg/serviceability/jvmti and it passes those.
>>>>>>> >
>>>>>>> > Thanks for all your help,
>>>>>>> > Jc
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson
>>>>>>> > <stefan.johansson at oracle.com <mailto:
>>>> stefan.johansson at oracle.com>
>>>>>>> <mailto:stefan.johansson at oracle.com
>>>>>>> <mailto:stefan.johansson at oracle.com>>> wrote:
>>>>>>> >
>>>>>>> > Hi JC,
>>>>>>> >
>>>>>>> > On 2018-04-11 00:56, JC Beyler wrote:
>>>>>>> > > Small update:
>>>>>>> > >
>>>>>>> > > Here is the fixed webrev for the '{' that were out of
>>>>>>> alignment.
>>>>>>> > This
>>>>>>> > > passed release build JTREG
>>>>>>> for hotspot/jtreg/compiler/jvmti (just
>>>>>>> > to run
>>>>>>> > > something as a smoke screen)
>>>>>>> and hotspot/jtreg/compiler/aot/ (to
>>>>>>> > test
>>>>>>> > > Graal).
>>>>>>> > >
>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
>>>>>>> > >
>>>>>>> > I think this looks better, I agree that leaving _end is
>>>>>>> tempting to
>>>>>>> > avoid a lot of change, but I think this will be better
>> in
>>>> the
>>>>>>> long run.
>>>>>>> >
>>>>>>> > I still miss the changes to make the SA work. To see a
>>>>>>> problem you
>>>>>>> > can run:
>>>>>>> > make CONF=fast run-test
>>>>>>> >
>>>> TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
>>>>>>> >
>>>>>>> > Cheers,
>>>>>>> > Stefan
>>>>>>> >
>>>>>>> > > Let me know what you think,
>>>>>>> > > Jc
>>>>>>> > >
>>>>>>> > > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler
>>>>>>> <jcbeyler at google.com <mailto:jcbeyler at google.com>
>>>>>>> > <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com
>>>>
>>>>>>> > > <mailto:jcbeyler at google.com <mailto:
>> jcbeyler at google.com
>>>>>
>>>>>>> <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>>>
>>>> wrote:
>>>>>>> > >
>>>>>>> > > Hi Karen and Stefan,
>>>>>>> > >
>>>>>>> > > @Stefan: Naming is hard :)
>>>>>>> > > @Karen: thanks for the Graal comment, I fixed it
>> in
>>>>>>> the new
>>>>>>> > webrev,
>>>>>>> > > let me know what you think :)
>>>>>>> > >
>>>>>>> > > I think the naming convention suggested in this
>>>> webrev
>>>>>>> came from
>>>>>>> > > conversations in for JEP-331 and I am actually
>>>>>> relatively
>>>>>>> > > indifferent to the final result (as long as we
>> have
>>>>>>> some form of
>>>>>>> > > forward progress :)). To be honest, I'd also be
>>>> happy
>>>>>>> to just
>>>>>>> > leave
>>>>>>> > > _end as is for all architectures and Graal and
>> have
>>>> a
>>>>>> new
>>>>>>> > > _allocation_end. However, during initial reviews
>> of
>>>>>>> JEP-331
>>>>>>> > it was
>>>>>>> > > deemed complicated to understand:
>>>>>>> > >
>>>>>>> > > _end -> the _end or sampling end
>>>>>>> > > _allocation_end -> end pointer for the last
>> possible
>>>>>>> allocation
>>>>>>> > > hard_end -> allocation end + reserved space
>>>>>>> > >
>>>>>>> > > That is how this naming came up and why hard_end
>>>> went
>>>>>> to
>>>>>>> > "reserved_end".
>>>>>>> > >
>>>>>>> > > I'm really indifferent, so I offer as a perusal:
>>>>>>> > >
>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
>>>>>>> > >
>>>>>>> > > I noticed a few problems of alignement of '{' so
>>>> I'll
>>>>>>> go fix
>>>>>>> > that.
>>>>>>> > > Basically this webrev does the following:
>>>>>>> > >
>>>>>>> > > - Uses fast_path_end instead of end
>>>>>>> > > - Reverts hard_end back to where it was
>>>>>>> > > - Adds the changes to Graal; there is a bunch of
>>>>>>> changes in Graal
>>>>>>> > > because Graal still contains a bit of code doing
>>>>>>> fasttlabrefills.
>>>>>>> > >
>>>>>>> > > Let me know what you think!
>>>>>>> > >
>>>>>>> > > Thanks,
>>>>>>> > > Jc
>>>>>>> > >
>>>>>>> > >
>>>>>>> > > On Tue, Apr 10, 2018 at 6:56 AM Karen Kinnear
>>>>>>> > > <karen.kinnear at oracle.com
>>>>>>> <mailto:karen.kinnear at oracle.com> <mailto:
>>>> karen.kinnear at oracle.com
>>>>>>> <mailto:karen.kinnear at oracle.com>>
>>>>>>> > <mailto:karen.kinnear at oracle.com
>>>>>>> <mailto:karen.kinnear at oracle.com> <mailto:
>>>> karen.kinnear at oracle.com
>>>>>>> <mailto:karen.kinnear at oracle.com>>>>
>>>>>>> > wrote:
>>>>>>> > >
>>>>>>> > > Hi JC,
>>>>>>> > >
>>>>>>> > > A comment about Graal. The impact on Graal
>> for
>>>> this
>>>>>>> > particular
>>>>>>> > > change would be to break it - so you?ll need
>>>>>>> > > to complete the Graal changes for this
>> renaming.
>>>>>>> That isn?t
>>>>>>> > > optional or something that could be a
>>>> follow-on. It
>>>>>>> > > is not ok to break a feature, even an
>>>> experimental
>>>>>>> one.
>>>>>>> > We will
>>>>>>> > > discuss in the other thread potential
>> phasing of
>>>>>>> adding
>>>>>>> > sampling.
>>>>>>> > >
>>>>>>> > > I did not do a thorough search -you can do
>> that
>>>> -
>>>>>>> I did find
>>>>>>> > > src/jdk.internal.vm.compiler/share/classes/
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>> > > public final int threadTlabOffset =
>>>>>>> > > getFieldOffset("Thread::_tlab",
>> Integer.class,
>>>>>>> > > "ThreadLocalAllocBuffer");
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>> > > private final int
>>>>>>> threadLocalAllocBufferStartOffset =
>>>>>>> > >
>> getFieldOffset("ThreadLocalAllocBuffer::_start",
>>>>>>> > Integer.class,
>>>>>>> > > "HeapWord*");
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>> > > private final int
>>>>>> threadLocalAllocBufferEndOffset =
>>>>>>> > >
>> getFieldOffset("ThreadLocalAllocBuffer::_end",
>>>>>>> Integer.class,
>>>>>>> > > "HeapWord*");
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>> > > private final int
>>>>>> threadLocalAllocBufferTopOffset =
>>>>>>> > >
>> getFieldOffset("ThreadLocalAllocBuffer::_top",
>>>>>>> Integer.class,
>>>>>>> > > "HeapWord*");
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>> > > private final int
>>>>>>> threadLocalAllocBufferPfTopOffset =
>>>>>>> > >
>>>> getFieldOffset("ThreadLocalAllocBuffer::_pf_top",
>>>>>>> > Integer.class,
>>>>>>> > > "HeapWord*");
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>> > > private final int
>>>>>>> > threadLocalAllocBufferSlowAllocationsOffset
>>>>>>> > > =
>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
>>>>>>> > > Integer.class, "unsigned");
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>> > > private final int
>>>>>>> > threadLocalAllocBufferFastRefillWasteOffset
>>>>>>> > > =
>>>>>>> >
>>>> getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
>>>>>>> > > Integer.class, "unsigned");
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>> > > private final int
>>>>>>> > threadLocalAllocBufferNumberOfRefillsOffset
>>>>>>> > > =
>>>>>>> >
>>>> getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
>>>>>>> > > Integer.class, "unsigned");
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>> > > private final int
>>>>>>> > > threadLocalAllocBufferRefillWasteLimitOffset
>> =
>>>>>>> > >
>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
>>>>>>> > > Integer.class, "size_t");
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>> > > private final int
>>>>>>> > threadLocalAllocBufferDesiredSizeOffset =
>>>>>>> > >
>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
>>>>>>> > > Integer.class, "size_t");
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>>>
>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>> > > public final int tlabAlignmentReserve =
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>>>
>>>>
>> getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
>>>>>>> > > Integer.class, "size_t?);
>>>>>>> > >
>>>>>>> > > hope this helps,
>>>>>>> > > Karen
>>>>>>> > >
>>>>>>> > >> On Apr 10, 2018, at 7:04 AM, Stefan
>> Johansson
>>>>>>> > >> <stefan.johansson at oracle.com
>>>>>>> <mailto:stefan.johansson at oracle.com>
>>>>>>> > <mailto:stefan.johansson at oracle.com
>>>>>>> <mailto:stefan.johansson at oracle.com>>
>>>>>>> > >> <mailto:stefan.johansson at oracle.com
>>>>>>> <mailto:stefan.johansson at oracle.com>
>>>>>>> > <mailto:stefan.johansson at oracle.com
>>>>>>> <mailto:stefan.johansson at oracle.com>>>> wrote:
>>>>>>> > >>
>>>>>>> > >> Hi JC,
>>>>>>> > >>
>>>>>>> > >> I realize that the names have been discussed
>>>>>>> before but I'm
>>>>>>> > >> leaning towards suggesting something new. We
>>>>>>> discussed this
>>>>>>> > >> briefly here in the office and others might
>>>> have
>>>>>>> different
>>>>>>> > >> opinions. One point that came up is that if
>> we
>>>> do
>>>>>>> this
>>>>>>> > change
>>>>>>> > >> and change all usages of
>>>>>>> JavaThread::tlab_end_offset() it
>>>>>>> > >> would be good to make sure the new name is
>>>> good.
>>>>>>> To us
>>>>>>> > >> _current_end is not very descriptive, but
>>>> naming
>>>>>>> is hard and
>>>>>>> > >> the best we could come up with is
>>>> _fast_path_end
>>>>>>> which would
>>>>>>> > >> give the code:
>>>>>>> > >> cmpptr(end, Address(thread,
>>>>>>> > >> JavaThread::tlab_fast_path_end_offset()));
>>>>>>> > >> jcc(Assembler::above, slow_case);
>>>>>>> > >>
>>>>>>> > >> I think this reads pretty good and is fairly
>>>>>>> clear. If we do
>>>>>>> > >> this rename I think you can re-use _end in
>>>> JEP-331
>>>>>>> > instead of
>>>>>>> > >> calling it _allocation_end. But that is a
>> later
>>>>>>> review :)
>>>>>>> > >>
>>>>>>> > >> Also, is there a good reason for renaming
>>>>>>> hard_end() to
>>>>>>> > >> reserved_end()?
>>>>>>> > >>
>>>>>>> > >> One additional thing, you need to update
>> the SA
>>>>>>> to reflect
>>>>>>> > >> this change. I think the only place you
>> need to
>>>>>>> fix is in:
>>>>>>> > >>
>>>>>>> >
>>>>>>>
>>>>>>
>>>>
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
>>>>>>> > >>
>>>>>>> > >> Thanks,
>>>>>>> > >> Stefan
>>>>>>> > >>
>>>>>>> > >> On 2018-04-09 19:24, JC Beyler wrote:
>>>>>>> > >>> Hi all,
>>>>>>> > >>> Small pre-amble to this request:
>>>>>>> > >>> In my work to try to get a heap sampler in
>>>>>>> OpenJDK (via JEP
>>>>>>> > >>> 331
>>>>>>> > <https://bugs.openjdk.java.net/browse/JDK-8171119>),
>> I'm
>>>>>>> > >>> trying to reduce the footprint of my
>> change so
>>>>>>> that the
>>>>>>> > >>> integration can be easier. I was told that
>>>>>>> generally a JEP
>>>>>>> > >>> webrev should be feature complete and go in
>>>>>> at-once.
>>>>>>> > However,
>>>>>>> > >>> with the change touching quite a bit of
>>>> various
>>>>>> code
>>>>>>> > pieces,
>>>>>>> > >>> I was trying to figure out what could be
>>>>>>> separated as not
>>>>>>> > >>> "part of the feature".
>>>>>>> > >>> I asked around and said that perhaps a
>>>> solution
>>>>>>> would be to
>>>>>>> > >>> cut up the renaming of TLAB's end field
>> that I
>>>>>>> do in that
>>>>>>> > >>> webrev. Because I'm renaming a field in
>> TLAB
>>>>>> used by
>>>>>>> > various
>>>>>>> > >>> backends for that work, I have to update
>> every
>>>>>>> architecture
>>>>>>> > >>> dependent code to reflect it.
>>>>>>> > >>> I entirely understand that perhaps this is
>> not
>>>>>>> in the
>>>>>>> > habits
>>>>>>> > >>> and very potentially might not be the way
>>>> things
>>>>>> are
>>>>>>> > >>> generally done. If so, I apologize and let
>> me
>>>>>>> know if you
>>>>>>> > >>> would not want this to go in separately :)
>>>>>>> > >>> Final note: there is still a chance JEP-331
>>>> does
>>>>>>> not go in.
>>>>>>> > >>> If it does not, we can leave the new name
>> in
>>>>>>> place or I'll
>>>>>>> > >>> happily revert it. I can even create an
>> issue
>>>> to
>>>>>>> track this
>>>>>>> > >>> if that makes it easier for all.
>>>>>>> > >>> End of the pre-amble.
>>>>>>> > >>> The 33-line change webrev in question is
>> here:
>>>>>>> > >>>
>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
>>>>>>> > >>> I fixed all the architectures and JVMCI and
>>>> ran
>>>>>>> a few
>>>>>>> > sanity
>>>>>>> > >>> tests to ensure I had not missed anything.
>>>>>>> > >>> Thanks for your help and I hope this is not
>>>> too
>>>>>> much
>>>>>>> > trouble,
>>>>>>> > >>> Jc
>>>>>>> > >>> Ps: there is a graal change that needs to
>>>> happen
>>>>>>> but I was
>>>>>>> > >>> not sure who/where
>> <https://teams.googleplex.com/u/where>
>>>> <https://teams.googleplex.com/u/where>
>>>>>> <https://teams.googleplex.com/u/where>
>>>>>>> <https://teams.googleplex.com/u/where>
>>>>>>> > <https://teams.googleplex.com/u/where>
>>>>>>> > <https://teams.googleplex.com/u/where> to
>>>>>>> > >>> ask about it. I was told it could happen
>> in a
>>>>>>> separate
>>>>>>> > >>> webrev. Can anyone point me to the right
>>>>>> direction?
>>>>>>> > Should it
>>>>>>> > >>> just be hotspot-compiler-dev?
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>
>>>>
>>
From vladimir.kozlov at oracle.com Wed Apr 18 00:30:18 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 17 Apr 2018 17:30:18 -0700
Subject: 8185505: AArch64: Port AOT
In-Reply-To: <4626be6e-7927-a8ad-dead-1c3a4fca3ec9@oracle.com>
References: <b439eaf0-e026-7ff8-e832-3717368027e4@redhat.com>
<AM5PR0802MB2449400467C4E4042C3C6A6390B00@AM5PR0802MB2449.eurprd08.prod.outlook.com>
<57767253-4826-e5b4-d142-7990d7114704@redhat.com>
<4626be6e-7927-a8ad-dead-1c3a4fca3ec9@oracle.com>
Message-ID: <5147cd22-8c3c-d72f-bf5d-0ef384eac45c@oracle.com>
And I forgot to say that changes looks good to me.
Thanks,
Vladimir
On 4/17/18 9:53 AM, Vladimir Kozlov wrote:
> On 4/16/18 2:03 AM, Andrew Haley wrote:
>> On 04/16/2018 09:53 AM, Ningsheng Jian wrote:
>>> I can see both the jdk patch and Graal PR contain changes of AArch64Assembler.java and
>>> AArch64MacroAssembler.java, but the changes looks somewhat different. How will they be synced?
>>
>> The changes to Graal in JDK do no more than allow OpenJDK to build.? They
>> are not called by anything, and will disappear at the next Graal import.
>>
>>> I noticed that in make/hotspot/lib/JvmFeatures.gmk line ~144, there's:
>>>
>>> ?? JVM_EXCLUDE_FILES += \
>>> ?????? compiledIC_aot_x86_64.cpp
>>>
>>> Do you want to add compiledIC_aot_aarch64.cpp to that list?
>>
>> I don't really know what this does, so I have no idea.
>
> It was done when we did not support/build AOT on Win and MacOS. It also work when AOT is disabled in
> build: configure --disable-aot
> We have to exclude to AOT files to avoid build failure because they do not have #ifdef INCLUDE_AOT.
>
> I think compiledIC_aot_aarch64.cpp should be added to exclude list too. And you can test you code
> with --disable-aot
>
> Vladimir
>
>>
>>> I also found that _immutable_PIC and its getters/setters are in the INCLUDE_AOT block, but some
>>> of their uses are not:
>>>
>>> src/hotspot/cpu/aarch64/compiledIC_aarch64.cpp:
>>>
>>> 61?? if (cbuf.immutable_PIC()) {
>>>
>>> src/hotspot/share/jvmci/jvmciCodeInstaller.cpp:
>>>
>>> 594?? buffer.set_immutable_PIC(_immutable_pic_compilation);
>>> 628?? buffer.set_immutable_PIC(_immutable_pic_compilation);
>>
>> Thank you.? For the sake of consistency I will change it.
>>
From thomas.stuefe at gmail.com Wed Apr 18 04:47:41 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 18 Apr 2018 06:47:41 +0200
Subject: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
In-Reply-To: <b65af851-d138-42b2-847a-fd6650a1767b@oracle.com>
References: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
<CAA-vtUz48xUdXQzDEAuS2JDdnis7n2pAjfJ52dgFkhKskNoX9Q@mail.gmail.com>
<b65af851-d138-42b2-847a-fd6650a1767b@oracle.com>
Message-ID: <CAA-vtUz+cyza6GOnVN7p-9XJ-JYo_vBozMNh0K=7woUbV4mKzA@mail.gmail.com>
Hi David,
On Tue, Apr 17, 2018 at 11:17 PM, David Holmes <david.holmes at oracle.com> wrote:
> On 18/04/2018 1:48 AM, Thomas St?fe wrote:
>>
>> Hi Christoph,
>>
>> I do not understand jio_print() at all. I think it is just wrong: if a
>> vfprintf hook is set, it prints to the defaultStream::output_stream(),
>> otherwise to defaultStream::output_fd()? Isnt that the same? Compare
>> this to jio_vfprintf(), which does the same logic, but correctly
>> prints to the vfprintf hook if it is set.
>
>
> If there is a hook it does a formatted print: jio_print -> jio_fprintf ->
> jio_vfprintf -> Arguments::vfprintf_hook()
> else it does a raw write.
Oh, I missed that.
So, jio_print() checks if a vfprintf hook is installed.
If it is, it calls jio_fprintf() with defaultStream::output_stream()
as output file handle. It expects jio_fprintf() to call
jio_vfprintf(), which should do the same check again and come to the
same conclusion, then should disregard the output file handle handed
down, instead call the vfprintf hook.
(The output file handle is handed down as argument to the vfprintf
hook; we had a discussion last year about it:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-May/026794.html
and we were not sure that made any sense.)
Not very clear coding. I think that can be improved by removing the
vfprintf hook check from jio_print completely and make jio_vfprintf()
be the only place where the vfprintf hook is handled.
For example, this would be equivalent:
void jio_print(const char* s) {
jio_printf("%s", s);
}
or this:
void jio_print(const char* s) {
jio_fprintf(defaultStream::output_stream(), "%s", s);
}
in which case we could also maybe also remove jio_printf(), because it
is nowhere used inside the hotspot (though it is exported, but I find
no reference to it being used anywhere in the OpenJDK).
>
> Now why it does this is another matter. I have no idea. But I wouldn't
> suggest changing it just because I don't know why it's done the way it is.
I was reasonably sure I had understood the function, and that it was
broken. In that case the proposal to change or remove it made sense.
Thomas
>
> David
>
>
>
>> I would propose to get rid of jio_print() altogether and replace the
>> few callers of it (all in ostream.cpp) with this:
>>
>> jio_printf("%s", string);
>>
>> which does the same, but correctly.
>>
>> Best Regards, Thomas
>>
>> On Tue, Apr 17, 2018 at 4:48 PM, Langer, Christoph
>> <christoph.langer at sap.com> wrote:
>>>
>>> Hi,
>>>
>>> can you please review a fix proposal for defaultStream::write(const char*
>>> s, size_t len).
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201649
>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201649.0/
>>>
>>> I have seen occurrences of truncated buffers which don't need to happen.
>>>
>>> Thanks and best regards
>>> Christoph
>>>
>
From david.holmes at oracle.com Wed Apr 18 05:59:10 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Apr 2018 15:59:10 +1000
Subject: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
In-Reply-To: <CAA-vtUz+cyza6GOnVN7p-9XJ-JYo_vBozMNh0K=7woUbV4mKzA@mail.gmail.com>
References: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
<CAA-vtUz48xUdXQzDEAuS2JDdnis7n2pAjfJ52dgFkhKskNoX9Q@mail.gmail.com>
<b65af851-d138-42b2-847a-fd6650a1767b@oracle.com>
<CAA-vtUz+cyza6GOnVN7p-9XJ-JYo_vBozMNh0K=7woUbV4mKzA@mail.gmail.com>
Message-ID: <b0fcb60f-ff76-9b98-871c-8692f4504442@oracle.com>
On 18/04/2018 2:47 PM, Thomas St?fe wrote:
> Hi David,
>
> On Tue, Apr 17, 2018 at 11:17 PM, David Holmes <david.holmes at oracle.com> wrote:
>> On 18/04/2018 1:48 AM, Thomas St?fe wrote:
>>>
>>> Hi Christoph,
>>>
>>> I do not understand jio_print() at all. I think it is just wrong: if a
>>> vfprintf hook is set, it prints to the defaultStream::output_stream(),
>>> otherwise to defaultStream::output_fd()? Isnt that the same? Compare
>>> this to jio_vfprintf(), which does the same logic, but correctly
>>> prints to the vfprintf hook if it is set.
>>
>>
>> If there is a hook it does a formatted print: jio_print -> jio_fprintf ->
>> jio_vfprintf -> Arguments::vfprintf_hook()
>> else it does a raw write.
>
> Oh, I missed that.
>
> So, jio_print() checks if a vfprintf hook is installed.
>
> If it is, it calls jio_fprintf() with defaultStream::output_stream()
> as output file handle. It expects jio_fprintf() to call
> jio_vfprintf(), which should do the same check again and come to the
> same conclusion, then should disregard the output file handle handed
> down, instead call the vfprintf hook.
>
> (The output file handle is handed down as argument to the vfprintf
> hook; we had a discussion last year about it:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-May/026794.html
> and we were not sure that made any sense.)
I had forgotten about that. :)
> Not very clear coding. I think that can be improved by removing the
> vfprintf hook check from jio_print completely and make jio_vfprintf()
> be the only place where the vfprintf hook is handled.
>
> For example, this would be equivalent:
>
> void jio_print(const char* s) {
> jio_printf("%s", s);
> }
>
> or this:
>
> void jio_print(const char* s) {
> jio_fprintf(defaultStream::output_stream(), "%s", s);
> }
They aren't equivalent because the always do a formatted write, never
the raw write the currently exists. Does that matter? <shrug> no idea. I
don't have time to do any archaeology on this piece of code - sorry.
Cheers,
David
-----
> in which case we could also maybe also remove jio_printf(), because it
> is nowhere used inside the hotspot (though it is exported, but I find
> no reference to it being used anywhere in the OpenJDK).
>
>>
>> Now why it does this is another matter. I have no idea. But I wouldn't
>> suggest changing it just because I don't know why it's done the way it is.
>
> I was reasonably sure I had understood the function, and that it was
> broken. In that case the proposal to change or remove it made sense.
>
> Thomas
>
>>
>> David
>>
>>
>>
>>> I would propose to get rid of jio_print() altogether and replace the
>>> few callers of it (all in ostream.cpp) with this:
>>>
>>> jio_printf("%s", string);
>>>
>>> which does the same, but correctly.
>>>
>>> Best Regards, Thomas
>>>
>>> On Tue, Apr 17, 2018 at 4:48 PM, Langer, Christoph
>>> <christoph.langer at sap.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> can you please review a fix proposal for defaultStream::write(const char*
>>>> s, size_t len).
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201649
>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201649.0/
>>>>
>>>> I have seen occurrences of truncated buffers which don't need to happen.
>>>>
>>>> Thanks and best regards
>>>> Christoph
>>>>
>>
From glaubitz at physik.fu-berlin.de Wed Apr 18 07:10:31 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Wed, 18 Apr 2018 09:10:31 +0200
Subject: jdk/jdk OPEN for HotSpot pushes (Re: Merging jdk/hs with jdk/jdk)
In-Reply-To: <EEA812F6-693C-41D9-87B4-5F66B478F9DB@oracle.com>
References: <8819CAD3-AF29-463E-8A76-14440CF37D2B@oracle.com>
<952F85EF-BB76-4645-AC05-F843DB83881B@oracle.com>
<EEA812F6-693C-41D9-87B4-5F66B478F9DB@oracle.com>
Message-ID: <585020bc-6f0f-5dd0-19e7-4ade558557d3@physik.fu-berlin.de>
Hi Jesper
On 04/17/2018 06:18 PM, jesper.wilhelmsson at oracle.com wrote:
> The final jdk/hs integration has landed in jdk/jdk. jdk/jdk is now open for regular hotspot pushes.
>>> As part of this
>>> merge we can also retire the newly setup submit-hs [3] repository
>>> and do all testing using the submit repo based on jdk/jdk [4].
(...)
>>> [4] http://hg.openjdk.java.net/jdk/submit <http://hg.openjdk.java.net/jdk/submit> <http://hg.openjdk.java.net/jdk/submit <http://hg.openjdk.java.net/jdk/submit>>
I pushed a change to the submit repository yesterday [1] but I still
haven't back from the testing environment. For submit-hs, the result
mail usually came back a couple of hours later.
Is the queue currently just very full or are there any issues at the
moment?
Adrian
> [1] http://hg.openjdk.java.net/jdk/submit/rev/2417c3dddb34
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From jesper.wilhelmsson at oracle.com Wed Apr 18 07:46:09 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Wed, 18 Apr 2018 09:46:09 +0200
Subject: jdk/jdk OPEN for HotSpot pushes (Re: Merging jdk/hs with jdk/jdk)
In-Reply-To: <585020bc-6f0f-5dd0-19e7-4ade558557d3@physik.fu-berlin.de>
References: <8819CAD3-AF29-463E-8A76-14440CF37D2B@oracle.com>
<952F85EF-BB76-4645-AC05-F843DB83881B@oracle.com>
<EEA812F6-693C-41D9-87B4-5F66B478F9DB@oracle.com>
<585020bc-6f0f-5dd0-19e7-4ade558557d3@physik.fu-berlin.de>
Message-ID: <F3D99DFF-9479-4A93-A9CC-9E0BC02D078D@oracle.com>
> On 18 Apr 2018, at 09:10, John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de> wrote:
>
> Hi Jesper
>
> On 04/17/2018 06:18 PM, jesper.wilhelmsson at oracle.com wrote:
>> The final jdk/hs integration has landed in jdk/jdk. jdk/jdk is now open for regular hotspot pushes.
>>>> As part of this
>>>> merge we can also retire the newly setup submit-hs [3] repository
>>>> and do all testing using the submit repo based on jdk/jdk [4].
> (...)
>>>> [4] http://hg.openjdk.java.net/jdk/submit <http://hg.openjdk.java.net/jdk/submit> <http://hg.openjdk.java.net/jdk/submit <http://hg.openjdk.java.net/jdk/submit>>
>
> I pushed a change to the submit repository yesterday [1] but I still
> haven't back from the testing environment. For submit-hs, the result
> mail usually came back a couple of hours later.
>
> Is the queue currently just very full or are there any issues at the
> moment?
I don't see any job with your username (glaubitz) and the bug id 8201616. The most recent is from six days ago, 8201480.
Most likely something went wrong when starting the job. I do see your push in the submit repo. Try to push some trivial change to the same branch, that should trigger a new test job.
/Jesper
>
> Adrian
>
>> [1] http://hg.openjdk.java.net/jdk/submit/rev/2417c3dddb34
>
> --
> .''`. John Paul Adrian Glaubitz
> : :' : Debian Developer - glaubitz at debian.org
> `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From robbin.ehn at oracle.com Wed Apr 18 07:50:34 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Wed, 18 Apr 2018 09:50:34 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <6690f389-9f49-6ce4-c957-5f64e52afd69@physik.fu-berlin.de>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<248611e6-879a-30f9-16c5-202d80983c54@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
<6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
<CAA-vtUwnVXnRPkT6Waw=q3SsV+J33TYUmY-3MM76QBYMZ9DqJg@mail.gmail.com>
<43f7de51-4fd9-3dac-2e23-f40ce3e7b4c0@physik.fu-berlin.de>
<3ea48b20-8d19-18f4-40e5-d8beb6c35461@physik.fu-berlin.de>
<49cd1bbe-0243-d34e-7990-7e727e3e509a@physik.fu-berlin.de>
<935e41ee-9618-24a8-b7e9-8a149e112006@oracle.com>
<7ebf0b4d-4e2a-f87e-be72-90d4e6490bf0@oracle.com>
<27273295-9d1b-a8a6-851b-a60705d5c27e@physik.fu-berlin.de>
<43e06d17-aba3-5110-1692-96cd061f0c14@oracle.com>
<6690f389-9f49-6ce4-c957-5f64e52afd69@physik.fu-berlin.de>
Message-ID: <015e93a9-3c3e-7a6e-f1f9-61eb9dea38f6@oracle.com>
Hi,
On 2018-04-17 23:08, John Paul Adrian Glaubitz wrote:
> On 04/17/2018 11:05 PM, David Holmes wrote:
>>> This seems to be theculprit: http://hg.openjdk.java.net/jdk/hs/rev/0ce0ac68ace7
>>
>> So you can run okay with -XX:-ThreadLocalHandshakes ?
>
> A HellWorld runs fine although I don't know whether that verifies anything:
>
> glaubitz at deb4g:/srv/glaubitz$ hs/build/linux-sparcv9-normal-server-release/jdk/bin/java -XX:-ThreadLocalHandshakes HelloWorld
Use something like:
java -Xcomp -XX:LoopStripMiningIter=1 -XX:+UseCountedLoopSafepoints
-XX:+SafepointALot -XX:GuaranteedSafepointInterval=1 HelloWorld
If you are not extremely unlucky you should hit a poll exception.
Until sparc/Linux is fixed and tested, I suggest we remove handshake support for
it by something like:
diff -r 69d7398038c5 src/hotspot/cpu/sparc/globalDefinitions_sparc.hpp
--- a/src/hotspot/cpu/sparc/globalDefinitions_sparc.hpp Wed Apr 18 09:25:51 2018
+0200
+++ b/src/hotspot/cpu/sparc/globalDefinitions_sparc.hpp Wed Apr 18 09:48:13 2018
+0200
@@ -51,8 +51,8 @@
#if defined(SOLARIS)
#define SUPPORT_RESERVED_STACK_AREA
+// SPARC solaris have implemented the local polling
+#define THREAD_LOCAL_POLL
#endif
-// SPARC have implemented the local polling
-#define THREAD_LOCAL_POLL
#endif // CPU_SPARC_VM_GLOBALDEFINITIONS_SPARC_HPP
/Robbin
> Hello, World
> glaubitz at deb4g:/srv/glaubitz$
>
From christoph.langer at sap.com Wed Apr 18 07:58:27 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 18 Apr 2018 07:58:27 +0000
Subject: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
In-Reply-To: <b0fcb60f-ff76-9b98-871c-8692f4504442@oracle.com>
References: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
<CAA-vtUz48xUdXQzDEAuS2JDdnis7n2pAjfJ52dgFkhKskNoX9Q@mail.gmail.com>
<b65af851-d138-42b2-847a-fd6650a1767b@oracle.com>
<CAA-vtUz+cyza6GOnVN7p-9XJ-JYo_vBozMNh0K=7woUbV4mKzA@mail.gmail.com>
<b0fcb60f-ff76-9b98-871c-8692f4504442@oracle.com>
Message-ID: <43ae45216d3545518b274dd7246d7862@sap.com>
cc-ing hotspot-runtime-dev as Dan mentioned in the bug that it should rather be there.
Hi Thomas, David,
I think it could be cleaned up nicely by removing jio_print and jio_printf from jvm.cpp and doing all in ostream.cpp. At the one place where we would call jio_print after my patch, we can do the vfprintf hook check and then either write to the hook or do the raw write. And the other 2 places where jio_printf is employed, we can just call jio_vfprintf(defaultStream::output_stream()). I don't see any other users of jio_print and jio_printf in the jdk repo.
Any objections to that (e.g. some Oracle closed coding that'd break)? Otherwise I'll prepare something...
Best regards
Christoph
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Mittwoch, 18. April 2018 07:59
> To: Thomas St?fe <thomas.stuefe at gmail.com>
> Cc: Langer, Christoph <christoph.langer at sap.com>; hotspot-
> dev at openjdk.java.net
> Subject: Re: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
>
> On 18/04/2018 2:47 PM, Thomas St?fe wrote:
> > Hi David,
> >
> > On Tue, Apr 17, 2018 at 11:17 PM, David Holmes
> <david.holmes at oracle.com> wrote:
> >> On 18/04/2018 1:48 AM, Thomas St?fe wrote:
> >>>
> >>> Hi Christoph,
> >>>
> >>> I do not understand jio_print() at all. I think it is just wrong: if a
> >>> vfprintf hook is set, it prints to the defaultStream::output_stream(),
> >>> otherwise to defaultStream::output_fd()? Isnt that the same? Compare
> >>> this to jio_vfprintf(), which does the same logic, but correctly
> >>> prints to the vfprintf hook if it is set.
> >>
> >>
> >> If there is a hook it does a formatted print: jio_print -> jio_fprintf ->
> >> jio_vfprintf -> Arguments::vfprintf_hook()
> >> else it does a raw write.
> >
> > Oh, I missed that.
> >
> > So, jio_print() checks if a vfprintf hook is installed.
> >
> > If it is, it calls jio_fprintf() with defaultStream::output_stream()
> > as output file handle. It expects jio_fprintf() to call
> > jio_vfprintf(), which should do the same check again and come to the
> > same conclusion, then should disregard the output file handle handed
> > down, instead call the vfprintf hook.
> >
> > (The output file handle is handed down as argument to the vfprintf
> > hook; we had a discussion last year about it:
> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> May/026794.html
> > and we were not sure that made any sense.)
>
> I had forgotten about that. :)
>
> > Not very clear coding. I think that can be improved by removing the
> > vfprintf hook check from jio_print completely and make jio_vfprintf()
> > be the only place where the vfprintf hook is handled.
> >
> > For example, this would be equivalent:
> >
> > void jio_print(const char* s) {
> > jio_printf("%s", s);
> > }
> >
> > or this:
> >
> > void jio_print(const char* s) {
> > jio_fprintf(defaultStream::output_stream(), "%s", s);
> > }
>
> They aren't equivalent because the always do a formatted write, never
> the raw write the currently exists. Does that matter? <shrug> no idea. I
> don't have time to do any archaeology on this piece of code - sorry.
>
> Cheers,
> David
> -----
>
> > in which case we could also maybe also remove jio_printf(), because it
> > is nowhere used inside the hotspot (though it is exported, but I find
> > no reference to it being used anywhere in the OpenJDK).
> >
> >>
> >> Now why it does this is another matter. I have no idea. But I wouldn't
> >> suggest changing it just because I don't know why it's done the way it is.
> >
> > I was reasonably sure I had understood the function, and that it was
> > broken. In that case the proposal to change or remove it made sense.
> >
> > Thomas
> >
> >>
> >> David
> >>
> >>
> >>
> >>> I would propose to get rid of jio_print() altogether and replace the
> >>> few callers of it (all in ostream.cpp) with this:
> >>>
> >>> jio_printf("%s", string);
> >>>
> >>> which does the same, but correctly.
> >>>
> >>> Best Regards, Thomas
> >>>
> >>> On Tue, Apr 17, 2018 at 4:48 PM, Langer, Christoph
> >>> <christoph.langer at sap.com> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> can you please review a fix proposal for defaultStream::write(const
> char*
> >>>> s, size_t len).
> >>>>
> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201649
> >>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201649.0/
> >>>>
> >>>> I have seen occurrences of truncated buffers which don't need to
> happen.
> >>>>
> >>>> Thanks and best regards
> >>>> Christoph
> >>>>
> >>
From david.holmes at oracle.com Wed Apr 18 07:59:15 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Apr 2018 17:59:15 +1000
Subject: jdk/jdk OPEN for HotSpot pushes (Re: Merging jdk/hs with jdk/jdk)
In-Reply-To: <F3D99DFF-9479-4A93-A9CC-9E0BC02D078D@oracle.com>
References: <8819CAD3-AF29-463E-8A76-14440CF37D2B@oracle.com>
<952F85EF-BB76-4645-AC05-F843DB83881B@oracle.com>
<EEA812F6-693C-41D9-87B4-5F66B478F9DB@oracle.com>
<585020bc-6f0f-5dd0-19e7-4ade558557d3@physik.fu-berlin.de>
<F3D99DFF-9479-4A93-A9CC-9E0BC02D078D@oracle.com>
Message-ID: <fcfaa52c-dc63-8f00-4955-3a95b9d6bfa6@oracle.com>
IIRC they disabled submit-hs due to the switch to jdk/jdk
David
On 18/04/2018 5:46 PM, jesper.wilhelmsson at oracle.com wrote:
>> On 18 Apr 2018, at 09:10, John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de> wrote:
>>
>> Hi Jesper
>>
>> On 04/17/2018 06:18 PM, jesper.wilhelmsson at oracle.com wrote:
>>> The final jdk/hs integration has landed in jdk/jdk. jdk/jdk is now open for regular hotspot pushes.
>>>>> As part of this
>>>>> merge we can also retire the newly setup submit-hs [3] repository
>>>>> and do all testing using the submit repo based on jdk/jdk [4].
>> (...)
>>>>> [4] http://hg.openjdk.java.net/jdk/submit <http://hg.openjdk.java.net/jdk/submit> <http://hg.openjdk.java.net/jdk/submit <http://hg.openjdk.java.net/jdk/submit>>
>>
>> I pushed a change to the submit repository yesterday [1] but I still
>> haven't back from the testing environment. For submit-hs, the result
>> mail usually came back a couple of hours later.
>>
>> Is the queue currently just very full or are there any issues at the
>> moment?
>
> I don't see any job with your username (glaubitz) and the bug id 8201616. The most recent is from six days ago, 8201480.
> Most likely something went wrong when starting the job. I do see your push in the submit repo. Try to push some trivial change to the same branch, that should trigger a new test job.
> /Jesper
>
>>
>> Adrian
>>
>>> [1] http://hg.openjdk.java.net/jdk/submit/rev/2417c3dddb34
>>
>> --
>> .''`. John Paul Adrian Glaubitz
>> : :' : Debian Developer - glaubitz at debian.org
>> `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>
From david.holmes at oracle.com Wed Apr 18 08:00:17 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Apr 2018 18:00:17 +1000
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <015e93a9-3c3e-7a6e-f1f9-61eb9dea38f6@oracle.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<CAA-vtUy3WvMsA3urVRLO=wAX6yBiCoS0-HtWW5Gr96kqU8U91A@mail.gmail.com>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
<6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
<CAA-vtUwnVXnRPkT6Waw=q3SsV+J33TYUmY-3MM76QBYMZ9DqJg@mail.gmail.com>
<43f7de51-4fd9-3dac-2e23-f40ce3e7b4c0@physik.fu-berlin.de>
<3ea48b20-8d19-18f4-40e5-d8beb6c35461@physik.fu-berlin.de>
<49cd1bbe-0243-d34e-7990-7e727e3e509a@physik.fu-berlin.de>
<935e41ee-9618-24a8-b7e9-8a149e112006@oracle.com>
<7ebf0b4d-4e2a-f87e-be72-90d4e6490bf0@oracle.com>
<27273295-9d1b-a8a6-851b-a60705d5c27e@physik.fu-berlin.de>
<43e06d17-aba3-5110-1692-96cd061f0c14@oracle.com>
<6690f389-9f49-6ce4-c957-5f64e52afd69@physik.fu-berlin.de>
<015e93a9-3c3e-7a6e-f1f9-61eb9dea38f6@oracle.com>
Message-ID: <d95b74c1-0eb5-952e-0da2-cd80671bf8fb@oracle.com>
Robbin,
I think it's now fixed. There were a couple of different email threads
on this.
Cheers,
David
On 18/04/2018 5:50 PM, Robbin Ehn wrote:
> Hi,
>
> On 2018-04-17 23:08, John Paul Adrian Glaubitz wrote:
>> On 04/17/2018 11:05 PM, David Holmes wrote:
>>>> This seems to be theculprit:
>>>> http://hg.openjdk.java.net/jdk/hs/rev/0ce0ac68ace7
>>>
>>> So you can run okay with -XX:-ThreadLocalHandshakes ?
>>
>> A HellWorld runs fine although I don't know whether that verifies
>> anything:
>>
>> glaubitz at deb4g:/srv/glaubitz$
>> hs/build/linux-sparcv9-normal-server-release/jdk/bin/java
>> -XX:-ThreadLocalHandshakes HelloWorld
>
> Use something like:
> java -Xcomp -XX:LoopStripMiningIter=1 -XX:+UseCountedLoopSafepoints
> -XX:+SafepointALot -XX:GuaranteedSafepointInterval=1 HelloWorld
> If you are not extremely unlucky you should hit a poll exception.
>
> Until sparc/Linux is fixed and tested, I suggest we remove handshake
> support for it by something like:
> diff -r 69d7398038c5 src/hotspot/cpu/sparc/globalDefinitions_sparc.hpp
> --- a/src/hotspot/cpu/sparc/globalDefinitions_sparc.hpp??? Wed Apr 18
> 09:25:51 2018 +0200
> +++ b/src/hotspot/cpu/sparc/globalDefinitions_sparc.hpp??? Wed Apr 18
> 09:48:13 2018 +0200
> @@ -51,8 +51,8 @@
> ?#if defined(SOLARIS)
> ?#define SUPPORT_RESERVED_STACK_AREA
> +// SPARC solaris have implemented the local polling
> +#define THREAD_LOCAL_POLL
> ?#endif
>
> -// SPARC have implemented the local polling
> -#define THREAD_LOCAL_POLL
>
> ?#endif // CPU_SPARC_VM_GLOBALDEFINITIONS_SPARC_HPP
>
>
> /Robbin
>
>
>> Hello, World
>> glaubitz at deb4g:/srv/glaubitz$
>>
From jesper.wilhelmsson at oracle.com Wed Apr 18 08:02:22 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Wed, 18 Apr 2018 10:02:22 +0200
Subject: jdk/jdk OPEN for HotSpot pushes (Re: Merging jdk/hs with jdk/jdk)
In-Reply-To: <fcfaa52c-dc63-8f00-4955-3a95b9d6bfa6@oracle.com>
References: <8819CAD3-AF29-463E-8A76-14440CF37D2B@oracle.com>
<952F85EF-BB76-4645-AC05-F843DB83881B@oracle.com>
<EEA812F6-693C-41D9-87B4-5F66B478F9DB@oracle.com>
<585020bc-6f0f-5dd0-19e7-4ade558557d3@physik.fu-berlin.de>
<F3D99DFF-9479-4A93-A9CC-9E0BC02D078D@oracle.com>
<fcfaa52c-dc63-8f00-4955-3a95b9d6bfa6@oracle.com>
Message-ID: <3DAF861F-3649-447E-BEFB-3BD605F8FB41@oracle.com>
Yes, submit-hs is read only now. But the latest push was to jdk/submit
/Jesper
> On 18 Apr 2018, at 09:59, David Holmes <david.holmes at oracle.com> wrote:
>
> IIRC they disabled submit-hs due to the switch to jdk/jdk
>
> David
>
> On 18/04/2018 5:46 PM, jesper.wilhelmsson at oracle.com wrote:
>>> On 18 Apr 2018, at 09:10, John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de> wrote:
>>>
>>> Hi Jesper
>>>
>>> On 04/17/2018 06:18 PM, jesper.wilhelmsson at oracle.com wrote:
>>>> The final jdk/hs integration has landed in jdk/jdk. jdk/jdk is now open for regular hotspot pushes.
>>>>>> As part of this
>>>>>> merge we can also retire the newly setup submit-hs [3] repository
>>>>>> and do all testing using the submit repo based on jdk/jdk [4].
>>> (...)
>>>>>> [4] http://hg.openjdk.java.net/jdk/submit <http://hg.openjdk.java.net/jdk/submit> <http://hg.openjdk.java.net/jdk/submit <http://hg.openjdk.java.net/jdk/submit>>
>>>
>>> I pushed a change to the submit repository yesterday [1] but I still
>>> haven't back from the testing environment. For submit-hs, the result
>>> mail usually came back a couple of hours later.
>>>
>>> Is the queue currently just very full or are there any issues at the
>>> moment?
>> I don't see any job with your username (glaubitz) and the bug id 8201616. The most recent is from six days ago, 8201480.
>> Most likely something went wrong when starting the job. I do see your push in the submit repo. Try to push some trivial change to the same branch, that should trigger a new test job.
>> /Jesper
>>>
>>> Adrian
>>>
>>>> [1] http://hg.openjdk.java.net/jdk/submit/rev/2417c3dddb34
>>>
>>> --
>>> .''`. John Paul Adrian Glaubitz
>>> : :' : Debian Developer - glaubitz at debian.org
>>> `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>>> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From robbin.ehn at oracle.com Wed Apr 18 08:02:47 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Wed, 18 Apr 2018 10:02:47 +0200
Subject: Hotspot segfaulting on Linux SPARC
In-Reply-To: <d95b74c1-0eb5-952e-0da2-cd80671bf8fb@oracle.com>
References: <1a27572c-c6b0-adbd-d7ab-973d8c0cb844@physik.fu-berlin.de>
<ff30e47d-71b2-9d8b-7e05-824250eac23e@physik.fu-berlin.de>
<2d8263c0-90ed-1c9e-c935-23ea3624ce43@oracle.com>
<1b48aef1-5a2c-2c87-6f79-af429cbd7207@physik.fu-berlin.de>
<af22f527-d966-ce9b-779e-678a9e04585a@oracle.com>
<6b501891-e8d8-88d8-2159-c4ac6485da49@physik.fu-berlin.de>
<CAA-vtUwnVXnRPkT6Waw=q3SsV+J33TYUmY-3MM76QBYMZ9DqJg@mail.gmail.com>
<43f7de51-4fd9-3dac-2e23-f40ce3e7b4c0@physik.fu-berlin.de>
<3ea48b20-8d19-18f4-40e5-d8beb6c35461@physik.fu-berlin.de>
<49cd1bbe-0243-d34e-7990-7e727e3e509a@physik.fu-berlin.de>
<935e41ee-9618-24a8-b7e9-8a149e112006@oracle.com>
<7ebf0b4d-4e2a-f87e-be72-90d4e6490bf0@oracle.com>
<27273295-9d1b-a8a6-851b-a60705d5c27e@physik.fu-berlin.de>
<43e06d17-aba3-5110-1692-96cd061f0c14@oracle.com>
<6690f389-9f49-6ce4-c957-5f64e52afd69@physik.fu-berlin.de>
<015e93a9-3c3e-7a6e-f1f9-61eb9dea38f6@oracle.com>
<d95b74c1-0eb5-952e-0da2-cd80671bf8fb@oracle.com>
Message-ID: <1d4497d6-a59f-4a18-8333-39122c70a91b@oracle.com>
On 2018-04-18 10:00, David Holmes wrote:
> Robbin,
>
> I think it's now fixed. There were a couple of different email threads on this.
Ok, great!
/Robbin
>
> Cheers,
> David
>
> On 18/04/2018 5:50 PM, Robbin Ehn wrote:
>> Hi,
>>
>> On 2018-04-17 23:08, John Paul Adrian Glaubitz wrote:
>>> On 04/17/2018 11:05 PM, David Holmes wrote:
>>>>> This seems to be theculprit:
>>>>> http://hg.openjdk.java.net/jdk/hs/rev/0ce0ac68ace7
>>>>
>>>> So you can run okay with -XX:-ThreadLocalHandshakes ?
>>>
>>> A HellWorld runs fine although I don't know whether that verifies anything:
>>>
>>> glaubitz at deb4g:/srv/glaubitz$
>>> hs/build/linux-sparcv9-normal-server-release/jdk/bin/java
>>> -XX:-ThreadLocalHandshakes HelloWorld
>>
>> Use something like:
>> java -Xcomp -XX:LoopStripMiningIter=1 -XX:+UseCountedLoopSafepoints
>> -XX:+SafepointALot -XX:GuaranteedSafepointInterval=1 HelloWorld
>> If you are not extremely unlucky you should hit a poll exception.
>>
>> Until sparc/Linux is fixed and tested, I suggest we remove handshake support
>> for it by something like:
>> diff -r 69d7398038c5 src/hotspot/cpu/sparc/globalDefinitions_sparc.hpp
>> --- a/src/hotspot/cpu/sparc/globalDefinitions_sparc.hpp??? Wed Apr 18 09:25:51
>> 2018 +0200
>> +++ b/src/hotspot/cpu/sparc/globalDefinitions_sparc.hpp??? Wed Apr 18 09:48:13
>> 2018 +0200
>> @@ -51,8 +51,8 @@
>> ??#if defined(SOLARIS)
>> ??#define SUPPORT_RESERVED_STACK_AREA
>> +// SPARC solaris have implemented the local polling
>> +#define THREAD_LOCAL_POLL
>> ??#endif
>>
>> -// SPARC have implemented the local polling
>> -#define THREAD_LOCAL_POLL
>>
>> ??#endif // CPU_SPARC_VM_GLOBALDEFINITIONS_SPARC_HPP
>>
>>
>> /Robbin
>>
>>
>>> Hello, World
>>> glaubitz at deb4g:/srv/glaubitz$
>>>
From stefan.johansson at oracle.com Wed Apr 18 08:04:11 2018
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Wed, 18 Apr 2018 10:04:11 +0200
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
fast_path_end
In-Reply-To: <735b3949-d9cd-3d37-ebb4-f59ee61f18ad@oracle.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
<fca2bf81-0e8d-ffce-8203-080c07afb323@oracle.com>
<3AAB892A-CE21-492C-ABA2-182EF9316F06@oracle.com>
<CAF9BGBz-=JqbaJ37B5G35u3Ziei53fjhf=JMaWFd06WeZUCLfQ@mail.gmail.com>
<CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
<3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>
<CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>
<5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
<CAF9BGBxEPXLTiyD-xG_ECyveyW0PXQL0+-z7jkw3Rv4QrkkszQ@mail.gmail.com>
<ec1a3e0e-ca9b-8668-b260-1fd3e612b7f7@oracle.com>
<CAF9BGBy-LBKCwJHQPdAQ65VRcSFBwVkk9dm8MLC_nrefE_JdEw@mail.gmail.com>
<e6528c19-5691-1215-1ac5-0349801b79b5@oracle.com>
<CAF9BGBwBgyOoJTfJU_YmqYJgSZ+1985yx_sSMJC4wNJELw1XDQ@mail.gmail.com>
<e63675e1-d693-cd25-75b2-32b593e266a2@oracle.com>
<CAF9BGBz3g4yXMjf9TxrqLdMbfaswoa3U13qYTEUtv-mZCDMd8Q@mail.gmail.com>
<735b3949-d9cd-3d37-ebb4-f59ee61f18ad@oracle.com>
Message-ID: <ba26dc77-a5ba-b490-2a03-cf4abd79ac3c@oracle.com>
Hi,
On 2018-04-18 02:02, Vladimir Kozlov wrote:
> > I think I like better not to add it. If no one is using it, there
> should be
> > no reason to add it? By not adding it, it also makes any future wish to
> > have it a nice indicator of: hey why do you want to see this? Same as
> > hard_end btw which is not visible. Am I missing something?
>
> I say "may" ;)
> You don't need new function if there is no use.
>
> >
> > So to summarize, the current consensus:
> >??? - _end can be renamed either to _current_end or _fast_path_end;
> that is
> > still up to a vote and choice :)
>
> Please, use _current_end. I was thinking about _sample_end but it does
> not reflect double usage.
I'm not sure if you have seen the discussion about naming on
hotspot-gc-dev, but I and others think that _current_end doesn't
describe the usage at all. Naming it _fast_path_end would clearly state
what it is, _sample_end or something similar also crossed my mind but I
think the code reads a lot better in the compiler with the name
fast_path_end.
>
> >??? - the access method end() and tlab_end_offset() remain the same to
> not
> > modify JIT/interpreter codes
I would find this very unfortunate, having accessors that don't match
the members can easily lead to misunderstanding, especially if we have
three different *_end members. Why do you think this is the best way
forward?
My first thought was also that it would be nice to avoid all the
compiler changes, but then we would have to stick with _end being the
sample/current/fast-path end and I'm not sure that is a better solution.
I don't see the big problem with changing those accessors to what they
really access and I think the compiler code reads good even after the
change. For example:
cmpptr(end, Address(thread, JavaThread::tlab_fast_path_end_offset()));
jcc(Assembler::above, slow_case);
> >
> > If all agree to this, then the consequences are:
> >??? - JDK-8201326 becomes useless
> >??? - The work for JEP-331 becomes smaller in terms of file changes
> >??? - I'll still be needing a decision on the renaming of the TLAB
> _end field
> > (current suggestions are _current_end and _fast_path_end).
We'll see where we end up. If JDK-8201326 ends up being a separate
change I think it should be pushed at the same time as the rest of the
JEP changes. To me it only makes sense to have it in the code base if we
also have the rest of the changes.
Thanks,
Stefan
>
> Sounds good to me.
>
> Thanks,
> Vladimir
>
> On 4/17/18 4:51 PM, JC Beyler wrote:
>> Hi Vladimir and Dean,
>>
>> @Dean: seems that Vladimir is in agreement with you for renaming just the
>> field and not the method names so ack to your answer that came at the
>> same
>> time :)
>>
>>
>>> Yes, from the beginning such changes should be discussed on common
>>> hotspot-dev list since all
>>> Hotspot's parts are affected.
>>>
>>
>> Sorry, being new to the scene, most of the conversation had been going on
>> in serviceability-dev.
>>
>>
>>>
>>> Graal specific question could be send to hotspot-compiler-dev list with
>>> [Graal] in subject.
>>>
>>> I looked on JEP's changes
>>> http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.02/ to understand
>>> how
>>> it works.
>>>
>>> Few questions about proposed JEP changes so I can understand it.
>>>
>>> You introducing new TLAB end for sampling and adjust it so that
>>> allocations in JITed code and
>>> Interpreter it will trigger slow path allocation where you do sampling.
>>> Right?
>>>
>>
>> Yes that is correct; if sampling is enabled of course. Btw, this is
>> the current
>> webrev <http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.15/>.
>>
>>
>>>
>>> Do all changes to _end, _actual_end and other TLAB fields happen during
>>> slow allocation?
>>>
>>
>> Yes, to that effect, with Robbin's help, we finalized deprecating the
>> FastTLabRefill via JDK-8194084
>> <https://bugs.openjdk.java.net/browse/JDK-8194084>. Seems like I/we
>> missed
>> that Graal does this as well. I filed GRAAL-64
>> <https://bugs.openjdk.java.net/browse/GRAAL-64> to not forget that Graal
>> would need to get that fixed.
>>
>>
>>
>>>
>>> I am concern about concurrent accesses to these fields from other
>>> threads
>>> if you have them (I don't
>>> see).
>>>
>>
>> Yes that is why we deprecated the FastTlabRefill. Other threads should
>> not
>> be changing the thread local data structure so I don't see an issue
>> there.
>> The major issue was that the fast paths could change the tlab without
>> going
>> via the slowpath.
>>
>> I had a fix to detect this issue but removed it once JDK-8194084 was
>> done;
>> Graal was missed in that work so that is why if sampling were enabled
>> with
>> Graal, there is a chance things would break currently. That will get
>> fixed
>> via GRAAL-64 <https://bugs.openjdk.java.net/browse/GRAAL-64> whether
>> it is
>> rendering the code also obsolete and going to the slowpath or whether
>> it is
>> adding my fix again to detect a fastpath TLAB reallocation happened.
>>
>>
>>>
>>> Renaming. I am fine with renaming if it helps to understand code
>>> better. I
>>> agree with proposed
>>> changes to fields name:
>>>
>>> _current_end
>>> _allocation_end
>>>
>>> But, as Dean, I would suggest to keep names of access functions. This
>>> way
>>> we can say that allocation
>>> code in Interpreter and JITed code stay the same.
>>>
>>
>> Sounds good to me, then in that case, this webrev will disappear, which
>> also makes me happy, since it simplifies a lot of things (and reduces
>> code
>> change).
>>
>>
>>>
>>> You may need only new method to access _allocation_end in places which
>>> look for real end of TLAB.
>>>
>>
>> I think I like better not to add it. If no one is using it, there
>> should be
>> no reason to add it? By not adding it, it also makes any future wish to
>> have it a nice indicator of: hey why do you want to see this? Same as
>> hard_end btw which is not visible. Am I missing something?
>>
>> So to summarize, the current consensus:
>> ?? - _end can be renamed either to _current_end or _fast_path_end;
>> that is
>> still up to a vote and choice :)
>> ?? - the access method end() and tlab_end_offset() remain the same to not
>> modify JIT/interpreter codes
>>
>> If all agree to this, then the consequences are:
>> ?? - JDK-8201326 becomes useless
>> ?? - The work for JEP-331 becomes smaller in terms of file changes
>> ?? - I'll still be needing a decision on the renaming of the TLAB _end
>> field
>> (current suggestions are _current_end and _fast_path_end).
>>
>> Thanks for your help!
>> Jc
>>
>>
>>>
>>> Regards,
>>> Vladimir
>>>
>>> On 4/16/18 4:42 PM, JC Beyler wrote:
>>>> Hi Dean,
>>>>
>>>> I think perhaps this is also an attempt to figure out the naming of all
>>>> this because naming (or renaming like here) is often the start of big
>>>> conversations :).
>>>>
>>>> Originally, in the JEP-331 work, I had left the _end field as is
>>>> and, by
>>>> doing so, this whole renaming webrev goes away. However, if we do that,
>>>> then the TLAB code contains:
>>>>
>>>> _end: the fast path end, can be the allocation end or the to-be-sampled
>>> end
>>>> _allocation_end: the actual allocation end of the current TLAB
>>>> hard_end: _allocation_end + reserved space
>>>>
>>>> With an early iteration of a webrev for JEP-331, a conversation
>>>> occurred
>>>> about whether or not that was clear or not and it was determined that
>>> this
>>>> renaming was more clear:
>>>>
>>>> _current_end: the fast path end
>>>> _allocation_end: the actual allocation end of the current TLAB
>>>> reserved_end: _allocation_end + reserved space
>>>>
>>>> Because I'm trying to reduce the footprint of files changed, I
>>>> pulled out
>>>> the renaming changes into this webrev. While talking about it with
>>>> the GC
>>>> team, the renaming suggested became:
>>>>
>>>> _fast_path_end: the fast path end
>>>> _allocation_end: the actual allocation end of the current TLAB
>>>> hard_end: _allocation_end + reserved space
>>>>
>>>> Now, to be honest, any renaming or no renaming is fine by me. I like
>>>> not
>>>> renaming the fields to not change the code of every backend and
>>>> Graal; I
>>>> also like the fast_path_end rename due to it making the backend code
>>>> easy
>>>> to read as mentioned in the GC mailing lis thread.
>>>>
>>>> So there are two questions really:
>>>> ???? - Should we rename the _end field and thus provoke the changes in
>>> this
>>>> webrev?
>>>> ???? - If we do want to change the field, should/could it go in an
>>>> initial
>>>> webrev or should it go in the JEP-331 webrev whenever/ifever it goes
>>>> in?
>>>> And if we do wait, could we at least converge on a renaming now so that
>>>> this does not become a point of contention for that webrev's review?
>>>>
>>>> If I read your answer correctly:
>>>> ?????? - You are saying that we should keep the _end field
>>>> altogether; or
>>> at
>>>> least only rename the field not the methods to access it, thus reducing
>>> the
>>>> change scope.
>>>> ?????? - You are also saying to wait for the JEP-331 webrev's final
>>> iteration
>>>> and integrate it in one step
>>>>
>>>> Have I understood your answer correctly?
>>>>
>>>> Again, I am fine with renaming to whatever or not renaming at all. I
>>>> just
>>>> am trying to get forward progress here :)
>>>>
>>>> Thanks for your help!
>>>> Jc
>>>>
>>>> On Mon, Apr 16, 2018 at 3:29 PM <dean.long at oracle.com> wrote:
>>>>
>>>>> Hi JC.? Others might disagree, but I would vote "no" on doing this
>>>>> renaming now, before the JEP, and even in the context of the JEP, I
>>>>> don't think renaming the field requires renaming all the uses.? The
>>>>> compiler code is only interested in the fast path, so it's implicitly
>>>>> understood.? Also, if there is a fast_path_end(), then isn't it
>>>>> logical
>>>>> to have fast_path_start() paired with it?? ("start" is already
>>>>> overloaded, but nobody is suggesting adding
>>>>> allocation_start()/current_start()/hard_start() are they?).? My
>>>>> opinion
>>>>> is that it's fine the way it is.
>>>>>
>>>>> dl
>>>>>
>>>>> On 4/16/18 1:43 PM, JC Beyler wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I've left the mail thread from the hotspot-gc-dev below for tracking
>>>>>> purposes but will start a new request here.
>>>>>>
>>>>>> - I'm trying to push a renaming of a TLAB field to make my work for
>>>>> JEP-331
>>>>>> <http://openjdk.java.net/jeps/331> easier
>>>>>> ????? - There is an understanding that if JEP-331 does not make
>>>>>> it, this
>>>>> might
>>>>>> be useless and I'll revert if that is what the community wants;
>>>>>> however
>>>>> the
>>>>>> new name seems better anyway so perhaps not?
>>>>>>
>>>>>> - The webrev renames a field used across the various back-ends and
>>> Graal
>>>>>> ????? - The webrev is here:
>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.04/
>>>>>>
>>>>>> Could I please get some feedback on this?
>>>>>>
>>>>>> Thanks all for your help,
>>>>>> Jc
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Apr 13, 2018 at 2:37 AM Stefan Johansson <
>>>>>> stefan.johansson at oracle.com> wrote:
>>>>>>
>>>>>>> Hi JC,
>>>>>>>
>>>>>>> I don't have a name, but I've looked at bit more at the failures
>>>>>>> and I
>>>>>>> think they are unrelated and one of the local compiler engineers
>>> agree.
>>>>>>>
>>>>>>> I also ran some local testing and was not able to get any error with
>>> you
>>>>>>> latest changes, but verified that it doens't work without the graal
>>>>>>> parts. So they seem good. It might still be good to switch this over
>>> to
>>>>>>> the general hotspot-dev list to let someone with Graal knowledge to
>>> look
>>>>>>> at the change and make sure everything is correct.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Stefan
>>>>>>>
>>>>>>>
>>>>>>> On 2018-04-12 17:26, JC Beyler wrote:
>>>>>>>> Hi Stefan,
>>>>>>>>
>>>>>>>> Thanks for testing :). I've renamed the bug title in the JBS and
>>>>>>>> will
>>>>>>>> emit a new webrev shortly. Do you have the name of a compiler
>>> engineer
>>>>>>>> in mind or should I perhaps now move this conversation to the
>>>>>>>> general
>>>>>>>> hotspot-dev mailing list and ask there?
>>>>>>>>
>>>>>>>> The alternative is to add the compiler-mailing list to this email
>>>>> thread
>>>>>>>> and ask there before sending to the general list. What do you think
>>> is
>>>>>>> best?
>>>>>>>> Thanks for all your help,
>>>>>>>> Jc
>>>>>>>>
>>>>>>>> On Thu, Apr 12, 2018 at 2:09 AM Stefan Johansson
>>>>>>>> <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> ?????? On 2018-04-11 17:48, JC Beyler wrote:
>>>>>>>> ??????? > Hi Stefan,
>>>>>>>> ??????? >
>>>>>>>> ??????? > Sorry about that, I must have missed adding the files or
>>>>>>>> ?????? something. Here
>>>>>>>> ??????? > is a webrev that added the changes for the SA file:
>>>>>>>> ??????? > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/
>>>>>>>> ??????? >
>>>>>>>> ?????? No problem, this looks good. I kicked of a run in our test
>>> system
>>>>> to
>>>>>>>> ?????? get
>>>>>>>> ?????? some more coverage and have tried to include some Graal
>>> testing.
>>>>> I'll
>>>>>>>> ?????? let you know the results once they are done.
>>>>>>>>
>>>>>>>> ?????? Please also update the bug title both in JBS and the
>>>>>>>> changeset.
>>>>>>>>
>>>>>>>> ?????? Cheers,
>>>>>>>> ?????? Stefan
>>>>>>>>
>>>>>>>> ??????? > I changed the method name, which propagated a change to:
>>>>>>>> ??????? >
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
>>>>>>>> ??????? >
>>>>>>>> ??????? > I tried testing your test file. It exists in my branch
>>>>>>>> (if
>>> the
>>>>>>>> ?????? same) under:
>>>>>>>> ??????? > hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
>>>>>>>> ??????? >
>>>>>>>> ??????? > and interestingly (which generally means I did something
>>>>> wrong),
>>>>>>> it
>>>>>>>> ??????? > passed before/after the change so I could not verify that
>>> this
>>>>> is
>>>>>>>> ?????? a test
>>>>>>>> ??????? > showing that all is well in the world on my side. Any
>>>>>>>> ideas
>>> of
>>>>>>>> ?????? what I
>>>>>>>> ??????? > did wrong?
>>>>>>>> ??????? >
>>>>>>>> ??????? > I did again test it for hotspot/jtreg/compiler/aot/ and
>>>>>>>> ??????? > hotspot/jtreg/serviceability/jvmti and it passes those.
>>>>>>>> ??????? >
>>>>>>>> ??????? > Thanks for all your help,
>>>>>>>> ??????? > Jc
>>>>>>>> ??????? >
>>>>>>>> ??????? >
>>>>>>>> ??????? >
>>>>>>>> ??????? > On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson
>>>>>>>> ??????? > <stefan.johansson at oracle.com <mailto:
>>>>> stefan.johansson at oracle.com>
>>>>>>>> ?????? <mailto:stefan.johansson at oracle.com
>>>>>>>> ?????? <mailto:stefan.johansson at oracle.com>>> wrote:
>>>>>>>> ??????? >
>>>>>>>> ??????? >???? Hi JC,
>>>>>>>> ??????? >
>>>>>>>> ??????? >???? On 2018-04-11 00:56, JC Beyler wrote:
>>>>>>>> ??????? >????? > Small update:
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >????? > Here is the fixed webrev for the '{' that were
>>>>>>>> out of
>>>>>>>> ?????? alignment.
>>>>>>>> ??????? >???? This
>>>>>>>> ??????? >????? > passed release build JTREG
>>>>>>>> ?????? for hotspot/jtreg/compiler/jvmti (just
>>>>>>>> ??????? >???? to run
>>>>>>>> ??????? >????? > something as a smoke screen)
>>>>>>>> ?????? and hotspot/jtreg/compiler/aot/ (to
>>>>>>>> ??????? >???? test
>>>>>>>> ??????? >????? > Graal).
>>>>>>>> ??????? >????? >
>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >???? I think this looks better, I agree that leaving
>>>>>>>> _end is
>>>>>>>> ?????? tempting to
>>>>>>>> ??????? >???? avoid a lot of change, but I think this will be
>>>>>>>> better
>>> in
>>>>> the
>>>>>>>> ?????? long run.
>>>>>>>> ??????? >
>>>>>>>> ??????? >???? I still miss the changes to make the SA work. To
>>>>>>>> see a
>>>>>>>> ?????? problem you
>>>>>>>> ??????? >???? can run:
>>>>>>>> ??????? >???? make CONF=fast run-test
>>>>>>>> ??????? >
>>>>> ?? TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
>>>>>>>> ??????? >
>>>>>>>> ??????? >???? Cheers,
>>>>>>>> ??????? >???? Stefan
>>>>>>>> ??????? >
>>>>>>>> ??????? >????? > Let me know what you think,
>>>>>>>> ??????? >????? > Jc
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >????? > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler
>>>>>>>> ?????? <jcbeyler at google.com <mailto:jcbeyler at google.com>
>>>>>>>> ??????? >???? <mailto:jcbeyler at google.com
>>>>>>>> <mailto:jcbeyler at google.com
>>>>>
>>>>>>>> ??????? >????? > <mailto:jcbeyler at google.com <mailto:
>>> jcbeyler at google.com
>>>>>>
>>>>>>>> ?????? <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>>>
>>>>> wrote:
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >????? >???? Hi Karen and Stefan,
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >????? >???? @Stefan: Naming is hard :)
>>>>>>>> ??????? >????? >???? @Karen: thanks for the Graal comment, I
>>>>>>>> fixed it
>>> in
>>>>>>>> ?????? the new
>>>>>>>> ??????? >???? webrev,
>>>>>>>> ??????? >????? >???? let me know what you think :)
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >????? >???? I think the naming convention suggested in
>>>>>>>> this
>>>>> webrev
>>>>>>>> ?????? came from
>>>>>>>> ??????? >????? >???? conversations in for JEP-331 and I am actually
>>>>>>> relatively
>>>>>>>> ??????? >????? >???? indifferent to the final result (as long as we
>>> have
>>>>>>>> ?????? some form of
>>>>>>>> ??????? >????? >???? forward progress :)). To be honest, I'd
>>>>>>>> also be
>>>>> happy
>>>>>>>> ?????? to just
>>>>>>>> ??????? >???? leave
>>>>>>>> ??????? >????? >???? _end as is for all architectures and Graal and
>>> have
>>>>> a
>>>>>>> new
>>>>>>>> ??????? >????? >???? _allocation_end. However, during initial
>>>>>>>> reviews
>>> of
>>>>>>>> ?????? JEP-331
>>>>>>>> ??????? >???? it was
>>>>>>>> ??????? >????? >???? deemed complicated to understand:
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >????? >???? _end -> the _end or sampling end
>>>>>>>> ??????? >????? >???? _allocation_end -> end pointer for the last
>>> possible
>>>>>>>> ?????? allocation
>>>>>>>> ??????? >????? >???? hard_end -> allocation end + reserved space
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >????? >???? That is how this naming came up and why
>>>>>>>> hard_end
>>>>> went
>>>>>>> to
>>>>>>>> ??????? >???? "reserved_end".
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >????? >???? I'm really indifferent, so I offer as a
>>>>>>>> perusal:
>>>>>>>> ??????? >????? >
>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >????? >???? I noticed a few problems of alignement of
>>>>>>>> '{' so
>>>>> I'll
>>>>>>>> ?????? go fix
>>>>>>>> ??????? >???? that.
>>>>>>>> ??????? >????? >???? Basically this webrev does the following:
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >????? >???? - Uses fast_path_end instead of end
>>>>>>>> ??????? >????? >???? - Reverts hard_end back to where it was
>>>>>>>> ??????? >????? >???? - Adds the changes to Graal; there is a
>>>>>>>> bunch of
>>>>>>>> ?????? changes in Graal
>>>>>>>> ??????? >????? >???? because Graal still contains a bit of code
>>>>>>>> doing
>>>>>>>> ?????? fasttlabrefills.
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >????? >???? Let me know what you think!
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >????? >???? Thanks,
>>>>>>>> ??????? >????? >???? Jc
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >????? >???? On Tue, Apr 10, 2018 at 6:56 AM Karen Kinnear
>>>>>>>> ??????? >????? >???? <karen.kinnear at oracle.com
>>>>>>>> ?????? <mailto:karen.kinnear at oracle.com> <mailto:
>>>>> karen.kinnear at oracle.com
>>>>>>>> ?????? <mailto:karen.kinnear at oracle.com>>
>>>>>>>> ??????? >???? <mailto:karen.kinnear at oracle.com
>>>>>>>> ?????? <mailto:karen.kinnear at oracle.com> <mailto:
>>>>> karen.kinnear at oracle.com
>>>>>>>> ?????? <mailto:karen.kinnear at oracle.com>>>>
>>>>>>>> ??????? >???? wrote:
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >????? >???????? Hi JC,
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >????? >???????? A comment about Graal. The impact on Graal
>>> for
>>>>> this
>>>>>>>> ??????? >???? particular
>>>>>>>> ??????? >????? >???????? change would be to break it - so you?ll
>>>>>>>> need
>>>>>>>> ??????? >????? >???????? to complete the Graal changes for this
>>> renaming.
>>>>>>>> ?????? That isn?t
>>>>>>>> ??????? >????? >???????? optional or something that could be a
>>>>> follow-on. It
>>>>>>>> ??????? >????? >???????? is not ok to break a feature, even an
>>>>> experimental
>>>>>>>> ?????? one.
>>>>>>>> ??????? >???? We will
>>>>>>>> ??????? >????? >???????? discuss in the other thread potential
>>> phasing of
>>>>>>>> ?????? adding
>>>>>>>> ??????? >???? sampling.
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >????? >???????? I did not do a thorough search -you can do
>>> that
>>>>> -
>>>>>>>> ?????? I did find
>>>>>>>> ??????? >????? >
>>>>>>>> src/jdk.internal.vm.compiler/share/classes/
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>
>>>>>>>> ??????? >????? >??????????? public final int threadTlabOffset =
>>>>>>>> ??????? >????? >???????? getFieldOffset("Thread::_tlab",
>>> Integer.class,
>>>>>>>> ??????? >????? >???????? "ThreadLocalAllocBuffer");
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>
>>>>>>>> ??????? >????? >??????????? private final int
>>>>>>>> ?????? threadLocalAllocBufferStartOffset =
>>>>>>>> ??????? >????? >
>>> ? getFieldOffset("ThreadLocalAllocBuffer::_start",
>>>>>>>> ??????? >???? Integer.class,
>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>
>>>>>>>> ??????? >????? >??????????? private final int
>>>>>>> threadLocalAllocBufferEndOffset =
>>>>>>>> ??????? >????? >
>>> ? getFieldOffset("ThreadLocalAllocBuffer::_end",
>>>>>>>> ?????? Integer.class,
>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>
>>>>>>>> ??????? >????? >??????????? private final int
>>>>>>> threadLocalAllocBufferTopOffset =
>>>>>>>> ??????? >????? >
>>> ? getFieldOffset("ThreadLocalAllocBuffer::_top",
>>>>>>>> ?????? Integer.class,
>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>
>>>>>>>> ??????? >????? >??????????? private final int
>>>>>>>> ?????? threadLocalAllocBufferPfTopOffset =
>>>>>>>> ??????? >????? >
>>>>> ?? getFieldOffset("ThreadLocalAllocBuffer::_pf_top",
>>>>>>>> ??????? >???? Integer.class,
>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>
>>>>>>>> ??????? >????? >??????????? private final int
>>>>>>>> ??????? >???? threadLocalAllocBufferSlowAllocationsOffset
>>>>>>>> ??????? >????? >???????? =
>>>>>>>> ?????? getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
>>>>>>>> ??????? >????? >???????? Integer.class, "unsigned");
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>
>>>>>>>> ??????? >????? >??????????? private final int
>>>>>>>> ??????? >???? threadLocalAllocBufferFastRefillWasteOffset
>>>>>>>> ??????? >????? >???????? =
>>>>>>>> ??????? >
>>>>> ?? getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
>>>>>>>> ??????? >????? >???????? Integer.class, "unsigned");
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>
>>>>>>>> ??????? >????? >??????????? private final int
>>>>>>>> ??????? >???? threadLocalAllocBufferNumberOfRefillsOffset
>>>>>>>> ??????? >????? >???????? =
>>>>>>>> ??????? >
>>>>> ?? getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
>>>>>>>> ??????? >????? >???????? Integer.class, "unsigned");
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>
>>>>>>>> ??????? >????? >??????????? private final int
>>>>>>>> ??????? >????? >
>>>>>>>> threadLocalAllocBufferRefillWasteLimitOffset
>>> =
>>>>>>>> ??????? >????? >
>>>>>>>>
>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
>>>>>>>> ??????? >????? >???????? Integer.class, "size_t");
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>
>>>>>>>> ??????? >????? >??????????? private final int
>>>>>>>> ??????? >???? threadLocalAllocBufferDesiredSizeOffset =
>>>>>>>> ??????? >????? >
>>>>>>>> ???????? getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
>>>>>>>> ??????? >????? >???????? Integer.class, "size_t");
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>
>>>>>>>> ??????? >????? >??????????? public final int tlabAlignmentReserve =
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>> getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
>>>
>>>>>>>> ??????? >????? >???????? Integer.class, "size_t?);
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >????? >???????? hope this helps,
>>>>>>>> ??????? >????? >???????? Karen
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >????? >>???????? On Apr 10, 2018, at 7:04 AM, Stefan
>>> Johansson
>>>>>>>> ??????? >????? >>???????? <stefan.johansson at oracle.com
>>>>>>>> ?????? <mailto:stefan.johansson at oracle.com>
>>>>>>>> ??????? >???? <mailto:stefan.johansson at oracle.com
>>>>>>>> ?????? <mailto:stefan.johansson at oracle.com>>
>>>>>>>> ??????? >????? >>???????? <mailto:stefan.johansson at oracle.com
>>>>>>>> ?????? <mailto:stefan.johansson at oracle.com>
>>>>>>>> ??????? >???? <mailto:stefan.johansson at oracle.com
>>>>>>>> ?????? <mailto:stefan.johansson at oracle.com>>>> wrote:
>>>>>>>> ??????? >????? >>
>>>>>>>> ??????? >????? >>???????? Hi JC,
>>>>>>>> ??????? >????? >>
>>>>>>>> ??????? >????? >>???????? I realize that the names have been
>>>>>>>> discussed
>>>>>>>> ?????? before but I'm
>>>>>>>> ??????? >????? >>???????? leaning towards suggesting something
>>>>>>>> new. We
>>>>>>>> ?????? discussed this
>>>>>>>> ??????? >????? >>???????? briefly here in the office and others
>>>>>>>> might
>>>>> have
>>>>>>>> ?????? different
>>>>>>>> ??????? >????? >>???????? opinions. One point that came up is
>>>>>>>> that if
>>> we
>>>>> do
>>>>>>>> ?????? this
>>>>>>>> ??????? >???? change
>>>>>>>> ??????? >????? >>???????? and change all usages of
>>>>>>>> ?????? JavaThread::tlab_end_offset() it
>>>>>>>> ??????? >????? >>???????? would be good to make sure the new
>>>>>>>> name is
>>>>> good.
>>>>>>>> ?????? To us
>>>>>>>> ??????? >????? >>???????? _current_end is not very descriptive, but
>>>>> naming
>>>>>>>> ?????? is hard and
>>>>>>>> ??????? >????? >>???????? the best we could come up with is
>>>>> _fast_path_end
>>>>>>>> ?????? which would
>>>>>>>> ??????? >????? >>???????? give the code:
>>>>>>>> ??????? >????? >>????????? cmpptr(end, Address(thread,
>>>>>>>> ??????? >????? >>
>>>>>>>> JavaThread::tlab_fast_path_end_offset()));
>>>>>>>> ??????? >????? >>????????? jcc(Assembler::above, slow_case);
>>>>>>>> ??????? >????? >>
>>>>>>>> ??????? >????? >>???????? I think this reads pretty good and is
>>>>>>>> fairly
>>>>>>>> ?????? clear. If we do
>>>>>>>> ??????? >????? >>???????? this rename I think you can re-use
>>>>>>>> _end in
>>>>> JEP-331
>>>>>>>> ??????? >???? instead of
>>>>>>>> ??????? >????? >>???????? calling it _allocation_end. But that is a
>>> later
>>>>>>>> ?????? review :)
>>>>>>>> ??????? >????? >>
>>>>>>>> ??????? >????? >>???????? Also, is there a good reason for renaming
>>>>>>>> ?????? hard_end() to
>>>>>>>> ??????? >????? >>???????? reserved_end()?
>>>>>>>> ??????? >????? >>
>>>>>>>> ??????? >????? >>???????? One additional thing, you need to update
>>> the SA
>>>>>>>> ?????? to reflect
>>>>>>>> ??????? >????? >>???????? this change. I think the only place you
>>> need to
>>>>>>>> ?????? fix is in:
>>>>>>>> ??????? >????? >>
>>>>>>>> ??????? >
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
>>>
>>>>>>>> ??????? >????? >>
>>>>>>>> ??????? >????? >>???????? Thanks,
>>>>>>>> ??????? >????? >>???????? Stefan
>>>>>>>> ??????? >????? >>
>>>>>>>> ??????? >????? >>???????? On 2018-04-09 19:24, JC Beyler wrote:
>>>>>>>> ??????? >????? >>>???????? Hi all,
>>>>>>>> ??????? >????? >>>???????? Small pre-amble to this request:
>>>>>>>> ??????? >????? >>>???????? In my work to try to get a heap
>>>>>>>> sampler in
>>>>>>>> ?????? OpenJDK (via JEP
>>>>>>>> ??????? >????? >>>???????? 331
>>>>>>>> ??????? >???? <https://bugs.openjdk.java.net/browse/JDK-8171119>),
>>> I'm
>>>>>>>> ??????? >????? >>>???????? trying to reduce the footprint of my
>>> change so
>>>>>>>> ?????? that the
>>>>>>>> ??????? >????? >>>???????? integration can be easier. I was told
>>>>>>>> that
>>>>>>>> ?????? generally a JEP
>>>>>>>> ??????? >????? >>>???????? webrev should be feature complete and
>>>>>>>> go in
>>>>>>> at-once.
>>>>>>>> ??????? >???? However,
>>>>>>>> ??????? >????? >>>???????? with the change touching quite a bit of
>>>>> various
>>>>>>> code
>>>>>>>> ??????? >???? pieces,
>>>>>>>> ??????? >????? >>>???????? I was trying to figure out what could be
>>>>>>>> ?????? separated as not
>>>>>>>> ??????? >????? >>>???????? "part of the feature".
>>>>>>>> ??????? >????? >>>???????? I asked around and said that perhaps a
>>>>> solution
>>>>>>>> ?????? would be to
>>>>>>>> ??????? >????? >>>???????? cut up the renaming of TLAB's end field
>>> that I
>>>>>>>> ?????? do in that
>>>>>>>> ??????? >????? >>>???????? webrev. Because I'm renaming a field in
>>> TLAB
>>>>>>> used by
>>>>>>>> ??????? >???? various
>>>>>>>> ??????? >????? >>>???????? backends for that work, I have to update
>>> every
>>>>>>>> ?????? architecture
>>>>>>>> ??????? >????? >>>???????? dependent code to reflect it.
>>>>>>>> ??????? >????? >>>???????? I entirely understand that perhaps
>>>>>>>> this is
>>> not
>>>>>>>> ?????? in the
>>>>>>>> ??????? >???? habits
>>>>>>>> ??????? >????? >>>???????? and very potentially might not be the
>>>>>>>> way
>>>>> things
>>>>>>> are
>>>>>>>> ??????? >????? >>>???????? generally done. If so, I apologize
>>>>>>>> and let
>>> me
>>>>>>>> ?????? know if you
>>>>>>>> ??????? >????? >>>???????? would not want this to go in
>>>>>>>> separately :)
>>>>>>>> ??????? >????? >>>???????? Final note: there is still a chance
>>>>>>>> JEP-331
>>>>> does
>>>>>>>> ?????? not go in.
>>>>>>>> ??????? >????? >>>???????? If it does not, we can leave the new
>>>>>>>> name
>>> in
>>>>>>>> ?????? place or I'll
>>>>>>>> ??????? >????? >>>???????? happily revert it. I can even create an
>>> issue
>>>>> to
>>>>>>>> ?????? track this
>>>>>>>> ??????? >????? >>>???????? if that makes it easier for all.
>>>>>>>> ??????? >????? >>>???????? End of the pre-amble.
>>>>>>>> ??????? >????? >>>???????? The 33-line change webrev in question is
>>> here:
>>>>>>>> ??????? >????? >>>
>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
>>>>>>>> ??????? >????? >>>???????? I fixed all the architectures and
>>>>>>>> JVMCI and
>>>>> ran
>>>>>>>> ?????? a few
>>>>>>>> ??????? >???? sanity
>>>>>>>> ??????? >????? >>>???????? tests to ensure I had not missed
>>>>>>>> anything.
>>>>>>>> ??????? >????? >>>???????? Thanks for your help and I hope this
>>>>>>>> is not
>>>>> too
>>>>>>> much
>>>>>>>> ??????? >???? trouble,
>>>>>>>> ??????? >????? >>>???????? Jc
>>>>>>>> ??????? >????? >>>???????? Ps: there is a graal change that
>>>>>>>> needs to
>>>>> happen
>>>>>>>> ?????? but I was
>>>>>>>> ??????? >????? >>>???????? not sure who/where
>>> <https://teams.googleplex.com/u/where>
>>>>> <https://teams.googleplex.com/u/where>
>>>>>>> <https://teams.googleplex.com/u/where>
>>>>>>>> ?????? <https://teams.googleplex.com/u/where>
>>>>>>>> ??????? >???? <https://teams.googleplex.com/u/where>
>>>>>>>> ??????? >???? <https://teams.googleplex.com/u/where> to
>>>>>>>> ??????? >????? >>>???????? ask about it. I was told it could happen
>>> in a
>>>>>>>> ?????? separate
>>>>>>>> ??????? >????? >>>???????? webrev. Can anyone point me to the right
>>>>>>> direction?
>>>>>>>> ??????? >???? Should it
>>>>>>>> ??????? >????? >>>???????? just be hotspot-compiler-dev?
>>>>>>>> ??????? >????? >
>>>>>>>> ??????? >
>>>>>>>>
>>>>>
>>>>>
>>>
From david.holmes at oracle.com Wed Apr 18 08:14:46 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Apr 2018 18:14:46 +1000
Subject: jdk/jdk OPEN for HotSpot pushes (Re: Merging jdk/hs with jdk/jdk)
In-Reply-To: <3DAF861F-3649-447E-BEFB-3BD605F8FB41@oracle.com>
References: <8819CAD3-AF29-463E-8A76-14440CF37D2B@oracle.com>
<952F85EF-BB76-4645-AC05-F843DB83881B@oracle.com>
<EEA812F6-693C-41D9-87B4-5F66B478F9DB@oracle.com>
<585020bc-6f0f-5dd0-19e7-4ade558557d3@physik.fu-berlin.de>
<F3D99DFF-9479-4A93-A9CC-9E0BC02D078D@oracle.com>
<fcfaa52c-dc63-8f00-4955-3a95b9d6bfa6@oracle.com>
<3DAF861F-3649-447E-BEFB-3BD605F8FB41@oracle.com>
Message-ID: <c0b11099-7e93-96e8-51c8-53f29f31a597@oracle.com>
Sorry misread it.
David
On 18/04/2018 6:02 PM, jesper.wilhelmsson at oracle.com wrote:
> Yes, submit-hs is read only now. But the latest push was to jdk/submit
> /Jesper
>
>> On 18 Apr 2018, at 09:59, David Holmes <david.holmes at oracle.com> wrote:
>>
>> IIRC they disabled submit-hs due to the switch to jdk/jdk
>>
>> David
>>
>> On 18/04/2018 5:46 PM, jesper.wilhelmsson at oracle.com wrote:
>>>> On 18 Apr 2018, at 09:10, John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de> wrote:
>>>>
>>>> Hi Jesper
>>>>
>>>> On 04/17/2018 06:18 PM, jesper.wilhelmsson at oracle.com wrote:
>>>>> The final jdk/hs integration has landed in jdk/jdk. jdk/jdk is now open for regular hotspot pushes.
>>>>>>> As part of this
>>>>>>> merge we can also retire the newly setup submit-hs [3] repository
>>>>>>> and do all testing using the submit repo based on jdk/jdk [4].
>>>> (...)
>>>>>>> [4] http://hg.openjdk.java.net/jdk/submit <http://hg.openjdk.java.net/jdk/submit> <http://hg.openjdk.java.net/jdk/submit <http://hg.openjdk.java.net/jdk/submit>>
>>>>
>>>> I pushed a change to the submit repository yesterday [1] but I still
>>>> haven't back from the testing environment. For submit-hs, the result
>>>> mail usually came back a couple of hours later.
>>>>
>>>> Is the queue currently just very full or are there any issues at the
>>>> moment?
>>> I don't see any job with your username (glaubitz) and the bug id 8201616. The most recent is from six days ago, 8201480.
>>> Most likely something went wrong when starting the job. I do see your push in the submit repo. Try to push some trivial change to the same branch, that should trigger a new test job.
>>> /Jesper
>>>>
>>>> Adrian
>>>>
>>>>> [1] http://hg.openjdk.java.net/jdk/submit/rev/2417c3dddb34
>>>>
>>>> --
>>>> .''`. John Paul Adrian Glaubitz
>>>> : :' : Debian Developer - glaubitz at debian.org
>>>> `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>>>> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
>
From per.liden at oracle.com Wed Apr 18 08:25:30 2018
From: per.liden at oracle.com (Per Liden)
Date: Wed, 18 Apr 2018 10:25:30 +0200
Subject: RFR: 8201647: Make initial clearing of CHeapBitMap optional
In-Reply-To: <1523969911.2369.6.camel@oracle.com>
References: <336cf9d0-0c71-0a01-8c4f-51103c39acc3@oracle.com>
<1523969911.2369.6.camel@oracle.com>
Message-ID: <2483f256-d329-d01d-d80e-6c2b06537ca1@oracle.com>
Thanks Thomas!
/Per
On 04/17/2018 02:58 PM, Thomas Schatzl wrote:
> Hi,
>
> On Tue, 2018-04-17 at 14:38 +0200, Per Liden wrote:
>> CHeapBitMap objects will by default clear the underlying bitmap
>> during construction. In ZGC we don't want mark bitmaps to be cleared
>> on construction, since we instead do this lazily during concurrent
>> marking.
>>
>> This patch adds a "bool clear = true" argument to CHeapBitMap's
>> constructor to be able to opt-out of this behavior.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201647
>> Webrev: http://cr.openjdk.java.net/~pliden/8201647/webrev.0
>>
>> /Per
>
> looks good.
>
> Thomas
>
From per.liden at oracle.com Wed Apr 18 08:26:05 2018
From: per.liden at oracle.com (Per Liden)
Date: Wed, 18 Apr 2018 10:26:05 +0200
Subject: RFR: 8201647: Make initial clearing of CHeapBitMap optional
In-Reply-To: <CAEGA6kZt3hyg1j5yCzvMs--rHymuNSruvNkV9_VDW3pOqWu0LQ@mail.gmail.com>
References: <336cf9d0-0c71-0a01-8c4f-51103c39acc3@oracle.com>
<CAEGA6kZt3hyg1j5yCzvMs--rHymuNSruvNkV9_VDW3pOqWu0LQ@mail.gmail.com>
Message-ID: <18882abb-2b2c-16ca-ecba-6985a7fcfa3b@oracle.com>
Thanks Stuart!
/Per
On 04/17/2018 03:17 PM, Stuart Monteith wrote:
> Not that I'm a reviewer, but that looks good to me.
>
> On 17 April 2018 at 13:38, Per Liden <per.liden at oracle.com> wrote:
>> CHeapBitMap objects will by default clear the underlying bitmap during
>> construction. In ZGC we don't want mark bitmaps to be cleared on
>> construction, since we instead do this lazily during concurrent marking.
>>
>> This patch adds a "bool clear = true" argument to CHeapBitMap's constructor
>> to be able to opt-out of this behavior.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201647
>> Webrev: http://cr.openjdk.java.net/~pliden/8201647/webrev.0
>>
>> /Per
From thomas.stuefe at gmail.com Wed Apr 18 08:32:48 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 18 Apr 2018 08:32:48 +0000
Subject: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
In-Reply-To: <43ae45216d3545518b274dd7246d7862@sap.com>
References: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
<CAA-vtUz48xUdXQzDEAuS2JDdnis7n2pAjfJ52dgFkhKskNoX9Q@mail.gmail.com>
<b65af851-d138-42b2-847a-fd6650a1767b@oracle.com>
<CAA-vtUz+cyza6GOnVN7p-9XJ-JYo_vBozMNh0K=7woUbV4mKzA@mail.gmail.com>
<b0fcb60f-ff76-9b98-871c-8692f4504442@oracle.com>
<43ae45216d3545518b274dd7246d7862@sap.com>
Message-ID: <CAA-vtUxSJ_DWSABFggKdcLJgNcWhELr0Ud9=D0g=AYspzBisww@mail.gmail.com>
Sounds good to me.
Gru? Thomas
On Wed, Apr 18, 2018, 09:58 Langer, Christoph <christoph.langer at sap.com>
wrote:
> cc-ing hotspot-runtime-dev as Dan mentioned in the bug that it should
> rather be there.
>
> Hi Thomas, David,
>
> I think it could be cleaned up nicely by removing jio_print and jio_printf
> from jvm.cpp and doing all in ostream.cpp. At the one place where we would
> call jio_print after my patch, we can do the vfprintf hook check and then
> either write to the hook or do the raw write. And the other 2 places where
> jio_printf is employed, we can just call
> jio_vfprintf(defaultStream::output_stream()). I don't see any other users
> of jio_print and jio_printf in the jdk repo.
>
> Any objections to that (e.g. some Oracle closed coding that'd break)?
> Otherwise I'll prepare something...
>
> Best regards
> Christoph
>
>
> > -----Original Message-----
> > From: David Holmes [mailto:david.holmes at oracle.com]
> > Sent: Mittwoch, 18. April 2018 07:59
> > To: Thomas St?fe <thomas.stuefe at gmail.com>
> > Cc: Langer, Christoph <christoph.langer at sap.com>; hotspot-
> > dev at openjdk.java.net
> > Subject: Re: RFR(S): 8201649: Remove dubious call_jio_print in
> ostream.cpp
> >
> > On 18/04/2018 2:47 PM, Thomas St?fe wrote:
> > > Hi David,
> > >
> > > On Tue, Apr 17, 2018 at 11:17 PM, David Holmes
> > <david.holmes at oracle.com> wrote:
> > >> On 18/04/2018 1:48 AM, Thomas St?fe wrote:
> > >>>
> > >>> Hi Christoph,
> > >>>
> > >>> I do not understand jio_print() at all. I think it is just wrong: if
> a
> > >>> vfprintf hook is set, it prints to the
> defaultStream::output_stream(),
> > >>> otherwise to defaultStream::output_fd()? Isnt that the same? Compare
> > >>> this to jio_vfprintf(), which does the same logic, but correctly
> > >>> prints to the vfprintf hook if it is set.
> > >>
> > >>
> > >> If there is a hook it does a formatted print: jio_print ->
> jio_fprintf ->
> > >> jio_vfprintf -> Arguments::vfprintf_hook()
> > >> else it does a raw write.
> > >
> > > Oh, I missed that.
> > >
> > > So, jio_print() checks if a vfprintf hook is installed.
> > >
> > > If it is, it calls jio_fprintf() with defaultStream::output_stream()
> > > as output file handle. It expects jio_fprintf() to call
> > > jio_vfprintf(), which should do the same check again and come to the
> > > same conclusion, then should disregard the output file handle handed
> > > down, instead call the vfprintf hook.
> > >
> > > (The output file handle is handed down as argument to the vfprintf
> > > hook; we had a discussion last year about it:
> > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> > May/026794.html
> > > and we were not sure that made any sense.)
> >
> > I had forgotten about that. :)
> >
> > > Not very clear coding. I think that can be improved by removing the
> > > vfprintf hook check from jio_print completely and make jio_vfprintf()
> > > be the only place where the vfprintf hook is handled.
> > >
> > > For example, this would be equivalent:
> > >
> > > void jio_print(const char* s) {
> > > jio_printf("%s", s);
> > > }
> > >
> > > or this:
> > >
> > > void jio_print(const char* s) {
> > > jio_fprintf(defaultStream::output_stream(), "%s", s);
> > > }
> >
> > They aren't equivalent because the always do a formatted write, never
> > the raw write the currently exists. Does that matter? <shrug> no idea. I
> > don't have time to do any archaeology on this piece of code - sorry.
> >
> > Cheers,
> > David
> > -----
> >
> > > in which case we could also maybe also remove jio_printf(), because it
> > > is nowhere used inside the hotspot (though it is exported, but I find
> > > no reference to it being used anywhere in the OpenJDK).
> > >
> > >>
> > >> Now why it does this is another matter. I have no idea. But I wouldn't
> > >> suggest changing it just because I don't know why it's done the way
> it is.
> > >
> > > I was reasonably sure I had understood the function, and that it was
> > > broken. In that case the proposal to change or remove it made sense.
> > >
> > > Thomas
> > >
> > >>
> > >> David
> > >>
> > >>
> > >>
> > >>> I would propose to get rid of jio_print() altogether and replace the
> > >>> few callers of it (all in ostream.cpp) with this:
> > >>>
> > >>> jio_printf("%s", string);
> > >>>
> > >>> which does the same, but correctly.
> > >>>
> > >>> Best Regards, Thomas
> > >>>
> > >>> On Tue, Apr 17, 2018 at 4:48 PM, Langer, Christoph
> > >>> <christoph.langer at sap.com> wrote:
> > >>>>
> > >>>> Hi,
> > >>>>
> > >>>> can you please review a fix proposal for defaultStream::write(const
> > char*
> > >>>> s, size_t len).
> > >>>>
> > >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201649
> > >>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201649.0/
> > >>>>
> > >>>> I have seen occurrences of truncated buffers which don't need to
> > happen.
> > >>>>
> > >>>> Thanks and best regards
> > >>>> Christoph
> > >>>>
> > >>
>
From adinn at redhat.com Wed Apr 18 08:42:53 2018
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 18 Apr 2018 09:42:53 +0100
Subject: RFR (M) 8201556: Disallow reading oops in ClassLoaderData if
unloading
In-Reply-To: <c22b8e6c-69e4-34bf-11d2-cc75c30204b8@oracle.com>
References: <c22b8e6c-69e4-34bf-11d2-cc75c30204b8@oracle.com>
Message-ID: <cfe9f9d1-ed56-c8cd-ff0b-3ad8dd865479@redhat.com>
Hi Coleen,
On 17/04/18 17:02, coleen.phillimore at oracle.com wrote:
> Summary: Move class_loader oop to an OopHandle, and assert that holder
> is alive when getting class_loader.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8201556.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8201556
>
> Tested with mach5 tiers 1-7.
I have just been browsing the code in this area so thought I should
offer a 2nd review. The changes all look good to me (subtracting the
typo and legacy closure Kim mentioned).
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
From shade at redhat.com Wed Apr 18 08:46:55 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 18 Apr 2018 10:46:55 +0200
Subject: RFR 8201785: Provide default implementations for
ModRefBarrierSetAssembler::oop_store_at for all platforms
Message-ID: <0e56d51f-7270-b894-9967-e44940b0cb4c@redhat.com>
RFE:
https://bugs.openjdk.java.net/browse/JDK-8201785
Webrev:
http://cr.openjdk.java.net/~shade/8201785/webrev.01/
Found this when while rebasing Epsilon to the recent jdk/jdk -- Epsilon defers to ModRefBS for
interpreter barriers. It makes more sense to me for ModRefBS to provide the default implementations
for all platforms, rather than it being abstract on some platforms. It follows what AArch64 and PPC
are doing right now, and aligns better with arraycopy barriers already implemented by default in
ModRefBS.
Testing: x86_64 build, Epsilon tests, jdk-submit (running)
Thanks,
-Aleksey
From glaubitz at physik.fu-berlin.de Wed Apr 18 09:01:51 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Wed, 18 Apr 2018 11:01:51 +0200
Subject: jdk/jdk OPEN for HotSpot pushes (Re: Merging jdk/hs with jdk/jdk)
In-Reply-To: <fcfaa52c-dc63-8f00-4955-3a95b9d6bfa6@oracle.com>
References: <8819CAD3-AF29-463E-8A76-14440CF37D2B@oracle.com>
<952F85EF-BB76-4645-AC05-F843DB83881B@oracle.com>
<EEA812F6-693C-41D9-87B4-5F66B478F9DB@oracle.com>
<585020bc-6f0f-5dd0-19e7-4ade558557d3@physik.fu-berlin.de>
<F3D99DFF-9479-4A93-A9CC-9E0BC02D078D@oracle.com>
<fcfaa52c-dc63-8f00-4955-3a95b9d6bfa6@oracle.com>
Message-ID: <25de1740-83d3-14ec-43f9-5d4bac30e28b@physik.fu-berlin.de>
Hi David!
On 04/18/2018 09:59 AM, David Holmes wrote:
> IIRC they disabled submit-hs due to the switch to jdk/jdk
I pushed to submit, not submit-hs ;).
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From glaubitz at physik.fu-berlin.de Wed Apr 18 09:14:52 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Wed, 18 Apr 2018 11:14:52 +0200
Subject: jdk/jdk OPEN for HotSpot pushes (Re: Merging jdk/hs with jdk/jdk)
In-Reply-To: <F3D99DFF-9479-4A93-A9CC-9E0BC02D078D@oracle.com>
References: <8819CAD3-AF29-463E-8A76-14440CF37D2B@oracle.com>
<952F85EF-BB76-4645-AC05-F843DB83881B@oracle.com>
<EEA812F6-693C-41D9-87B4-5F66B478F9DB@oracle.com>
<585020bc-6f0f-5dd0-19e7-4ade558557d3@physik.fu-berlin.de>
<F3D99DFF-9479-4A93-A9CC-9E0BC02D078D@oracle.com>
Message-ID: <5564dce5-914c-0371-5146-003ca96a1340@physik.fu-berlin.de>
On 04/18/2018 09:46 AM, jesper.wilhelmsson at oracle.com wrote:
> I don't see any job with your username (glaubitz) and the bug id 8201616. The most recent is from six days ago, 8201480.
> Most likely something went wrong when starting the job. I do see your push in the submit repo. Try to push some trivial change to the same branch, that should trigger a new test job.
Ok, I just pushed another NOP change by adding a comment.
Let's see if that works.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From shade at redhat.com Wed Apr 18 09:20:00 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 18 Apr 2018 11:20:00 +0200
Subject: [11]RFR(S): 8201509: Zero : S390x (S390 and not _LP64)
atomic_copy64 inline assembler is wrong.
In-Reply-To: <2061faf8-b9f3-4559-4774-d55f450e0de8@LGonQn.Org>
References: <2061faf8-b9f3-4559-4774-d55f450e0de8@LGonQn.Org>
Message-ID: <687b2ace-58a4-8807-ff38-aac261cf291e@redhat.com>
On 04/17/2018 05:46 PM, Chris Phillips wrote:
> Hi,
>
> Please review this small but significant change to Zero only code
> related to S390 (31bit) Zero self-build failures.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201509
> webrev: http://cr.openjdk.java.net/~chrisphi/JDK-8201509/webrev.1
Looks okay to me.
In addition to discussion in the bug itself, it seems we can argue it should look similar to the
PPC32 && !__SPE__ block above. Which is does, as far as operands are concerned. But, are we sure
ld/std is enough to copy 64 bits on S390? I assume "d" is for double in those insns?
Thanks,
-Aleksey
From erik.osterlund at oracle.com Wed Apr 18 10:12:38 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Wed, 18 Apr 2018 12:12:38 +0200
Subject: RFR 8201785: Provide default implementations for
ModRefBarrierSetAssembler::oop_store_at for all platforms
In-Reply-To: <0e56d51f-7270-b894-9967-e44940b0cb4c@redhat.com>
References: <0e56d51f-7270-b894-9967-e44940b0cb4c@redhat.com>
Message-ID: <5AD71A16.3060004@oracle.com>
Hi Aleksey,
Why are you instantiating a ModRefBarrierSetAssembler as opposed to a
BarrierSetAssembler? ModRef is meant as an abstract class for GCs that
have a notion of write barriers. I don't believe your GC has such a notion.
Thanks,
/Erik
On 2018-04-18 10:46, Aleksey Shipilev wrote:
> RFE:
> https://bugs.openjdk.java.net/browse/JDK-8201785
>
> Webrev:
> http://cr.openjdk.java.net/~shade/8201785/webrev.01/
>
> Found this when while rebasing Epsilon to the recent jdk/jdk -- Epsilon defers to ModRefBS for
> interpreter barriers. It makes more sense to me for ModRefBS to provide the default implementations
> for all platforms, rather than it being abstract on some platforms. It follows what AArch64 and PPC
> are doing right now, and aligns better with arraycopy barriers already implemented by default in
> ModRefBS.
>
> Testing: x86_64 build, Epsilon tests, jdk-submit (running)
>
> Thanks,
> -Aleksey
>
From shade at redhat.com Wed Apr 18 10:22:23 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 18 Apr 2018 12:22:23 +0200
Subject: RFR 8201785: Provide default implementations for
ModRefBarrierSetAssembler::oop_store_at for all platforms
In-Reply-To: <5AD71A16.3060004@oracle.com>
References: <0e56d51f-7270-b894-9967-e44940b0cb4c@redhat.com>
<5AD71A16.3060004@oracle.com>
Message-ID: <e64732c3-8285-e0e6-5f9f-5ae30eb6f0f0@redhat.com>
On 04/18/2018 12:12 PM, Erik ?sterlund wrote:
> Why are you instantiating a ModRefBarrierSetAssembler as opposed to a BarrierSetAssembler? ModRef is
> meant as an abstract class for GCs that have a notion of write barriers. I don't believe your GC has
> such a notion.
To answer the Epsilon-related question: in order to reduce code duplication, current implementation
tries to delegate to existing barrier sets, where possible. ModRefBSAssembler is nearly there for
interpreter GC barriers, because even though its subclasses implement write-barrier-bearing BS, its
default implementation may do nothing for write-barriers -- and it does nothing for AArch64 and PPC,
which is convenient.
This might not be a good way to implement EpsilonBS in the end -- it should probably just go for
BarrierSetAssembler::store_at -- but see how it exposes implementation desyncs today. I think
Epsilon-related questions are not so relevant in the context of this change, which syncs
arch-specific implementations.
At very least, it makes ModRefBSAssembler consistently concrete in all arches. The alternative may
be the reverse: make ModRefBSAssembler consistently abstract in all arches, but purging AArch64 and
PPC default implementations.
Thanks,
-Aleksey
From christian.tornqvist at oracle.com Wed Apr 18 10:22:49 2018
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Wed, 18 Apr 2018 06:22:49 -0400
Subject: jdk/jdk OPEN for HotSpot pushes (Re: Merging jdk/hs with jdk/jdk)
In-Reply-To: <5564dce5-914c-0371-5146-003ca96a1340@physik.fu-berlin.de>
References: <8819CAD3-AF29-463E-8A76-14440CF37D2B@oracle.com>
<952F85EF-BB76-4645-AC05-F843DB83881B@oracle.com>
<EEA812F6-693C-41D9-87B4-5F66B478F9DB@oracle.com>
<585020bc-6f0f-5dd0-19e7-4ade558557d3@physik.fu-berlin.de>
<F3D99DFF-9479-4A93-A9CC-9E0BC02D078D@oracle.com>
<5564dce5-914c-0371-5146-003ca96a1340@physik.fu-berlin.de>
Message-ID: <C8884BF7-98D3-46D5-B5A3-11F2F76A6C09@oracle.com>
Hi Adrian,
We did some maintenance on the jdk-submit repo as part of the preparation for merging jdk/hs and jdk/jdk, unfortunately everything wasn?t enabled again. I?ve fixed the problem and I?ve triggered a build & test for your branch, you should have the results in a few hours.
Sorry for the inconvenience!
Thanks,
Christian
> On Apr 18, 2018, at 5:14 52AM, John Paul Adrian Glaubitz <glaubitz at physik.fu-berlin.de> wrote:
>
> On 04/18/2018 09:46 AM, jesper.wilhelmsson at oracle.com wrote:
>> I don't see any job with your username (glaubitz) and the bug id 8201616. The most recent is from six days ago, 8201480.
>> Most likely something went wrong when starting the job. I do see your push in the submit repo. Try to push some trivial change to the same branch, that should trigger a new test job.
>
> Ok, I just pushed another NOP change by adding a comment.
>
> Let's see if that works.
>
> Adrian
>
> --
> .''`. John Paul Adrian Glaubitz
> : :' : Debian Developer - glaubitz at debian.org
> `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From erik.osterlund at oracle.com Wed Apr 18 10:30:10 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Wed, 18 Apr 2018 12:30:10 +0200
Subject: RFR 8201785: Provide default implementations for
ModRefBarrierSetAssembler::oop_store_at for all platforms
In-Reply-To: <e64732c3-8285-e0e6-5f9f-5ae30eb6f0f0@redhat.com>
References: <0e56d51f-7270-b894-9967-e44940b0cb4c@redhat.com>
<5AD71A16.3060004@oracle.com>
<e64732c3-8285-e0e6-5f9f-5ae30eb6f0f0@redhat.com>
Message-ID: <5AD71E32.3060605@oracle.com>
Hi Aleksey,
On 2018-04-18 12:22, Aleksey Shipilev wrote:
> On 04/18/2018 12:12 PM, Erik ?sterlund wrote:
>> Why are you instantiating a ModRefBarrierSetAssembler as opposed to a BarrierSetAssembler? ModRef is
>> meant as an abstract class for GCs that have a notion of write barriers. I don't believe your GC has
>> such a notion.
> To answer the Epsilon-related question: in order to reduce code duplication, current implementation
> tries to delegate to existing barrier sets, where possible. ModRefBSAssembler is nearly there for
> interpreter GC barriers, because even though its subclasses implement write-barrier-bearing BS, its
> default implementation may do nothing for write-barriers -- and it does nothing for AArch64 and PPC,
> which is convenient.
The same should go for BarrierSetAssembler - you should be able to just
instantiate a BarrierSetAssembler if you don't want to make your own
assembler that inherits from BarrierSetAssembler.
> This might not be a good way to implement EpsilonBS in the end -- it should probably just go for
> BarrierSetAssembler::store_at -- but see how it exposes implementation desyncs today. I think
> Epsilon-related questions are not so relevant in the context of this change, which syncs
> arch-specific implementations.
>
> At very least, it makes ModRefBSAssembler consistently concrete in all arches. The alternative may
> be the reverse: make ModRefBSAssembler consistently abstract in all arches, but purging AArch64 and
> PPC default implementations.
I think ModRefBarrierSetAssembler should be abstract on all
architectures. It is really only a helper for GCs with a notion of write
barriers.
Thanks,
/Erik
> Thanks,
> -Aleksey
>
>
From shade at redhat.com Wed Apr 18 10:36:00 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 18 Apr 2018 12:36:00 +0200
Subject: RFR 8201785: Provide default implementations for
ModRefBarrierSetAssembler::oop_store_at for all platforms
In-Reply-To: <5AD71E32.3060605@oracle.com>
References: <0e56d51f-7270-b894-9967-e44940b0cb4c@redhat.com>
<5AD71A16.3060004@oracle.com>
<e64732c3-8285-e0e6-5f9f-5ae30eb6f0f0@redhat.com>
<5AD71E32.3060605@oracle.com>
Message-ID: <3257141c-f4b2-bcca-55b8-fd2c17b9769b@redhat.com>
On 04/18/2018 12:30 PM, Erik ?sterlund wrote:
> On 2018-04-18 12:22, Aleksey Shipilev wrote:
>> On 04/18/2018 12:12 PM, Erik ?sterlund wrote:
>>> Why are you instantiating a ModRefBarrierSetAssembler as opposed to a BarrierSetAssembler? ModRef is
>>> meant as an abstract class for GCs that have a notion of write barriers. I don't believe your GC has
>>> such a notion.
>> To answer the Epsilon-related question: in order to reduce code duplication, current implementation
>> tries to delegate to existing barrier sets, where possible. ModRefBSAssembler is nearly there for
>> interpreter GC barriers, because even though its subclasses implement write-barrier-bearing BS, its
>> default implementation may do nothing for write-barriers -- and it does nothing for AArch64 and PPC,
>> which is convenient.
>
> The same should go for BarrierSetAssembler - you should be able to just instantiate a
> BarrierSetAssembler if you don't want to make your own assembler that inherits from
> BarrierSetAssembler.
Oh! I overlooked that BarrierSetAssembler is not abstract! Thanks, it seems to work :)
>> At very least, it makes ModRefBSAssembler consistently concrete in all arches. The alternative may
>> be the reverse: make ModRefBSAssembler consistently abstract in all arches, but purging AArch64 and
>> PPC default implementations.
>
> I think ModRefBarrierSetAssembler should be abstract on all architectures. It is really only a
> helper for GCs with a notion of write barriers.
Okay, let me withdraw this patch, and propose the reverse: make it abstract all the way.
Thanks,
-Aleksey
From erik.osterlund at oracle.com Wed Apr 18 10:40:08 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Wed, 18 Apr 2018 12:40:08 +0200
Subject: RFR 8201785: Provide default implementations for
ModRefBarrierSetAssembler::oop_store_at for all platforms
In-Reply-To: <3257141c-f4b2-bcca-55b8-fd2c17b9769b@redhat.com>
References: <0e56d51f-7270-b894-9967-e44940b0cb4c@redhat.com>
<5AD71A16.3060004@oracle.com>
<e64732c3-8285-e0e6-5f9f-5ae30eb6f0f0@redhat.com>
<5AD71E32.3060605@oracle.com>
<3257141c-f4b2-bcca-55b8-fd2c17b9769b@redhat.com>
Message-ID: <5AD72088.6010508@oracle.com>
Hi Aleksey,
On 2018-04-18 12:36, Aleksey Shipilev wrote:
> On 04/18/2018 12:30 PM, Erik ?sterlund wrote:
>> On 2018-04-18 12:22, Aleksey Shipilev wrote:
>>> On 04/18/2018 12:12 PM, Erik ?sterlund wrote:
>>>> Why are you instantiating a ModRefBarrierSetAssembler as opposed to a BarrierSetAssembler? ModRef is
>>>> meant as an abstract class for GCs that have a notion of write barriers. I don't believe your GC has
>>>> such a notion.
>>> To answer the Epsilon-related question: in order to reduce code duplication, current implementation
>>> tries to delegate to existing barrier sets, where possible. ModRefBSAssembler is nearly there for
>>> interpreter GC barriers, because even though its subclasses implement write-barrier-bearing BS, its
>>> default implementation may do nothing for write-barriers -- and it does nothing for AArch64 and PPC,
>>> which is convenient.
>> The same should go for BarrierSetAssembler - you should be able to just instantiate a
>> BarrierSetAssembler if you don't want to make your own assembler that inherits from
>> BarrierSetAssembler.
> Oh! I overlooked that BarrierSetAssembler is not abstract! Thanks, it seems to work :)
>
>>> At very least, it makes ModRefBSAssembler consistently concrete in all arches. The alternative may
>>> be the reverse: make ModRefBSAssembler consistently abstract in all arches, but purging AArch64 and
>>> PPC default implementations.
>> I think ModRefBarrierSetAssembler should be abstract on all architectures. It is really only a
>> helper for GCs with a notion of write barriers.
> Okay, let me withdraw this patch, and propose the reverse: make it abstract all the way.
Thanks, that would be great. :)
/Erik
> Thanks,
> -Aleksey
>
>
From per.liden at oracle.com Wed Apr 18 10:43:33 2018
From: per.liden at oracle.com (Per Liden)
Date: Wed, 18 Apr 2018 12:43:33 +0200
Subject: RFR: 8201647: Make initial clearing of CHeapBitMap optional
In-Reply-To: <CFCCD73F-79CD-4DB5-A093-FCEC1403B2B2@oracle.com>
References: <336cf9d0-0c71-0a01-8c4f-51103c39acc3@oracle.com>
<CFCCD73F-79CD-4DB5-A093-FCEC1403B2B2@oracle.com>
Message-ID: <6f22f0e9-8a33-14e6-8673-142d6848e31b@oracle.com>
Thanks Kim!
/Per
On 04/17/2018 02:57 PM, Kim Barrett wrote:
>> On Apr 17, 2018, at 8:38 AM, Per Liden <per.liden at oracle.com> wrote:
>>
>> CHeapBitMap objects will by default clear the underlying bitmap during construction. In ZGC we don't want mark bitmaps to be cleared on construction, since we instead do this lazily during concurrent marking.
>>
>> This patch adds a "bool clear = true" argument to CHeapBitMap's constructor to be able to opt-out of this behavior.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201647
>> Webrev: http://cr.openjdk.java.net/~pliden/8201647/webrev.0
>>
>> /Per
>
> Looks good.
>
From erik.osterlund at oracle.com Wed Apr 18 11:14:48 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Wed, 18 Apr 2018 13:14:48 +0200
Subject: RFR: 8200235: Generalize jniFastGetField jobject/jweak resolve
Message-ID: <5AD728A8.9050606@oracle.com>
Hi,
The fantastic jniFastGetField optimization that we all know and love,
resolves jobjects/jweaks in native, possibly concurrent with GC safepoints.
Currently it is assumed that it is "safe" to just unmask the potential
jweak tag, and read the jobject/jweak oop and then speculatively read
the integer value of that oop (resorting to the signal handler as plan B
if the heap was concurrently unmapped in the safepoint).
This happens to be safe with existing collectors, but ties very strongly
to how these oops are processed (as it is normally strictly forbidden by
mutators to resolve jobject/jweak in safepoints, except of course when
using it to quickly read integers via JNI).
My proposed solution is to add a try_resolve_jobject_in_native()
function in the BarrierSetAssembler class, and allow it try to perform
this resolution, but also give it an option to opt out should it find
that this jobject/jweak really has to go through the proper VM
transition. This allows a GC where this is not in general safe (but
possibly mostly safe depending on GC-specific details such as pointer
colouring) to override this special in-native jobject/jweak resolution.
That should make everyone happy I hope.
I provided changes for x86_64, SPARC and AArch64. PPC and S390 do not
use jniFastGetField, and there are no current plans that I am aware of
to introduce support for any new GC any time soon to the non-AArch64 arm
port.
Webrev:
http://cr.openjdk.java.net/~eosterlund/8200235/webrev.00/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8200235
Thanks,
/Erik
From shade at redhat.com Wed Apr 18 11:50:48 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 18 Apr 2018 13:50:48 +0200
Subject: RFR 8201799: Build failures after JDK-8195099 (Concurrent
safe-memory-reclamation mechanism)
Message-ID: <150dc231-d81e-58da-fa46-fd2397bb7ca2@redhat.com>
Bug:
https://bugs.openjdk.java.net/browse/JDK-8201799
Fix:
diff -r bfba4712d4ff src/hotspot/share/utilities/globalCounter.inline.hpp
--- a/src/hotspot/share/utilities/globalCounter.inline.hpp Wed Apr 18 11:36:48 2018 +0200
+++ b/src/hotspot/share/utilities/globalCounter.inline.hpp Wed Apr 18 13:50:34 2018 +0200
@@ -27,6 +27,7 @@
#include "runtime/orderAccess.inline.hpp"
#include "runtime/thread.hpp"
+#include "runtime/thread.inline.hpp"
#include "utilities/globalCounter.hpp"
inline void GlobalCounter::critical_section_begin(Thread *thread) {
Testing: failing aarch64 build
Thanks,
-Aleksey
From shade at redhat.com Wed Apr 18 11:57:23 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 18 Apr 2018 13:57:23 +0200
Subject: RFR 8201785: Make ModRefBarrierSetAssembler abstract on all platforms
Message-ID: <1148c233-dcaa-9de8-ecce-f416a0aa7634@redhat.com>
RFE:
https://bugs.openjdk.java.net/browse/JDK-8201785
Webrev:
http://cr.openjdk.java.net/~shade/8201785/webrev.02/
Found this when while rebasing Epsilon to the recent jdk/jdk. ModRefBSAssembler is abstract on some
platforms (x86, sparc), but not on the others (aarch64, ppc). I think this allows missing the
required overrides of oop_store_at in ModRefBSAssembler subclasses, which should be caught
mechanically. (Epsilon used to defer to ModRefBSAssembler, and it was successfully instantiated!)
PPC folks, would you like to give it a spin on your platforms?
Testing: x86_64 and aarch64 non-PCH builds, Epsilon tests
Thanks,
-Aleksey
From stefan.karlsson at oracle.com Wed Apr 18 12:10:16 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 18 Apr 2018 14:10:16 +0200
Subject: RFR (M) 8200555: OopHandle should use Access API
In-Reply-To: <f176b0d9-6152-45d2-ace9-1effb6b5fa28@oracle.com>
References: <f176b0d9-6152-45d2-ace9-1effb6b5fa28@oracle.com>
Message-ID: <6ae89bb3-efbc-0bf8-9de4-5bc21040ab2e@oracle.com>
Hi Coleen,
The Runtime part looks good to me.
StefanK
On 2018-04-13 16:56, coleen.phillimore at oracle.com wrote:
> Summary: Add RootAccess<> to OopHandle.resolve() in runtime and
> interpreter code.? Add comments for compiler code for later.
>
> For the current GCs this code does not generate additional code. Also,
> the compiler Access API code is TBD.?? Since oopHandle.hpp erroneously
> included orderAccess.hpp and atomic.hpp, some include file fixing is
> also in this change.
>
> Tested with mach5 tier1,tier2 on all Oracle platforms.? Also tested
> compilation on linux-aarch64.? The other non-Oracle platforms weren't
> changed because they'll never need this.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8200555.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8200555
>
> Thanks,
> Coleen
From coleen.phillimore at oracle.com Wed Apr 18 12:15:33 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 18 Apr 2018 08:15:33 -0400
Subject: RFR (M) 8200555: OopHandle should use Access API
In-Reply-To: <6ae89bb3-efbc-0bf8-9de4-5bc21040ab2e@oracle.com>
References: <f176b0d9-6152-45d2-ace9-1effb6b5fa28@oracle.com>
<6ae89bb3-efbc-0bf8-9de4-5bc21040ab2e@oracle.com>
Message-ID: <ec6ab7e8-b4f9-dbc5-fc86-7108bc555c91@oracle.com>
Thanks Stefan!
Coleen
On 4/18/18 8:10 AM, Stefan Karlsson wrote:
> Hi Coleen,
>
> The Runtime part looks good to me.
>
> StefanK
>
> On 2018-04-13 16:56, coleen.phillimore at oracle.com wrote:
>> Summary: Add RootAccess<> to OopHandle.resolve() in runtime and
>> interpreter code.? Add comments for compiler code for later.
>>
>> For the current GCs this code does not generate additional code.
>> Also, the compiler Access API code is TBD.?? Since oopHandle.hpp
>> erroneously included orderAccess.hpp and atomic.hpp, some include
>> file fixing is also in this change.
>>
>> Tested with mach5 tier1,tier2 on all Oracle platforms.? Also tested
>> compilation on linux-aarch64.? The other non-Oracle platforms weren't
>> changed because they'll never need this.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8200555.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8200555
>>
>> Thanks,
>> Coleen
From coleen.phillimore at oracle.com Wed Apr 18 12:17:50 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 18 Apr 2018 08:17:50 -0400
Subject: RFR (M) 8201556: Disallow reading oops in ClassLoaderData if
unloading
In-Reply-To: <cfe9f9d1-ed56-c8cd-ff0b-3ad8dd865479@redhat.com>
References: <c22b8e6c-69e4-34bf-11d2-cc75c30204b8@oracle.com>
<cfe9f9d1-ed56-c8cd-ff0b-3ad8dd865479@redhat.com>
Message-ID: <1e38f611-5e6f-37bc-d857-8062bb048e32@oracle.com>
On 4/18/18 4:42 AM, Andrew Dinn wrote:
> Hi Coleen,
>
> On 17/04/18 17:02, coleen.phillimore at oracle.com wrote:
>> Summary: Move class_loader oop to an OopHandle, and assert that holder
>> is alive when getting class_loader.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8201556.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8201556
>>
>> Tested with mach5 tiers 1-7.
> I have just been browsing the code in this area so thought I should
> offer a 2nd review. The changes all look good to me (subtracting the
> typo and legacy closure Kim mentioned).
Thank you Andrew.? I'm glad you're looking at these changes!
Coleen
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
From erik.osterlund at oracle.com Wed Apr 18 12:26:29 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Wed, 18 Apr 2018 14:26:29 +0200
Subject: RFR 8201785: Make ModRefBarrierSetAssembler abstract on all
platforms
In-Reply-To: <1148c233-dcaa-9de8-ecce-f416a0aa7634@redhat.com>
References: <1148c233-dcaa-9de8-ecce-f416a0aa7634@redhat.com>
Message-ID: <5AD73975.7060708@oracle.com>
Hi Aleksey,
This looks good to me. Thanks for cleaning this up.
/Erik
On 2018-04-18 13:57, Aleksey Shipilev wrote:
> RFE:
> https://bugs.openjdk.java.net/browse/JDK-8201785
>
> Webrev:
> http://cr.openjdk.java.net/~shade/8201785/webrev.02/
>
> Found this when while rebasing Epsilon to the recent jdk/jdk. ModRefBSAssembler is abstract on some
> platforms (x86, sparc), but not on the others (aarch64, ppc). I think this allows missing the
> required overrides of oop_store_at in ModRefBSAssembler subclasses, which should be caught
> mechanically. (Epsilon used to defer to ModRefBSAssembler, and it was successfully instantiated!)
>
> PPC folks, would you like to give it a spin on your platforms?
>
> Testing: x86_64 and aarch64 non-PCH builds, Epsilon tests
>
> Thanks,
> -Aleksey
>
From david.holmes at oracle.com Wed Apr 18 12:27:27 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Apr 2018 22:27:27 +1000
Subject: RFR 8201799: Build failures after JDK-8195099 (Concurrent
safe-memory-reclamation mechanism)
In-Reply-To: <150dc231-d81e-58da-fa46-fd2397bb7ca2@redhat.com>
References: <150dc231-d81e-58da-fa46-fd2397bb7ca2@redhat.com>
Message-ID: <ee7c6a6c-7697-ca4b-dd3d-484ca24aeabd@oracle.com>
Hi Aleksey,
On 18/04/2018 9:50 PM, Aleksey Shipilev wrote:
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8201799
>
> Fix:
>
> diff -r bfba4712d4ff src/hotspot/share/utilities/globalCounter.inline.hpp
> --- a/src/hotspot/share/utilities/globalCounter.inline.hpp Wed Apr 18 11:36:48 2018 +0200
> +++ b/src/hotspot/share/utilities/globalCounter.inline.hpp Wed Apr 18 13:50:34 2018 +0200
> @@ -27,6 +27,7 @@
>
> #include "runtime/orderAccess.inline.hpp"
> #include "runtime/thread.hpp"
The above line can be deleted now.
> +#include "runtime/thread.inline.hpp"
Fix is good.
Thanks,
David
> #include "utilities/globalCounter.hpp"
>
> inline void GlobalCounter::critical_section_begin(Thread *thread) {
>
> Testing: failing aarch64 build
>
> Thanks,
> -Aleksey
>
From david.holmes at oracle.com Wed Apr 18 12:30:13 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Apr 2018 22:30:13 +1000
Subject: RFR: 8200235: Generalize jniFastGetField jobject/jweak resolve
In-Reply-To: <5AD728A8.9050606@oracle.com>
References: <5AD728A8.9050606@oracle.com>
Message-ID: <4376d839-eae6-28e9-6fab-d357c6bcd7e0@oracle.com>
Hi Erik,
How does this affect performance? That's the only reason we have these
'fast' functions.
Thanks,
David
On 18/04/2018 9:14 PM, Erik ?sterlund wrote:
> Hi,
>
> The fantastic jniFastGetField optimization that we all know and love,
> resolves jobjects/jweaks in native, possibly concurrent with GC safepoints.
> Currently it is assumed that it is "safe" to just unmask the potential
> jweak tag, and read the jobject/jweak oop and then speculatively read
> the integer value of that oop (resorting to the signal handler as plan B
> if the heap was concurrently unmapped in the safepoint).
>
> This happens to be safe with existing collectors, but ties very strongly
> to how these oops are processed (as it is normally strictly forbidden by
> mutators to resolve jobject/jweak in safepoints, except of course when
> using it to quickly read integers via JNI).
>
> My proposed solution is to add a try_resolve_jobject_in_native()
> function in the BarrierSetAssembler class, and allow it try to perform
> this resolution, but also give it an option to opt out should it find
> that this jobject/jweak really has to go through the proper VM
> transition. This allows a GC where this is not in general safe (but
> possibly mostly safe depending on GC-specific details such as pointer
> colouring) to override this special in-native jobject/jweak resolution.
> That should make everyone happy I hope.
>
> I provided changes for x86_64, SPARC and AArch64. PPC and S390 do not
> use jniFastGetField, and there are no current plans that I am aware of
> to introduce support for any new GC any time soon to the non-AArch64 arm
> port.
>
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8200235/webrev.00/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8200235
>
> Thanks,
> /Erik
From david.holmes at oracle.com Wed Apr 18 12:38:44 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Apr 2018 22:38:44 +1000
Subject: RFR: 8200235: Generalize jniFastGetField jobject/jweak resolve
In-Reply-To: <4376d839-eae6-28e9-6fab-d357c6bcd7e0@oracle.com>
References: <5AD728A8.9050606@oracle.com>
<4376d839-eae6-28e9-6fab-d357c6bcd7e0@oracle.com>
Message-ID: <b50e52c4-9ec4-9118-9426-2ae13ea09891@oracle.com>
I should have looked closer first ...
On 18/04/2018 10:30 PM, David Holmes wrote:
> Hi Erik,
>
> How does this affect performance? That's the only reason we have these
> 'fast' functions.
Okay at the moment there's no affect as you've just added a potential
for change in a future GC that needs it.
For the ports not addressed they continue to use whatever "hard-wired"
approach they use.
David
> Thanks,
> David
>
> On 18/04/2018 9:14 PM, Erik ?sterlund wrote:
>> Hi,
>>
>> The fantastic jniFastGetField optimization that we all know and love,
>> resolves jobjects/jweaks in native, possibly concurrent with GC
>> safepoints.
>> Currently it is assumed that it is "safe" to just unmask the potential
>> jweak tag, and read the jobject/jweak oop and then speculatively read
>> the integer value of that oop (resorting to the signal handler as plan
>> B if the heap was concurrently unmapped in the safepoint).
>>
>> This happens to be safe with existing collectors, but ties very
>> strongly to how these oops are processed (as it is normally strictly
>> forbidden by mutators to resolve jobject/jweak in safepoints, except
>> of course when using it to quickly read integers via JNI).
>>
>> My proposed solution is to add a try_resolve_jobject_in_native()
>> function in the BarrierSetAssembler class, and allow it try to perform
>> this resolution, but also give it an option to opt out should it find
>> that this jobject/jweak really has to go through the proper VM
>> transition. This allows a GC where this is not in general safe (but
>> possibly mostly safe depending on GC-specific details such as pointer
>> colouring) to override this special in-native jobject/jweak
>> resolution. That should make everyone happy I hope.
>>
>> I provided changes for x86_64, SPARC and AArch64. PPC and S390 do not
>> use jniFastGetField, and there are no current plans that I am aware of
>> to introduce support for any new GC any time soon to the non-AArch64
>> arm port.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8200235/webrev.00/
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8200235
>>
>> Thanks,
>> /Erik
From erik.osterlund at oracle.com Wed Apr 18 12:41:56 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Wed, 18 Apr 2018 14:41:56 +0200
Subject: RFR: 8200235: Generalize jniFastGetField jobject/jweak resolve
In-Reply-To: <4376d839-eae6-28e9-6fab-d357c6bcd7e0@oracle.com>
References: <5AD728A8.9050606@oracle.com>
<4376d839-eae6-28e9-6fab-d357c6bcd7e0@oracle.com>
Message-ID: <5AD73D14.2060601@oracle.com>
Hi David,
I like the way you think. I thought the same thing. My original wish was
to get rid of this optimization, hoping that it is no longer necessary.
So I ran a bunch of benchmarks, hoping that it would show it made no
difference. To my dismay, I found that on x86 linux, SPECjvm2008
regressed ~5% without jniFastGetField. I don't know why and did not look
further into it. I thought that if there is one benchmark where this
makes a large ish difference, there might be real applications that
regress as well. And to dodge that debate, I decided to go down the
route of making it possible for GCs to partially opt out of this madness
when it is too problematic to maintain the interactions with
jobject/jweak processing in safepoints. But the existing GCs can do the
same thing and therefore not regress in performance.
Thanks,
/Erik
On 2018-04-18 14:30, David Holmes wrote:
> Hi Erik,
>
> How does this affect performance? That's the only reason we have these
> 'fast' functions.
>
> Thanks,
> David
>
> On 18/04/2018 9:14 PM, Erik ?sterlund wrote:
>> Hi,
>>
>> The fantastic jniFastGetField optimization that we all know and love,
>> resolves jobjects/jweaks in native, possibly concurrent with GC
>> safepoints.
>> Currently it is assumed that it is "safe" to just unmask the
>> potential jweak tag, and read the jobject/jweak oop and then
>> speculatively read the integer value of that oop (resorting to the
>> signal handler as plan B if the heap was concurrently unmapped in the
>> safepoint).
>>
>> This happens to be safe with existing collectors, but ties very
>> strongly to how these oops are processed (as it is normally strictly
>> forbidden by mutators to resolve jobject/jweak in safepoints, except
>> of course when using it to quickly read integers via JNI).
>>
>> My proposed solution is to add a try_resolve_jobject_in_native()
>> function in the BarrierSetAssembler class, and allow it try to
>> perform this resolution, but also give it an option to opt out should
>> it find that this jobject/jweak really has to go through the proper
>> VM transition. This allows a GC where this is not in general safe
>> (but possibly mostly safe depending on GC-specific details such as
>> pointer colouring) to override this special in-native jobject/jweak
>> resolution. That should make everyone happy I hope.
>>
>> I provided changes for x86_64, SPARC and AArch64. PPC and S390 do not
>> use jniFastGetField, and there are no current plans that I am aware
>> of to introduce support for any new GC any time soon to the
>> non-AArch64 arm port.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8200235/webrev.00/
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8200235
>>
>> Thanks,
>> /Erik
From thomas.schatzl at oracle.com Wed Apr 18 12:39:46 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 18 Apr 2018 14:39:46 +0200
Subject: RFR 8201799: Build failures after JDK-8195099 (Concurrent
safe-memory-reclamation mechanism)
In-Reply-To: <150dc231-d81e-58da-fa46-fd2397bb7ca2@redhat.com>
References: <150dc231-d81e-58da-fa46-fd2397bb7ca2@redhat.com>
Message-ID: <1524055186.6872.7.camel@oracle.com>
Hi,
On Wed, 2018-04-18 at 13:50 +0200, Aleksey Shipilev wrote:
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8201799
>
> Fix:
>
> diff -r bfba4712d4ff
> src/hotspot/share/utilities/globalCounter.inline.hpp
> --- a/src/hotspot/share/utilities/globalCounter.inline.hpp Wed
> Apr 18 11:36:48 2018 +0200
> +++ b/src/hotspot/share/utilities/globalCounter.inline.hpp Wed
> Apr 18 13:50:34 2018 +0200
> @@ -27,6 +27,7 @@
>
> #include "runtime/orderAccess.inline.hpp"
> #include "runtime/thread.hpp"
Agree with David that this line should be removed before pushing.
> +#include "runtime/thread.inline.hpp"
> #include "utilities/globalCounter.hpp"
>
> inline void GlobalCounter::critical_section_begin(Thread *thread) {
>
> Testing: failing aarch64 build
Seems good to go.
Thomas
From erik.osterlund at oracle.com Wed Apr 18 12:42:58 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Wed, 18 Apr 2018 14:42:58 +0200
Subject: RFR: 8200235: Generalize jniFastGetField jobject/jweak resolve
In-Reply-To: <b50e52c4-9ec4-9118-9426-2ae13ea09891@oracle.com>
References: <5AD728A8.9050606@oracle.com>
<4376d839-eae6-28e9-6fab-d357c6bcd7e0@oracle.com>
<b50e52c4-9ec4-9118-9426-2ae13ea09891@oracle.com>
Message-ID: <5AD73D52.3080705@oracle.com>
Hi David,
On 2018-04-18 14:38, David Holmes wrote:
> I should have looked closer first ...
>
> On 18/04/2018 10:30 PM, David Holmes wrote:
>> Hi Erik,
>>
>> How does this affect performance? That's the only reason we have
>> these 'fast' functions.
>
> Okay at the moment there's no affect as you've just added a potential
> for change in a future GC that needs it.
Yes, exactly.
> For the ports not addressed they continue to use whatever "hard-wired"
> approach they use.
Yes.
/Erik
> David
>
>> Thanks,
>> David
>>
>> On 18/04/2018 9:14 PM, Erik ?sterlund wrote:
>>> Hi,
>>>
>>> The fantastic jniFastGetField optimization that we all know and
>>> love, resolves jobjects/jweaks in native, possibly concurrent with
>>> GC safepoints.
>>> Currently it is assumed that it is "safe" to just unmask the
>>> potential jweak tag, and read the jobject/jweak oop and then
>>> speculatively read the integer value of that oop (resorting to the
>>> signal handler as plan B if the heap was concurrently unmapped in
>>> the safepoint).
>>>
>>> This happens to be safe with existing collectors, but ties very
>>> strongly to how these oops are processed (as it is normally strictly
>>> forbidden by mutators to resolve jobject/jweak in safepoints, except
>>> of course when using it to quickly read integers via JNI).
>>>
>>> My proposed solution is to add a try_resolve_jobject_in_native()
>>> function in the BarrierSetAssembler class, and allow it try to
>>> perform this resolution, but also give it an option to opt out
>>> should it find that this jobject/jweak really has to go through the
>>> proper VM transition. This allows a GC where this is not in general
>>> safe (but possibly mostly safe depending on GC-specific details such
>>> as pointer colouring) to override this special in-native
>>> jobject/jweak resolution. That should make everyone happy I hope.
>>>
>>> I provided changes for x86_64, SPARC and AArch64. PPC and S390 do
>>> not use jniFastGetField, and there are no current plans that I am
>>> aware of to introduce support for any new GC any time soon to the
>>> non-AArch64 arm port.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~eosterlund/8200235/webrev.00/
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8200235
>>>
>>> Thanks,
>>> /Erik
From erik.osterlund at oracle.com Wed Apr 18 12:47:15 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Wed, 18 Apr 2018 14:47:15 +0200
Subject: RFR 8201799: Build failures after JDK-8195099 (Concurrent
safe-memory-reclamation mechanism)
In-Reply-To: <ee7c6a6c-7697-ca4b-dd3d-484ca24aeabd@oracle.com>
References: <150dc231-d81e-58da-fa46-fd2397bb7ca2@redhat.com>
<ee7c6a6c-7697-ca4b-dd3d-484ca24aeabd@oracle.com>
Message-ID: <5AD73E53.90904@oracle.com>
Hi,
Please also note that the Atomic::add used in write_synchronize assumes
bidirectional fencing (which is the contract provided by Atomic::add).
This is however not true for the PPC backend of Atomic::add - it has
acq_rel semantics instead. So this mechanism is currently not safe to
use on PPC.
From globalCounter.cpp:
61 // Atomic::add must provide fence since we have storeload
dependency.
62 volatile uintx gbl_cnt = Atomic::add((uintx)COUNTER_INCREMENT,
&_global_counter._counter);
Might want to have a look at the safe use of this mechanism on PPC as a
follow-up.
Thanks,
/Erik
On 2018-04-18 14:27, David Holmes wrote:
> Hi Aleksey,
>
> On 18/04/2018 9:50 PM, Aleksey Shipilev wrote:
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8201799
>>
>> Fix:
>>
>> diff -r bfba4712d4ff
>> src/hotspot/share/utilities/globalCounter.inline.hpp
>> --- a/src/hotspot/share/utilities/globalCounter.inline.hpp Wed Apr 18
>> 11:36:48 2018 +0200
>> +++ b/src/hotspot/share/utilities/globalCounter.inline.hpp Wed Apr 18
>> 13:50:34 2018 +0200
>> @@ -27,6 +27,7 @@
>>
>> #include "runtime/orderAccess.inline.hpp"
>> #include "runtime/thread.hpp"
>
> The above line can be deleted now.
>
>> +#include "runtime/thread.inline.hpp"
>
> Fix is good.
>
> Thanks,
> David
>
>> #include "utilities/globalCounter.hpp"
>>
>> inline void GlobalCounter::critical_section_begin(Thread *thread) {
>>
>> Testing: failing aarch64 build
>>
>> Thanks,
>> -Aleksey
>>
From shade at redhat.com Wed Apr 18 13:07:53 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 18 Apr 2018 15:07:53 +0200
Subject: RFR 8201799: Build failures after JDK-8195099 (Concurrent
safe-memory-reclamation mechanism)
In-Reply-To: <1524055186.6872.7.camel@oracle.com>
References: <150dc231-d81e-58da-fa46-fd2397bb7ca2@redhat.com>
<1524055186.6872.7.camel@oracle.com>
Message-ID: <9670dc77-9c31-e2b0-5b74-35466cd5b45e@redhat.com>
Thanks guys, I verified that removal of the include does not break aarch64 build, and pushed:
http://hg.openjdk.java.net/jdk/jdk/rev/0c2ceb50783e
-Aleksey
On 04/18/2018 02:39 PM, Thomas Schatzl wrote:
> Hi,
>
> On Wed, 2018-04-18 at 13:50 +0200, Aleksey Shipilev wrote:
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8201799
>>
>> Fix:
>>
>> diff -r bfba4712d4ff
>> src/hotspot/share/utilities/globalCounter.inline.hpp
>> --- a/src/hotspot/share/utilities/globalCounter.inline.hpp Wed
>> Apr 18 11:36:48 2018 +0200
>> +++ b/src/hotspot/share/utilities/globalCounter.inline.hpp Wed
>> Apr 18 13:50:34 2018 +0200
>> @@ -27,6 +27,7 @@
>>
>> #include "runtime/orderAccess.inline.hpp"
>> #include "runtime/thread.hpp"
>
> Agree with David that this line should be removed before pushing.
>
>> +#include "runtime/thread.inline.hpp"
>> #include "utilities/globalCounter.hpp"
>>
>> inline void GlobalCounter::critical_section_begin(Thread *thread) {
>>
>> Testing: failing aarch64 build
>
> Seems good to go.
>
> Thomas
>
From daniel.daugherty at oracle.com Wed Apr 18 13:11:31 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 18 Apr 2018 09:11:31 -0400
Subject: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
In-Reply-To: <43ae45216d3545518b274dd7246d7862@sap.com>
References: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
<CAA-vtUz48xUdXQzDEAuS2JDdnis7n2pAjfJ52dgFkhKskNoX9Q@mail.gmail.com>
<b65af851-d138-42b2-847a-fd6650a1767b@oracle.com>
<CAA-vtUz+cyza6GOnVN7p-9XJ-JYo_vBozMNh0K=7woUbV4mKzA@mail.gmail.com>
<b0fcb60f-ff76-9b98-871c-8692f4504442@oracle.com>
<43ae45216d3545518b274dd7246d7862@sap.com>
Message-ID: <4dcc535e-4906-05a8-0636-65191f8a8695@oracle.com>
On 4/18/18 3:58 AM, Langer, Christoph wrote:
> cc-ing hotspot-runtime-dev as Dan mentioned in the bug that it should rather be there.
The review conversation is fine in hotspot-dev at ...
I moved the bug to hotspot/runtime since that it had no subcat set
which means that the Runtime triage team will pick it up. I believe
the policy for the 'hotspot' category is that a subcat should be set.
> Hi Thomas, David,
>
> I think it could be cleaned up nicely by removing jio_print and jio_printf from jvm.cpp and doing all in ostream.cpp. At the one place where we would call jio_print after my patch, we can do the vfprintf hook check and then either write to the hook or do the raw write. And the other 2 places where jio_printf is employed, we can just call jio_vfprintf(defaultStream::output_stream()). I don't see any other users of jio_print and jio_printf in the jdk repo.
>
> Any objections to that (e.g. some Oracle closed coding that'd break)? Otherwise I'll prepare something...
$ grep -r jio_print closed
Showed nothing found.
Dan
>
> Best regards
> Christoph
>
>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Mittwoch, 18. April 2018 07:59
>> To: Thomas St?fe <thomas.stuefe at gmail.com>
>> Cc: Langer, Christoph <christoph.langer at sap.com>; hotspot-
>> dev at openjdk.java.net
>> Subject: Re: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
>>
>> On 18/04/2018 2:47 PM, Thomas St?fe wrote:
>>> Hi David,
>>>
>>> On Tue, Apr 17, 2018 at 11:17 PM, David Holmes
>> <david.holmes at oracle.com> wrote:
>>>> On 18/04/2018 1:48 AM, Thomas St?fe wrote:
>>>>> Hi Christoph,
>>>>>
>>>>> I do not understand jio_print() at all. I think it is just wrong: if a
>>>>> vfprintf hook is set, it prints to the defaultStream::output_stream(),
>>>>> otherwise to defaultStream::output_fd()? Isnt that the same? Compare
>>>>> this to jio_vfprintf(), which does the same logic, but correctly
>>>>> prints to the vfprintf hook if it is set.
>>>>
>>>> If there is a hook it does a formatted print: jio_print -> jio_fprintf ->
>>>> jio_vfprintf -> Arguments::vfprintf_hook()
>>>> else it does a raw write.
>>> Oh, I missed that.
>>>
>>> So, jio_print() checks if a vfprintf hook is installed.
>>>
>>> If it is, it calls jio_fprintf() with defaultStream::output_stream()
>>> as output file handle. It expects jio_fprintf() to call
>>> jio_vfprintf(), which should do the same check again and come to the
>>> same conclusion, then should disregard the output file handle handed
>>> down, instead call the vfprintf hook.
>>>
>>> (The output file handle is handed down as argument to the vfprintf
>>> hook; we had a discussion last year about it:
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
>> May/026794.html
>>> and we were not sure that made any sense.)
>> I had forgotten about that. :)
>>
>>> Not very clear coding. I think that can be improved by removing the
>>> vfprintf hook check from jio_print completely and make jio_vfprintf()
>>> be the only place where the vfprintf hook is handled.
>>>
>>> For example, this would be equivalent:
>>>
>>> void jio_print(const char* s) {
>>> jio_printf("%s", s);
>>> }
>>>
>>> or this:
>>>
>>> void jio_print(const char* s) {
>>> jio_fprintf(defaultStream::output_stream(), "%s", s);
>>> }
>> They aren't equivalent because the always do a formatted write, never
>> the raw write the currently exists. Does that matter? <shrug> no idea. I
>> don't have time to do any archaeology on this piece of code - sorry.
>>
>> Cheers,
>> David
>> -----
>>
>>> in which case we could also maybe also remove jio_printf(), because it
>>> is nowhere used inside the hotspot (though it is exported, but I find
>>> no reference to it being used anywhere in the OpenJDK).
>>>
>>>> Now why it does this is another matter. I have no idea. But I wouldn't
>>>> suggest changing it just because I don't know why it's done the way it is.
>>> I was reasonably sure I had understood the function, and that it was
>>> broken. In that case the proposal to change or remove it made sense.
>>>
>>> Thomas
>>>
>>>> David
>>>>
>>>>
>>>>
>>>>> I would propose to get rid of jio_print() altogether and replace the
>>>>> few callers of it (all in ostream.cpp) with this:
>>>>>
>>>>> jio_printf("%s", string);
>>>>>
>>>>> which does the same, but correctly.
>>>>>
>>>>> Best Regards, Thomas
>>>>>
>>>>> On Tue, Apr 17, 2018 at 4:48 PM, Langer, Christoph
>>>>> <christoph.langer at sap.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> can you please review a fix proposal for defaultStream::write(const
>> char*
>>>>>> s, size_t len).
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201649
>>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201649.0/
>>>>>>
>>>>>> I have seen occurrences of truncated buffers which don't need to
>> happen.
>>>>>> Thanks and best regards
>>>>>> Christoph
>>>>>>
From daniel.daugherty at oracle.com Wed Apr 18 13:29:08 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 18 Apr 2018 09:29:08 -0400
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
fast_path_end
In-Reply-To: <ba26dc77-a5ba-b490-2a03-cf4abd79ac3c@oracle.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
<3AAB892A-CE21-492C-ABA2-182EF9316F06@oracle.com>
<CAF9BGBz-=JqbaJ37B5G35u3Ziei53fjhf=JMaWFd06WeZUCLfQ@mail.gmail.com>
<CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
<3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>
<CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>
<5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
<CAF9BGBxEPXLTiyD-xG_ECyveyW0PXQL0+-z7jkw3Rv4QrkkszQ@mail.gmail.com>
<ec1a3e0e-ca9b-8668-b260-1fd3e612b7f7@oracle.com>
<CAF9BGBy-LBKCwJHQPdAQ65VRcSFBwVkk9dm8MLC_nrefE_JdEw@mail.gmail.com>
<e6528c19-5691-1215-1ac5-0349801b79b5@oracle.com>
<CAF9BGBwBgyOoJTfJU_YmqYJgSZ+1985yx_sSMJC4wNJELw1XDQ@mail.gmail.com>
<e63675e1-d693-cd25-75b2-32b593e266a2@oracle.com>
<CAF9BGBz3g4yXMjf9TxrqLdMbfaswoa3U13qYTEUtv-mZCDMd8Q@mail.gmail.com>
<735b3949-d9cd-3d37-ebb4-f59ee61f18ad@oracle.com>
<ba26dc77-a5ba-b490-2a03-cf4abd79ac3c@oracle.com>
Message-ID: <ff9474cd-6f07-446c-12b5-2dafbca35ce3@oracle.com>
Greetings,
The idea of splitting this change off from "8171119: Low-Overhead Heap
Profiling"
came up during the design review. It might have been me that suggested
the split
off or it was someone else. Sorry I don't remember.
In any case, the rename of "end" to "fast_path_end" is just a clarity
change to
the existing code and I think that change can easily stand on its own.
That is
particularly true if the accessors are renamed at the same time. I think
having
the accessor names match the field names is a pretty well known HotSpot rule
so I'm not sure why we're talking about not renaming the accessors...
Personally, I prefer "_fast_path_end" over "_current_end".
Dan
On 4/18/18 4:04 AM, Stefan Johansson wrote:
> Hi,
>
> On 2018-04-18 02:02, Vladimir Kozlov wrote:
>> ?> I think I like better not to add it. If no one is using it, there
>> should be
>> ?> no reason to add it? By not adding it, it also makes any future
>> wish to
>> ?> have it a nice indicator of: hey why do you want to see this? Same as
>> ?> hard_end btw which is not visible. Am I missing something?
>>
>> I say "may" ;)
>> You don't need new function if there is no use.
>>
>> ?>
>> ?> So to summarize, the current consensus:
>> ?>??? - _end can be renamed either to _current_end or _fast_path_end;
>> that is
>> ?> still up to a vote and choice :)
>>
>> Please, use _current_end. I was thinking about _sample_end but it
>> does not reflect double usage.
>
> I'm not sure if you have seen the discussion about naming on
> hotspot-gc-dev, but I and others think that _current_end doesn't
> describe the usage at all. Naming it _fast_path_end would clearly
> state what it is, _sample_end or something similar also crossed my
> mind but I think the code reads a lot better in the compiler with the
> name fast_path_end.
>
>>
>> ?>??? - the access method end() and tlab_end_offset() remain the same
>> to not
>> ?> modify JIT/interpreter codes
> I would find this very unfortunate, having accessors that don't match
> the members can easily lead to misunderstanding, especially if we have
> three different *_end members. Why do you think this is the best way
> forward?
>
> My first thought was also that it would be nice to avoid all the
> compiler changes, but then we would have to stick with _end being the
> sample/current/fast-path end and I'm not sure that is a better
> solution. I don't see the big problem with changing those accessors to
> what they really access and I think the compiler code reads good even
> after the change. For example:
> cmpptr(end, Address(thread, JavaThread::tlab_fast_path_end_offset()));
> jcc(Assembler::above, slow_case);
>
>> ?>
>> ?> If all agree to this, then the consequences are:
>> ?>??? - JDK-8201326 becomes useless
>> ?>??? - The work for JEP-331 becomes smaller in terms of file changes
>> ?>??? - I'll still be needing a decision on the renaming of the TLAB
>> _end field
>> ?> (current suggestions are _current_end and _fast_path_end).
>
> We'll see where we end up. If JDK-8201326 ends up being a separate
> change I think it should be pushed at the same time as the rest of the
> JEP changes. To me it only makes sense to have it in the code base if
> we also have the rest of the changes.
>
> Thanks,
> Stefan
>
>>
>> Sounds good to me.
>>
>> Thanks,
>> Vladimir
>>
>> On 4/17/18 4:51 PM, JC Beyler wrote:
>>> Hi Vladimir and Dean,
>>>
>>> @Dean: seems that Vladimir is in agreement with you for renaming
>>> just the
>>> field and not the method names so ack to your answer that came at
>>> the same
>>> time :)
>>>
>>>
>>>> Yes, from the beginning such changes should be discussed on common
>>>> hotspot-dev list since all
>>>> Hotspot's parts are affected.
>>>>
>>>
>>> Sorry, being new to the scene, most of the conversation had been
>>> going on
>>> in serviceability-dev.
>>>
>>>
>>>>
>>>> Graal specific question could be send to hotspot-compiler-dev list
>>>> with
>>>> [Graal] in subject.
>>>>
>>>> I looked on JEP's changes
>>>> http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.02/ to
>>>> understand how
>>>> it works.
>>>>
>>>> Few questions about proposed JEP changes so I can understand it.
>>>>
>>>> You introducing new TLAB end for sampling and adjust it so that
>>>> allocations in JITed code and
>>>> Interpreter it will trigger slow path allocation where you do
>>>> sampling.
>>>> Right?
>>>>
>>>
>>> Yes that is correct; if sampling is enabled of course. Btw, this is
>>> the current
>>> webrev <http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.15/>.
>>>
>>>
>>>>
>>>> Do all changes to _end, _actual_end and other TLAB fields happen
>>>> during
>>>> slow allocation?
>>>>
>>>
>>> Yes, to that effect, with Robbin's help, we finalized deprecating the
>>> FastTLabRefill via JDK-8194084
>>> <https://bugs.openjdk.java.net/browse/JDK-8194084>. Seems like I/we
>>> missed
>>> that Graal does this as well. I filed GRAAL-64
>>> <https://bugs.openjdk.java.net/browse/GRAAL-64> to not forget that
>>> Graal
>>> would need to get that fixed.
>>>
>>>
>>>
>>>>
>>>> I am concern about concurrent accesses to these fields from other
>>>> threads
>>>> if you have them (I don't
>>>> see).
>>>>
>>>
>>> Yes that is why we deprecated the FastTlabRefill. Other threads
>>> should not
>>> be changing the thread local data structure so I don't see an issue
>>> there.
>>> The major issue was that the fast paths could change the tlab
>>> without going
>>> via the slowpath.
>>>
>>> I had a fix to detect this issue but removed it once JDK-8194084 was
>>> done;
>>> Graal was missed in that work so that is why if sampling were
>>> enabled with
>>> Graal, there is a chance things would break currently. That will get
>>> fixed
>>> via GRAAL-64 <https://bugs.openjdk.java.net/browse/GRAAL-64> whether
>>> it is
>>> rendering the code also obsolete and going to the slowpath or
>>> whether it is
>>> adding my fix again to detect a fastpath TLAB reallocation happened.
>>>
>>>
>>>>
>>>> Renaming. I am fine with renaming if it helps to understand code
>>>> better. I
>>>> agree with proposed
>>>> changes to fields name:
>>>>
>>>> _current_end
>>>> _allocation_end
>>>>
>>>> But, as Dean, I would suggest to keep names of access functions.
>>>> This way
>>>> we can say that allocation
>>>> code in Interpreter and JITed code stay the same.
>>>>
>>>
>>> Sounds good to me, then in that case, this webrev will disappear, which
>>> also makes me happy, since it simplifies a lot of things (and
>>> reduces code
>>> change).
>>>
>>>
>>>>
>>>> You may need only new method to access _allocation_end in places which
>>>> look for real end of TLAB.
>>>>
>>>
>>> I think I like better not to add it. If no one is using it, there
>>> should be
>>> no reason to add it? By not adding it, it also makes any future wish to
>>> have it a nice indicator of: hey why do you want to see this? Same as
>>> hard_end btw which is not visible. Am I missing something?
>>>
>>> So to summarize, the current consensus:
>>> ?? - _end can be renamed either to _current_end or _fast_path_end;
>>> that is
>>> still up to a vote and choice :)
>>> ?? - the access method end() and tlab_end_offset() remain the same
>>> to not
>>> modify JIT/interpreter codes
>>>
>>> If all agree to this, then the consequences are:
>>> ?? - JDK-8201326 becomes useless
>>> ?? - The work for JEP-331 becomes smaller in terms of file changes
>>> ?? - I'll still be needing a decision on the renaming of the TLAB
>>> _end field
>>> (current suggestions are _current_end and _fast_path_end).
>>>
>>> Thanks for your help!
>>> Jc
>>>
>>>
>>>>
>>>> Regards,
>>>> Vladimir
>>>>
>>>> On 4/16/18 4:42 PM, JC Beyler wrote:
>>>>> Hi Dean,
>>>>>
>>>>> I think perhaps this is also an attempt to figure out the naming
>>>>> of all
>>>>> this because naming (or renaming like here) is often the start of big
>>>>> conversations :).
>>>>>
>>>>> Originally, in the JEP-331 work, I had left the _end field as is
>>>>> and, by
>>>>> doing so, this whole renaming webrev goes away. However, if we do
>>>>> that,
>>>>> then the TLAB code contains:
>>>>>
>>>>> _end: the fast path end, can be the allocation end or the
>>>>> to-be-sampled
>>>> end
>>>>> _allocation_end: the actual allocation end of the current TLAB
>>>>> hard_end: _allocation_end + reserved space
>>>>>
>>>>> With an early iteration of a webrev for JEP-331, a conversation
>>>>> occurred
>>>>> about whether or not that was clear or not and it was determined that
>>>> this
>>>>> renaming was more clear:
>>>>>
>>>>> _current_end: the fast path end
>>>>> _allocation_end: the actual allocation end of the current TLAB
>>>>> reserved_end: _allocation_end + reserved space
>>>>>
>>>>> Because I'm trying to reduce the footprint of files changed, I
>>>>> pulled out
>>>>> the renaming changes into this webrev. While talking about it with
>>>>> the GC
>>>>> team, the renaming suggested became:
>>>>>
>>>>> _fast_path_end: the fast path end
>>>>> _allocation_end: the actual allocation end of the current TLAB
>>>>> hard_end: _allocation_end + reserved space
>>>>>
>>>>> Now, to be honest, any renaming or no renaming is fine by me. I
>>>>> like not
>>>>> renaming the fields to not change the code of every backend and
>>>>> Graal; I
>>>>> also like the fast_path_end rename due to it making the backend
>>>>> code easy
>>>>> to read as mentioned in the GC mailing lis thread.
>>>>>
>>>>> So there are two questions really:
>>>>> ???? - Should we rename the _end field and thus provoke the
>>>>> changes in
>>>> this
>>>>> webrev?
>>>>> ???? - If we do want to change the field, should/could it go in an
>>>>> initial
>>>>> webrev or should it go in the JEP-331 webrev whenever/ifever it
>>>>> goes in?
>>>>> And if we do wait, could we at least converge on a renaming now so
>>>>> that
>>>>> this does not become a point of contention for that webrev's review?
>>>>>
>>>>> If I read your answer correctly:
>>>>> ?????? - You are saying that we should keep the _end field
>>>>> altogether; or
>>>> at
>>>>> least only rename the field not the methods to access it, thus
>>>>> reducing
>>>> the
>>>>> change scope.
>>>>> ?????? - You are also saying to wait for the JEP-331 webrev's final
>>>> iteration
>>>>> and integrate it in one step
>>>>>
>>>>> Have I understood your answer correctly?
>>>>>
>>>>> Again, I am fine with renaming to whatever or not renaming at all.
>>>>> I just
>>>>> am trying to get forward progress here :)
>>>>>
>>>>> Thanks for your help!
>>>>> Jc
>>>>>
>>>>> On Mon, Apr 16, 2018 at 3:29 PM <dean.long at oracle.com> wrote:
>>>>>
>>>>>> Hi JC.? Others might disagree, but I would vote "no" on doing this
>>>>>> renaming now, before the JEP, and even in the context of the JEP, I
>>>>>> don't think renaming the field requires renaming all the uses.? The
>>>>>> compiler code is only interested in the fast path, so it's
>>>>>> implicitly
>>>>>> understood.? Also, if there is a fast_path_end(), then isn't it
>>>>>> logical
>>>>>> to have fast_path_start() paired with it?? ("start" is already
>>>>>> overloaded, but nobody is suggesting adding
>>>>>> allocation_start()/current_start()/hard_start() are they?).? My
>>>>>> opinion
>>>>>> is that it's fine the way it is.
>>>>>>
>>>>>> dl
>>>>>>
>>>>>> On 4/16/18 1:43 PM, JC Beyler wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I've left the mail thread from the hotspot-gc-dev below for
>>>>>>> tracking
>>>>>>> purposes but will start a new request here.
>>>>>>>
>>>>>>> - I'm trying to push a renaming of a TLAB field to make my work for
>>>>>> JEP-331
>>>>>>> <http://openjdk.java.net/jeps/331> easier
>>>>>>> ????? - There is an understanding that if JEP-331 does not make
>>>>>>> it, this
>>>>>> might
>>>>>>> be useless and I'll revert if that is what the community wants;
>>>>>>> however
>>>>>> the
>>>>>>> new name seems better anyway so perhaps not?
>>>>>>>
>>>>>>> - The webrev renames a field used across the various back-ends and
>>>> Graal
>>>>>>> ????? - The webrev is here:
>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.04/
>>>>>>>
>>>>>>> Could I please get some feedback on this?
>>>>>>>
>>>>>>> Thanks all for your help,
>>>>>>> Jc
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Apr 13, 2018 at 2:37 AM Stefan Johansson <
>>>>>>> stefan.johansson at oracle.com> wrote:
>>>>>>>
>>>>>>>> Hi JC,
>>>>>>>>
>>>>>>>> I don't have a name, but I've looked at bit more at the
>>>>>>>> failures and I
>>>>>>>> think they are unrelated and one of the local compiler engineers
>>>> agree.
>>>>>>>>
>>>>>>>> I also ran some local testing and was not able to get any error
>>>>>>>> with
>>>> you
>>>>>>>> latest changes, but verified that it doens't work without the
>>>>>>>> graal
>>>>>>>> parts. So they seem good. It might still be good to switch this
>>>>>>>> over
>>>> to
>>>>>>>> the general hotspot-dev list to let someone with Graal
>>>>>>>> knowledge to
>>>> look
>>>>>>>> at the change and make sure everything is correct.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Stefan
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2018-04-12 17:26, JC Beyler wrote:
>>>>>>>>> Hi Stefan,
>>>>>>>>>
>>>>>>>>> Thanks for testing :). I've renamed the bug title in the JBS
>>>>>>>>> and will
>>>>>>>>> emit a new webrev shortly. Do you have the name of a compiler
>>>> engineer
>>>>>>>>> in mind or should I perhaps now move this conversation to the
>>>>>>>>> general
>>>>>>>>> hotspot-dev mailing list and ask there?
>>>>>>>>>
>>>>>>>>> The alternative is to add the compiler-mailing list to this email
>>>>>> thread
>>>>>>>>> and ask there before sending to the general list. What do you
>>>>>>>>> think
>>>> is
>>>>>>>> best?
>>>>>>>>> Thanks for all your help,
>>>>>>>>> Jc
>>>>>>>>>
>>>>>>>>> On Thu, Apr 12, 2018 at 2:09 AM Stefan Johansson
>>>>>>>>> <stefan.johansson at oracle.com
>>>>>>>>> <mailto:stefan.johansson at oracle.com>>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ?????? On 2018-04-11 17:48, JC Beyler wrote:
>>>>>>>>> ??????? > Hi Stefan,
>>>>>>>>> ??????? >
>>>>>>>>> ??????? > Sorry about that, I must have missed adding the
>>>>>>>>> files or
>>>>>>>>> ?????? something. Here
>>>>>>>>> ??????? > is a webrev that added the changes for the SA file:
>>>>>>>>> ??????? > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/
>>>>>>>>> ??????? >
>>>>>>>>> ?????? No problem, this looks good. I kicked of a run in our test
>>>> system
>>>>>> to
>>>>>>>>> ?????? get
>>>>>>>>> ?????? some more coverage and have tried to include some Graal
>>>> testing.
>>>>>> I'll
>>>>>>>>> ?????? let you know the results once they are done.
>>>>>>>>>
>>>>>>>>> ?????? Please also update the bug title both in JBS and the
>>>>>>>>> changeset.
>>>>>>>>>
>>>>>>>>> ?????? Cheers,
>>>>>>>>> ?????? Stefan
>>>>>>>>>
>>>>>>>>> ??????? > I changed the method name, which propagated a change
>>>>>>>>> to:
>>>>>>>>> ??????? >
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
>>>>
>>>>>>>>> ??????? >
>>>>>>>>> ??????? > I tried testing your test file. It exists in my
>>>>>>>>> branch (if
>>>> the
>>>>>>>>> ?????? same) under:
>>>>>>>>> ??????? > hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
>>>>>>>>> ??????? >
>>>>>>>>> ??????? > and interestingly (which generally means I did
>>>>>>>>> something
>>>>>> wrong),
>>>>>>>> it
>>>>>>>>> ??????? > passed before/after the change so I could not verify
>>>>>>>>> that
>>>> this
>>>>>> is
>>>>>>>>> ?????? a test
>>>>>>>>> ??????? > showing that all is well in the world on my side.
>>>>>>>>> Any ideas
>>>> of
>>>>>>>>> ?????? what I
>>>>>>>>> ??????? > did wrong?
>>>>>>>>> ??????? >
>>>>>>>>> ??????? > I did again test it for hotspot/jtreg/compiler/aot/ and
>>>>>>>>> ??????? > hotspot/jtreg/serviceability/jvmti and it passes those.
>>>>>>>>> ??????? >
>>>>>>>>> ??????? > Thanks for all your help,
>>>>>>>>> ??????? > Jc
>>>>>>>>> ??????? >
>>>>>>>>> ??????? >
>>>>>>>>> ??????? >
>>>>>>>>> ??????? > On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson
>>>>>>>>> ??????? > <stefan.johansson at oracle.com <mailto:
>>>>>> stefan.johansson at oracle.com>
>>>>>>>>> <mailto:stefan.johansson at oracle.com
>>>>>>>>> <mailto:stefan.johansson at oracle.com>>> wrote:
>>>>>>>>> ??????? >
>>>>>>>>> ??????? >???? Hi JC,
>>>>>>>>> ??????? >
>>>>>>>>> ??????? >???? On 2018-04-11 00:56, JC Beyler wrote:
>>>>>>>>> ??????? >????? > Small update:
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >????? > Here is the fixed webrev for the '{' that
>>>>>>>>> were out of
>>>>>>>>> ?????? alignment.
>>>>>>>>> ??????? >???? This
>>>>>>>>> ??????? >????? > passed release build JTREG
>>>>>>>>> ?????? for hotspot/jtreg/compiler/jvmti (just
>>>>>>>>> ??????? >???? to run
>>>>>>>>> ??????? >????? > something as a smoke screen)
>>>>>>>>> ?????? and hotspot/jtreg/compiler/aot/ (to
>>>>>>>>> ??????? >???? test
>>>>>>>>> ??????? >????? > Graal).
>>>>>>>>> ??????? >????? >
>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >???? I think this looks better, I agree that leaving
>>>>>>>>> _end is
>>>>>>>>> ?????? tempting to
>>>>>>>>> ??????? >???? avoid a lot of change, but I think this will be
>>>>>>>>> better
>>>> in
>>>>>> the
>>>>>>>>> ?????? long run.
>>>>>>>>> ??????? >
>>>>>>>>> ??????? >???? I still miss the changes to make the SA work. To
>>>>>>>>> see a
>>>>>>>>> ?????? problem you
>>>>>>>>> ??????? >???? can run:
>>>>>>>>> ??????? >???? make CONF=fast run-test
>>>>>>>>> ??????? >
>>>>>> TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
>>>>>>>>> ??????? >
>>>>>>>>> ??????? >???? Cheers,
>>>>>>>>> ??????? >???? Stefan
>>>>>>>>> ??????? >
>>>>>>>>> ??????? >????? > Let me know what you think,
>>>>>>>>> ??????? >????? > Jc
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >????? > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler
>>>>>>>>> ?????? <jcbeyler at google.com <mailto:jcbeyler at google.com>
>>>>>>>>> ??????? >???? <mailto:jcbeyler at google.com
>>>>>>>>> <mailto:jcbeyler at google.com
>>>>>>
>>>>>>>>> ??????? >????? > <mailto:jcbeyler at google.com <mailto:
>>>> jcbeyler at google.com
>>>>>>>
>>>>>>>>> <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>>>
>>>>>> wrote:
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >????? >???? Hi Karen and Stefan,
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >????? >???? @Stefan: Naming is hard :)
>>>>>>>>> ??????? >????? >???? @Karen: thanks for the Graal comment, I
>>>>>>>>> fixed it
>>>> in
>>>>>>>>> ?????? the new
>>>>>>>>> ??????? >???? webrev,
>>>>>>>>> ??????? >????? >???? let me know what you think :)
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >????? >???? I think the naming convention suggested
>>>>>>>>> in this
>>>>>> webrev
>>>>>>>>> ?????? came from
>>>>>>>>> ??????? >????? >???? conversations in for JEP-331 and I am
>>>>>>>>> actually
>>>>>>>> relatively
>>>>>>>>> ??????? >????? > indifferent to the final result (as long as we
>>>> have
>>>>>>>>> ?????? some form of
>>>>>>>>> ??????? >????? >???? forward progress :)). To be honest, I'd
>>>>>>>>> also be
>>>>>> happy
>>>>>>>>> ?????? to just
>>>>>>>>> ??????? >???? leave
>>>>>>>>> ??????? >????? >???? _end as is for all architectures and
>>>>>>>>> Graal and
>>>> have
>>>>>> a
>>>>>>>> new
>>>>>>>>> ??????? >????? > _allocation_end. However, during initial reviews
>>>> of
>>>>>>>>> ?????? JEP-331
>>>>>>>>> ??????? >???? it was
>>>>>>>>> ??????? >????? >???? deemed complicated to understand:
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >????? >???? _end -> the _end or sampling end
>>>>>>>>> ??????? >????? >???? _allocation_end -> end pointer for the last
>>>> possible
>>>>>>>>> ?????? allocation
>>>>>>>>> ??????? >????? >???? hard_end -> allocation end + reserved space
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >????? >???? That is how this naming came up and why
>>>>>>>>> hard_end
>>>>>> went
>>>>>>>> to
>>>>>>>>> ??????? > "reserved_end".
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >????? >???? I'm really indifferent, so I offer as a
>>>>>>>>> perusal:
>>>>>>>>> ??????? >????? >
>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >????? >???? I noticed a few problems of alignement of
>>>>>>>>> '{' so
>>>>>> I'll
>>>>>>>>> ?????? go fix
>>>>>>>>> ??????? >???? that.
>>>>>>>>> ??????? >????? >???? Basically this webrev does the following:
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >????? >???? - Uses fast_path_end instead of end
>>>>>>>>> ??????? >????? >???? - Reverts hard_end back to where it was
>>>>>>>>> ??????? >????? >???? - Adds the changes to Graal; there is a
>>>>>>>>> bunch of
>>>>>>>>> ?????? changes in Graal
>>>>>>>>> ??????? >????? >???? because Graal still contains a bit of
>>>>>>>>> code doing
>>>>>>>>> ?????? fasttlabrefills.
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >????? >???? Let me know what you think!
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >????? >???? Thanks,
>>>>>>>>> ??????? >????? >???? Jc
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >????? >???? On Tue, Apr 10, 2018 at 6:56 AM Karen
>>>>>>>>> Kinnear
>>>>>>>>> ??????? >????? > <karen.kinnear at oracle.com
>>>>>>>>> ?????? <mailto:karen.kinnear at oracle.com> <mailto:
>>>>>> karen.kinnear at oracle.com
>>>>>>>>> <mailto:karen.kinnear at oracle.com>>
>>>>>>>>> ??????? > <mailto:karen.kinnear at oracle.com
>>>>>>>>> ?????? <mailto:karen.kinnear at oracle.com> <mailto:
>>>>>> karen.kinnear at oracle.com
>>>>>>>>> <mailto:karen.kinnear at oracle.com>>>>
>>>>>>>>> ??????? >???? wrote:
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >????? >???????? Hi JC,
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >????? >???????? A comment about Graal. The impact on
>>>>>>>>> Graal
>>>> for
>>>>>> this
>>>>>>>>> ??????? >???? particular
>>>>>>>>> ??????? >????? >???????? change would be to break it - so
>>>>>>>>> you?ll need
>>>>>>>>> ??????? >????? >???????? to complete the Graal changes for this
>>>> renaming.
>>>>>>>>> ?????? That isn?t
>>>>>>>>> ??????? >????? >???????? optional or something that could be a
>>>>>> follow-on. It
>>>>>>>>> ??????? > >???????? is not ok to break a feature, even an
>>>>>> experimental
>>>>>>>>> ?????? one.
>>>>>>>>> ??????? >???? We will
>>>>>>>>> ??????? >????? >???????? discuss in the other thread potential
>>>> phasing of
>>>>>>>>> ?????? adding
>>>>>>>>> ??????? >???? sampling.
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >????? >???????? I did not do a thorough search -you
>>>>>>>>> can do
>>>> that
>>>>>> -
>>>>>>>>> ?????? I did find
>>>>>>>>> ??????? >????? > src/jdk.internal.vm.compiler/share/classes/
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>
>>>>>>>>> ??????? > >??????????? public final int threadTlabOffset =
>>>>>>>>> ??????? >????? > getFieldOffset("Thread::_tlab",
>>>> Integer.class,
>>>>>>>>> ??????? > >???????? "ThreadLocalAllocBuffer");
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>
>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>> ?????? threadLocalAllocBufferStartOffset =
>>>>>>>>> ??????? >????? >
>>>> ? getFieldOffset("ThreadLocalAllocBuffer::_start",
>>>>>>>>> ??????? > Integer.class,
>>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>
>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>> threadLocalAllocBufferEndOffset =
>>>>>>>>> ??????? >????? >
>>>> ? getFieldOffset("ThreadLocalAllocBuffer::_end",
>>>>>>>>> ?????? Integer.class,
>>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>
>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>> threadLocalAllocBufferTopOffset =
>>>>>>>>> ??????? >????? >
>>>> ? getFieldOffset("ThreadLocalAllocBuffer::_top",
>>>>>>>>> ?????? Integer.class,
>>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>
>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>> ?????? threadLocalAllocBufferPfTopOffset =
>>>>>>>>> ??????? >????? >
>>>>>> ?? getFieldOffset("ThreadLocalAllocBuffer::_pf_top",
>>>>>>>>> ??????? > Integer.class,
>>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>
>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>> ??????? > threadLocalAllocBufferSlowAllocationsOffset
>>>>>>>>> ??????? >????? >???????? =
>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
>>>>>>>>> ??????? >????? >???????? Integer.class, "unsigned");
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>
>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>> ??????? > threadLocalAllocBufferFastRefillWasteOffset
>>>>>>>>> ??????? >????? >???????? =
>>>>>>>>> ??????? >
>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
>>>>>>>>> ??????? > >???????? Integer.class, "unsigned");
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>
>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>> ??????? > threadLocalAllocBufferNumberOfRefillsOffset
>>>>>>>>> ??????? >????? >???????? =
>>>>>>>>> ??????? >
>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
>>>>>>>>> ??????? > >???????? Integer.class, "unsigned");
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>
>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>> ??????? >????? > threadLocalAllocBufferRefillWasteLimitOffset
>>>> =
>>>>>>>>> ??????? >????? >
>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
>>>>>>>>> ??????? >????? >???????? Integer.class, "size_t");
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>
>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>> ??????? > threadLocalAllocBufferDesiredSizeOffset =
>>>>>>>>> ??????? >????? >
>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
>>>>>>>>> ??????? >????? >???????? Integer.class, "size_t");
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>
>>>>>>>>> ??????? > >??????????? public final int tlabAlignmentReserve =
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>> getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
>>>>
>>>>>>>>> ??????? > >???????? Integer.class, "size_t?);
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >????? >???????? hope this helps,
>>>>>>>>> ??????? >????? >???????? Karen
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >????? >>???????? On Apr 10, 2018, at 7:04 AM, Stefan
>>>> Johansson
>>>>>>>>> ??????? > >>???????? <stefan.johansson at oracle.com
>>>>>>>>> ?????? <mailto:stefan.johansson at oracle.com>
>>>>>>>>> ??????? > <mailto:stefan.johansson at oracle.com
>>>>>>>>> <mailto:stefan.johansson at oracle.com>>
>>>>>>>>> ??????? >????? >> <mailto:stefan.johansson at oracle.com
>>>>>>>>> ?????? <mailto:stefan.johansson at oracle.com>
>>>>>>>>> ??????? > <mailto:stefan.johansson at oracle.com
>>>>>>>>> <mailto:stefan.johansson at oracle.com>>>> wrote:
>>>>>>>>> ??????? >????? >>
>>>>>>>>> ??????? >????? >>???????? Hi JC,
>>>>>>>>> ??????? >????? >>
>>>>>>>>> ??????? >????? >>???????? I realize that the names have been
>>>>>>>>> discussed
>>>>>>>>> ?????? before but I'm
>>>>>>>>> ??????? >????? >>???????? leaning towards suggesting something
>>>>>>>>> new. We
>>>>>>>>> ?????? discussed this
>>>>>>>>> ??????? >????? >>???????? briefly here in the office and
>>>>>>>>> others might
>>>>>> have
>>>>>>>>> ?????? different
>>>>>>>>> ??????? >????? >>???????? opinions. One point that came up is
>>>>>>>>> that if
>>>> we
>>>>>> do
>>>>>>>>> ?????? this
>>>>>>>>> ??????? >???? change
>>>>>>>>> ??????? >????? >>???????? and change all usages of
>>>>>>>>> ?????? JavaThread::tlab_end_offset() it
>>>>>>>>> ??????? >????? >>???????? would be good to make sure the new
>>>>>>>>> name is
>>>>>> good.
>>>>>>>>> ?????? To us
>>>>>>>>> ??????? >????? >>???????? _current_end is not very
>>>>>>>>> descriptive, but
>>>>>> naming
>>>>>>>>> ?????? is hard and
>>>>>>>>> ??????? >????? >>???????? the best we could come up with is
>>>>>> _fast_path_end
>>>>>>>>> ?????? which would
>>>>>>>>> ??????? >????? >>???????? give the code:
>>>>>>>>> ??????? >????? >>????????? cmpptr(end, Address(thread,
>>>>>>>>> ??????? >????? >> JavaThread::tlab_fast_path_end_offset()));
>>>>>>>>> ??????? >????? >> jcc(Assembler::above, slow_case);
>>>>>>>>> ??????? >????? >>
>>>>>>>>> ??????? >????? >>???????? I think this reads pretty good and
>>>>>>>>> is fairly
>>>>>>>>> ?????? clear. If we do
>>>>>>>>> ??????? >????? >>???????? this rename I think you can re-use
>>>>>>>>> _end in
>>>>>> JEP-331
>>>>>>>>> ??????? >???? instead of
>>>>>>>>> ??????? >????? >>???????? calling it _allocation_end. But that
>>>>>>>>> is a
>>>> later
>>>>>>>>> ?????? review :)
>>>>>>>>> ??????? >????? >>
>>>>>>>>> ??????? >????? >>???????? Also, is there a good reason for
>>>>>>>>> renaming
>>>>>>>>> ?????? hard_end() to
>>>>>>>>> ??????? >????? >>???????? reserved_end()?
>>>>>>>>> ??????? >????? >>
>>>>>>>>> ??????? >????? >>???????? One additional thing, you need to
>>>>>>>>> update
>>>> the SA
>>>>>>>>> ?????? to reflect
>>>>>>>>> ??????? >????? >>???????? this change. I think the only place you
>>>> need to
>>>>>>>>> ?????? fix is in:
>>>>>>>>> ??????? >????? >>
>>>>>>>>> ??????? >
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
>>>>
>>>>>>>>> ??????? >????? >>
>>>>>>>>> ??????? >????? >>???????? Thanks,
>>>>>>>>> ??????? >????? >>???????? Stefan
>>>>>>>>> ??????? >????? >>
>>>>>>>>> ??????? >????? >>???????? On 2018-04-09 19:24, JC Beyler wrote:
>>>>>>>>> ??????? >????? >>>???????? Hi all,
>>>>>>>>> ??????? >????? >>>???????? Small pre-amble to this request:
>>>>>>>>> ??????? >????? >>>???????? In my work to try to get a heap
>>>>>>>>> sampler in
>>>>>>>>> ?????? OpenJDK (via JEP
>>>>>>>>> ??????? >????? >>>???????? 331
>>>>>>>>> ??????? > <https://bugs.openjdk.java.net/browse/JDK-8171119>),
>>>> I'm
>>>>>>>>> ??????? > >>>???????? trying to reduce the footprint of my
>>>> change so
>>>>>>>>> ?????? that the
>>>>>>>>> ??????? >????? >>>???????? integration can be easier. I was
>>>>>>>>> told that
>>>>>>>>> ?????? generally a JEP
>>>>>>>>> ??????? >????? >>>???????? webrev should be feature complete
>>>>>>>>> and go in
>>>>>>>> at-once.
>>>>>>>>> ??????? >???? However,
>>>>>>>>> ??????? >????? >>>???????? with the change touching quite a
>>>>>>>>> bit of
>>>>>> various
>>>>>>>> code
>>>>>>>>> ??????? >???? pieces,
>>>>>>>>> ??????? >????? >>>???????? I was trying to figure out what
>>>>>>>>> could be
>>>>>>>>> ?????? separated as not
>>>>>>>>> ??????? >????? >>>???????? "part of the feature".
>>>>>>>>> ??????? >????? >>>???????? I asked around and said that perhaps a
>>>>>> solution
>>>>>>>>> ?????? would be to
>>>>>>>>> ??????? >????? >>>???????? cut up the renaming of TLAB's end
>>>>>>>>> field
>>>> that I
>>>>>>>>> ?????? do in that
>>>>>>>>> ??????? >????? >>>???????? webrev. Because I'm renaming a
>>>>>>>>> field in
>>>> TLAB
>>>>>>>> used by
>>>>>>>>> ??????? >???? various
>>>>>>>>> ??????? >????? >>>???????? backends for that work, I have to
>>>>>>>>> update
>>>> every
>>>>>>>>> ?????? architecture
>>>>>>>>> ??????? >????? >>>???????? dependent code to reflect it.
>>>>>>>>> ??????? >????? >>>???????? I entirely understand that perhaps
>>>>>>>>> this is
>>>> not
>>>>>>>>> ?????? in the
>>>>>>>>> ??????? >???? habits
>>>>>>>>> ??????? >????? >>>???????? and very potentially might not be
>>>>>>>>> the way
>>>>>> things
>>>>>>>> are
>>>>>>>>> ??????? > >>>???????? generally done. If so, I apologize and let
>>>> me
>>>>>>>>> ?????? know if you
>>>>>>>>> ??????? >????? >>>???????? would not want this to go in
>>>>>>>>> separately :)
>>>>>>>>> ??????? >????? >>>???????? Final note: there is still a chance
>>>>>>>>> JEP-331
>>>>>> does
>>>>>>>>> ?????? not go in.
>>>>>>>>> ??????? >????? >>>???????? If it does not, we can leave the
>>>>>>>>> new name
>>>> in
>>>>>>>>> ?????? place or I'll
>>>>>>>>> ??????? >????? >>>???????? happily revert it. I can even
>>>>>>>>> create an
>>>> issue
>>>>>> to
>>>>>>>>> ?????? track this
>>>>>>>>> ??????? >????? >>>???????? if that makes it easier for all.
>>>>>>>>> ??????? >????? >>>???????? End of the pre-amble.
>>>>>>>>> ??????? >????? >>>???????? The 33-line change webrev in
>>>>>>>>> question is
>>>> here:
>>>>>>>>> ??????? > >>>
>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
>>>>>>>>> ??????? > >>>???????? I fixed all the architectures and JVMCI and
>>>>>> ran
>>>>>>>>> ?????? a few
>>>>>>>>> ??????? >???? sanity
>>>>>>>>> ??????? >????? >>>???????? tests to ensure I had not missed
>>>>>>>>> anything.
>>>>>>>>> ??????? >????? >>>???????? Thanks for your help and I hope
>>>>>>>>> this is not
>>>>>> too
>>>>>>>> much
>>>>>>>>> ??????? >???? trouble,
>>>>>>>>> ??????? >????? >>>???????? Jc
>>>>>>>>> ??????? >????? >>>???????? Ps: there is a graal change that
>>>>>>>>> needs to
>>>>>> happen
>>>>>>>>> ?????? but I was
>>>>>>>>> ??????? >????? >>>???????? not sure who/where
>>>> <https://teams.googleplex.com/u/where>
>>>>>> <https://teams.googleplex.com/u/where>
>>>>>>>> <https://teams.googleplex.com/u/where>
>>>>>>>>> <https://teams.googleplex.com/u/where>
>>>>>>>>> ??????? > <https://teams.googleplex.com/u/where>
>>>>>>>>> ??????? > <https://teams.googleplex.com/u/where> to
>>>>>>>>> ??????? >????? >>>???????? ask about it. I was told it could
>>>>>>>>> happen
>>>> in a
>>>>>>>>> ?????? separate
>>>>>>>>> ??????? >????? >>>???????? webrev. Can anyone point me to the
>>>>>>>>> right
>>>>>>>> direction?
>>>>>>>>> ??????? >???? Should it
>>>>>>>>> ??????? >????? >>>???????? just be hotspot-compiler-dev?
>>>>>>>>> ??????? >????? >
>>>>>>>>> ??????? >
>>>>>>>>>
>>>>>>
>>>>>>
>>>>
From coleen.phillimore at oracle.com Wed Apr 18 14:00:05 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 18 Apr 2018 10:00:05 -0400
Subject: RFR (M) 8201505: Use WeakHandle for ProtectionDomainCacheTable
and ResolvedMethodTable
In-Reply-To: <7091958f-01a0-beb0-7ab7-2372944f54b1@oracle.com>
References: <7091958f-01a0-beb0-7ab7-2372944f54b1@oracle.com>
Message-ID: <9cf8fcf9-56cc-8851-c57d-61851a7b39a7@oracle.com>
From some discussions, I've changed
ResolvedMethodTable::adjust_method_entries() to have a for loop to avoid
the bug in redefinition that this fixed.? See:
open webrev at http://cr.openjdk.java.net/~coleenp/8201505.02/webrev
Coleen
On 4/13/18 8:12 AM, coleen.phillimore at oracle.com wrote:
> 8193524: Redefining a method that removes use of 1 or more lambda
> expressions causes the JVM to hang
> Summary: Remove oop pointers from runtime data structures and fix
> missing next assignment.
>
> Also, this contains a fix for
> https://bugs.openjdk.java.net/browse/JDK-8193524 (forgotten next
> pointer assignment) because I changed that function 3 lines up, and
> tests contributed by Lois.
>
> Tested with mach5 tier1-5.
>
> Thanks,
> Coleen
>
From ChrisPhi at LGonQn.Org Wed Apr 18 14:27:43 2018
From: ChrisPhi at LGonQn.Org (Chris Phillips)
Date: Wed, 18 Apr 2018 10:27:43 -0400
Subject: [11]RFR(S): 8201509: Zero : S390x (S390 and not _LP64)
atomic_copy64 inline assembler is wrong.
In-Reply-To: <687b2ace-58a4-8807-ff38-aac261cf291e@redhat.com>
References: <2061faf8-b9f3-4559-4774-d55f450e0de8@LGonQn.Org>
<687b2ace-58a4-8807-ff38-aac261cf291e@redhat.com>
Message-ID: <87744d4d-1057-1265-5bd4-61c7249cc263@LGonQn.Org>
Hi Aleksey,
On 18/04/18 05:20 AM, Aleksey Shipilev wrote:
> On 04/17/2018 05:46 PM, Chris Phillips wrote:
>> Hi,
>>
>> Please review this small but significant change to Zero only code
>> related to S390 (31bit) Zero self-build failures.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201509
>> webrev: http://cr.openjdk.java.net/~chrisphi/JDK-8201509/webrev.1
>
> Looks okay to me.
>
> In addition to discussion in the bug itself, it seems we can argue it should look similar to the
> PPC32 && !__SPE__ block above. Which is does, as far as operands are concerned. But, are we sure
> ld/std is enough to copy 64 bits on S390? I assume "d" is for double in those insns?
Yes ld/std memory is double or 64 bits on s390 31bit , the "=&f"
specifies an fp reg of at least 64bits.
>
> Thanks,
> -Aleksey
>
Thanks for reviewing!
Chris
From shade at redhat.com Wed Apr 18 14:29:29 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 18 Apr 2018 16:29:29 +0200
Subject: [11]RFR(S): 8201509: Zero : S390x (S390 and not _LP64)
atomic_copy64 inline assembler is wrong.
In-Reply-To: <87744d4d-1057-1265-5bd4-61c7249cc263@LGonQn.Org>
References: <2061faf8-b9f3-4559-4774-d55f450e0de8@LGonQn.Org>
<687b2ace-58a4-8807-ff38-aac261cf291e@redhat.com>
<87744d4d-1057-1265-5bd4-61c7249cc263@LGonQn.Org>
Message-ID: <9e961d96-6e78-ee6c-0d40-88b539d3a1ad@redhat.com>
On 04/18/2018 04:27 PM, Chris Phillips wrote:
> Hi Aleksey,
>
> On 18/04/18 05:20 AM, Aleksey Shipilev wrote:
>> On 04/17/2018 05:46 PM, Chris Phillips wrote:
>>> Hi,
>>>
>>> Please review this small but significant change to Zero only code
>>> related to S390 (31bit) Zero self-build failures.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201509
>>> webrev: http://cr.openjdk.java.net/~chrisphi/JDK-8201509/webrev.1
>>
>> Looks okay to me.
>>
>> In addition to discussion in the bug itself, it seems we can argue it should look similar to the
>> PPC32 && !__SPE__ block above. Which is does, as far as operands are concerned. But, are we sure
>> ld/std is enough to copy 64 bits on S390? I assume "d" is for double in those insns?
>
> Yes ld/std memory is double or 64 bits on s390 31bit , the "=&f"
> specifies an fp reg of at least 64bits.
Okay! Looks good then.
-Aleksey
From stefan.karlsson at oracle.com Wed Apr 18 14:47:51 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 18 Apr 2018 16:47:51 +0200
Subject: RFR (M) 8201537: Remove is_alive closure from
Klass::is_loader_alive()
In-Reply-To: <f380f832-3c6d-5c60-09c5-4b447f87d94b@oracle.com>
References: <f380f832-3c6d-5c60-09c5-4b447f87d94b@oracle.com>
Message-ID: <9bb05931-93c8-94eb-1740-9ddb5f3f325f@oracle.com>
Looks good.
StefanK
On 2018-04-16 16:00, coleen.phillimore at oracle.com wrote:
> Summary: remove is_alive closure from callers of Klass::is_loader_alive
> so that cleaning metadata doesn't require GC closure.
>
> This changes runtime, GC and compiler code.
>
> Tested with mach5 tier1-5 with no failures.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8201537.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8201537
>
> Thanks,
> Coleen
From stefan.karlsson at oracle.com Wed Apr 18 14:51:36 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 18 Apr 2018 16:51:36 +0200
Subject: RFR (M) 8201505: Use WeakHandle for ProtectionDomainCacheTable
and ResolvedMethodTable
In-Reply-To: <9cf8fcf9-56cc-8851-c57d-61851a7b39a7@oracle.com>
References: <7091958f-01a0-beb0-7ab7-2372944f54b1@oracle.com>
<9cf8fcf9-56cc-8851-c57d-61851a7b39a7@oracle.com>
Message-ID: <c922028f-7a00-3c93-8b25-dd14bafb7b12@oracle.com>
Hi Coleen,
I haven't reviewed the tests and I can't be 100% sure that the new lock
ordering level is correct, but the other parts of the code looks good to me.
Thanks,
StefanK
On 2018-04-18 16:00, coleen.phillimore at oracle.com wrote:
>
> From some discussions, I've changed
> ResolvedMethodTable::adjust_method_entries() to have a for loop to avoid
> the bug in redefinition that this fixed.? See:
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8201505.02/webrev
>
> Coleen
>
> On 4/13/18 8:12 AM, coleen.phillimore at oracle.com wrote:
>> 8193524: Redefining a method that removes use of 1 or more lambda
>> expressions causes the JVM to hang
>> Summary: Remove oop pointers from runtime data structures and fix
>> missing next assignment.
>>
>> Also, this contains a fix for
>> https://bugs.openjdk.java.net/browse/JDK-8193524 (forgotten next
>> pointer assignment) because I changed that function 3 lines up, and
>> tests contributed by Lois.
>>
>> Tested with mach5 tier1-5.
>>
>> Thanks,
>> Coleen
>>
>
From coleen.phillimore at oracle.com Wed Apr 18 14:53:26 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 18 Apr 2018 10:53:26 -0400
Subject: RFR (M) 8201537: Remove is_alive closure from
Klass::is_loader_alive()
In-Reply-To: <9bb05931-93c8-94eb-1740-9ddb5f3f325f@oracle.com>
References: <f380f832-3c6d-5c60-09c5-4b447f87d94b@oracle.com>
<9bb05931-93c8-94eb-1740-9ddb5f3f325f@oracle.com>
Message-ID: <b5442987-de6a-f4b1-257d-4e34e43221f4@oracle.com>
Thanks!
Coleen
On 4/18/18 10:47 AM, Stefan Karlsson wrote:
> Looks good.
>
> StefanK
>
> On 2018-04-16 16:00, coleen.phillimore at oracle.com wrote:
>> Summary: remove is_alive closure from callers of
>> Klass::is_loader_alive so that cleaning metadata doesn't require GC
>> closure.
>>
>> This changes runtime, GC and compiler code.
>>
>> Tested with mach5 tier1-5 with no failures.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8201537.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8201537
>>
>> Thanks,
>> Coleen
From christoph.langer at sap.com Wed Apr 18 15:01:09 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 18 Apr 2018 15:01:09 +0000
Subject: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
In-Reply-To: <4dcc535e-4906-05a8-0636-65191f8a8695@oracle.com>
References: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
<CAA-vtUz48xUdXQzDEAuS2JDdnis7n2pAjfJ52dgFkhKskNoX9Q@mail.gmail.com>
<b65af851-d138-42b2-847a-fd6650a1767b@oracle.com>
<CAA-vtUz+cyza6GOnVN7p-9XJ-JYo_vBozMNh0K=7woUbV4mKzA@mail.gmail.com>
<b0fcb60f-ff76-9b98-871c-8692f4504442@oracle.com>
<43ae45216d3545518b274dd7246d7862@sap.com>
<4dcc535e-4906-05a8-0636-65191f8a8695@oracle.com>
Message-ID: <5fc75353a1a74c22a0c24e2bdfc2d05b@sap.com>
Hi,
> > I think it could be cleaned up nicely by removing jio_print and jio_printf
> from jvm.cpp and doing all in ostream.cpp. At the one place where we would
> call jio_print after my patch, we can do the vfprintf hook check and then
> either write to the hook or do the raw write. And the other 2 places where
> jio_printf is employed, we can just call
> jio_vfprintf(defaultStream::output_stream()). I don't see any other users of
> jio_print and jio_printf in the jdk repo.
> >
> > Any objections to that (e.g. some Oracle closed coding that'd break)?
> Otherwise I'll prepare something...
>
> $ grep -r jio_print closed
>
> Showed nothing found.
I've prepared a new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201649.1/
I remove jio_printf and jio_print completely.
If we agree that in defaultStream::write(), the raw write is not needed and we can use fprintf, we could further simplify the code to just call jio_fprintf.
Furhtermore, I have updated the jio_*print* function declarations in jvm.cpp to match those of jvm.h. Is that desired (I thought yes, in times where we try to get rid of the mapfiles anyway). I wonder if those symbols can be taken out of make/hotspot/symbols/symbols-shared then...
Best regards
Christoph
From coleen.phillimore at oracle.com Wed Apr 18 15:01:42 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 18 Apr 2018 11:01:42 -0400
Subject: RFR (M) 8201505: Use WeakHandle for ProtectionDomainCacheTable
and ResolvedMethodTable
In-Reply-To: <c922028f-7a00-3c93-8b25-dd14bafb7b12@oracle.com>
References: <7091958f-01a0-beb0-7ab7-2372944f54b1@oracle.com>
<9cf8fcf9-56cc-8851-c57d-61851a7b39a7@oracle.com>
<c922028f-7a00-3c93-8b25-dd14bafb7b12@oracle.com>
Message-ID: <e3724798-b81b-836e-ad2d-14f6daf082dc@oracle.com>
Thank you for reviewing this.? The lock ranking code in general needs
further work because now we decide rankings in sort of an ad-hoc manner
(ie if we get the assert).
thanks,
Coleen
On 4/18/18 10:51 AM, Stefan Karlsson wrote:
> Hi Coleen,
>
> I haven't reviewed the tests and I can't be 100% sure that the new
> lock ordering level is correct, but the other parts of the code looks
> good to me.
>
> Thanks,
> StefanK
>
> On 2018-04-18 16:00, coleen.phillimore at oracle.com wrote:
>>
>> ?From some discussions, I've changed
>> ResolvedMethodTable::adjust_method_entries() to have a for loop to
>> avoid the bug in redefinition that this fixed.? See:
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8201505.02/webrev
>>
>> Coleen
>>
>> On 4/13/18 8:12 AM, coleen.phillimore at oracle.com wrote:
>>> 8193524: Redefining a method that removes use of 1 or more lambda
>>> expressions causes the JVM to hang
>>> Summary: Remove oop pointers from runtime data structures and fix
>>> missing next assignment.
>>>
>>> Also, this contains a fix for
>>> https://bugs.openjdk.java.net/browse/JDK-8193524 (forgotten next
>>> pointer assignment) because I changed that function 3 lines up, and
>>> tests contributed by Lois.
>>>
>>> Tested with mach5 tier1-5.
>>>
>>> Thanks,
>>> Coleen
>>>
>>
From thomas.stuefe at gmail.com Wed Apr 18 15:55:13 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 18 Apr 2018 17:55:13 +0200
Subject: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
In-Reply-To: <5fc75353a1a74c22a0c24e2bdfc2d05b@sap.com>
References: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
<CAA-vtUz48xUdXQzDEAuS2JDdnis7n2pAjfJ52dgFkhKskNoX9Q@mail.gmail.com>
<b65af851-d138-42b2-847a-fd6650a1767b@oracle.com>
<CAA-vtUz+cyza6GOnVN7p-9XJ-JYo_vBozMNh0K=7woUbV4mKzA@mail.gmail.com>
<b0fcb60f-ff76-9b98-871c-8692f4504442@oracle.com>
<43ae45216d3545518b274dd7246d7862@sap.com>
<4dcc535e-4906-05a8-0636-65191f8a8695@oracle.com>
<5fc75353a1a74c22a0c24e2bdfc2d05b@sap.com>
Message-ID: <CAA-vtUyKJ4dXw7RS+CvTkKj5j0R+UB-4_pwpHqDExKCYGR8vhQ@mail.gmail.com>
Hi Chrisoph,
thanks for the new webrev, this looks all very reasonable.
Unfortunately a small issue occurred to me while thinking this over...
Sigh, this turns out to be more complicated than I thought.
The original intent of this change was to get rid of that extra copy
step we do in "call_jio_print" which aims to ensure that the string we
hand down to jio_print is zero terminated.
But ultimately, the problem was never jio_print, but the vfprintf
hook: The vfprintf hook has the form "foo(FILE*, char* fmt, ....) and
this is a contract with an embedding program - it has to provide a
"fprinf-like function" but ultimately can do whatever it wants with
the arguments we give it.
(IMHO this whole vfprintf hook thing was very badly designed. We had a
number of issues with this already. For a discussion about some
details, see e.g.
http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-May/026794.html
.)
The problem I see is that now we may call the vfprintf hook with
something like ("%.*s", precision, s) with the explicit intention of
passing in not-zero-terminated strings for s and a precision which
prevents us reading beyond the end of s. This was the whole point - we
avoid the copy step.
As we discussed offlist, this would be a perfectly valid fix were we
to feed those arguments to a standard fprintf() function which is
POSIX compatible, because POSIX states for the format specifier 's':
<quote>
The argument shall be a pointer to an array of char. Bytes from the
array shall be written up to (but not including) any terminating null
byte. If the precision is specified, no more than that many bytes
shall be written. If the precision is not specified or is greater than
the size of the array, the application shall ensure that the array
contains a null byte.
</quote>
This explicitly allows us to pass a pointer to a non-zero-terminated
string as long as the precision is smaller than its length.
However, the argument vfprintf hook can be anything. It is a
user-provided function. Usually they will probably just call vxxprintf
functions from the libc, but for all we know they may roll their own
printf routine. So, we may uncover bugs in their implementation.
Seeing that the vfprintf hook is very badly documented, we move in
gray area here. We may break user code which has a bad, non-Posix
implementation of the vfprintf hook.
I would like to know if others think this concern is valid.
Otherwise, the patch looks good.
..Thomas
On Wed, Apr 18, 2018 at 5:01 PM, Langer, Christoph
<christoph.langer at sap.com> wrote:
> Hi,
>
>> > I think it could be cleaned up nicely by removing jio_print and jio_printf
>> from jvm.cpp and doing all in ostream.cpp. At the one place where we would
>> call jio_print after my patch, we can do the vfprintf hook check and then
>> either write to the hook or do the raw write. And the other 2 places where
>> jio_printf is employed, we can just call
>> jio_vfprintf(defaultStream::output_stream()). I don't see any other users of
>> jio_print and jio_printf in the jdk repo.
>> >
>> > Any objections to that (e.g. some Oracle closed coding that'd break)?
>> Otherwise I'll prepare something...
>>
>> $ grep -r jio_print closed
>>
>> Showed nothing found.
>
> I've prepared a new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201649.1/
>
> I remove jio_printf and jio_print completely.
>
> If we agree that in defaultStream::write(), the raw write is not needed and we can use fprintf, we could further simplify the code to just call jio_fprintf.
>
> Furhtermore, I have updated the jio_*print* function declarations in jvm.cpp to match those of jvm.h. Is that desired (I thought yes, in times where we try to get rid of the mapfiles anyway). I wonder if those symbols can be taken out of make/hotspot/symbols/symbols-shared then...
>
> Best regards
> Christoph
From martin.doerr at sap.com Wed Apr 18 16:37:43 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Wed, 18 Apr 2018 16:37:43 +0000
Subject: RFR 8201799: Build failures after JDK-8195099 (Concurrent
safe-memory-reclamation mechanism)
In-Reply-To: <5AD73E53.90904@oracle.com>
References: <150dc231-d81e-58da-fa46-fd2397bb7ca2@redhat.com>
<ee7c6a6c-7697-ca4b-dd3d-484ca24aeabd@oracle.com> <5AD73E53.90904@oracle.com>
Message-ID: <803cb23d4b754d2384d9681950f5297c@sap.com>
Hi Erik,
thank you for bringing this issue up again.
In my opinion, good multi-threaded code specifies ordering semantics precisely for each lock-free access. I think this was done well enough here by adding a comment.
It'd be great if we could specify semantics for Atomic:add like we do for Atomic::cmpchgx.
However, the double-fence is a very bad default from performance perspective. I wonder if PPC64 is the only platform which gets hit.
Would it be acceptable to set the default to memory_order_acquire_release and specify memory_order_conservative for the new usage? I think this would fit perfectly for PPC64, but some people may not like it. One could say PPC64 is the problem, but one could also say the VM code is the problem ??
I don't really like the straight forward fix to insert a fence with #ifdef AIX.
Best regards,
Martin
-----Original Message-----
From: Erik ?sterlund [mailto:erik.osterlund at oracle.com]
Sent: Mittwoch, 18. April 2018 14:47
To: David Holmes <david.holmes at oracle.com>; Aleksey Shipilev <shade at redhat.com>; hotspot-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>
Subject: Re: RFR 8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism)
Hi,
Please also note that the Atomic::add used in write_synchronize assumes
bidirectional fencing (which is the contract provided by Atomic::add).
This is however not true for the PPC backend of Atomic::add - it has
acq_rel semantics instead. So this mechanism is currently not safe to
use on PPC.
From globalCounter.cpp:
61 // Atomic::add must provide fence since we have storeload
dependency.
62 volatile uintx gbl_cnt = Atomic::add((uintx)COUNTER_INCREMENT,
&_global_counter._counter);
Might want to have a look at the safe use of this mechanism on PPC as a
follow-up.
Thanks,
/Erik
On 2018-04-18 14:27, David Holmes wrote:
> Hi Aleksey,
>
> On 18/04/2018 9:50 PM, Aleksey Shipilev wrote:
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8201799
>>
>> Fix:
>>
>> diff -r bfba4712d4ff
>> src/hotspot/share/utilities/globalCounter.inline.hpp
>> --- a/src/hotspot/share/utilities/globalCounter.inline.hpp Wed Apr 18
>> 11:36:48 2018 +0200
>> +++ b/src/hotspot/share/utilities/globalCounter.inline.hpp Wed Apr 18
>> 13:50:34 2018 +0200
>> @@ -27,6 +27,7 @@
>>
>> #include "runtime/orderAccess.inline.hpp"
>> #include "runtime/thread.hpp"
>
> The above line can be deleted now.
>
>> +#include "runtime/thread.inline.hpp"
>
> Fix is good.
>
> Thanks,
> David
>
>> #include "utilities/globalCounter.hpp"
>>
>> inline void GlobalCounter::critical_section_begin(Thread *thread) {
>>
>> Testing: failing aarch64 build
>>
>> Thanks,
>> -Aleksey
>>
From serguei.spitsyn at oracle.com Wed Apr 18 17:10:50 2018
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 18 Apr 2018 10:10:50 -0700
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
fast_path_end
In-Reply-To: <ff9474cd-6f07-446c-12b5-2dafbca35ce3@oracle.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
<CAF9BGBz-=JqbaJ37B5G35u3Ziei53fjhf=JMaWFd06WeZUCLfQ@mail.gmail.com>
<CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
<3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>
<CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>
<5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
<CAF9BGBxEPXLTiyD-xG_ECyveyW0PXQL0+-z7jkw3Rv4QrkkszQ@mail.gmail.com>
<ec1a3e0e-ca9b-8668-b260-1fd3e612b7f7@oracle.com>
<CAF9BGBy-LBKCwJHQPdAQ65VRcSFBwVkk9dm8MLC_nrefE_JdEw@mail.gmail.com>
<e6528c19-5691-1215-1ac5-0349801b79b5@oracle.com>
<CAF9BGBwBgyOoJTfJU_YmqYJgSZ+1985yx_sSMJC4wNJELw1XDQ@mail.gmail.com>
<e63675e1-d693-cd25-75b2-32b593e266a2@oracle.com>
<CAF9BGBz3g4yXMjf9TxrqLdMbfaswoa3U13qYTEUtv-mZCDMd8Q@mail.gmail.com>
<735b3949-d9cd-3d37-ebb4-f59ee61f18ad@oracle.com>
<ba26dc77-a5ba-b490-2a03-cf4abd79ac3c@oracle.com>
<ff9474cd-6f07-446c-12b5-2dafbca35ce3@oracle.com>
Message-ID: <56030d6f-4a5e-772b-cc83-b80ac65e4a78@oracle.com>
I'd like to support what Dan is saying.
The idea to split this renaming from the rest of the JEP was to avoid
re-basing
the fix constantly as it touches frequently updated area.
Another approach to avoid it would be to do members accessors renaming
after the JEP is pushed.
It would even simplify the whole process.
Thanks,
Serguei
On 4/18/18 06:29, Daniel D. Daugherty wrote:
> Greetings,
>
> The idea of splitting this change off from "8171119: Low-Overhead Heap
> Profiling"
> came up during the design review. It might have been me that suggested
> the split
> off or it was someone else. Sorry I don't remember.
>
> In any case, the rename of "end" to "fast_path_end" is just a clarity
> change to
> the existing code and I think that change can easily stand on its own.
> That is
> particularly true if the accessors are renamed at the same time. I
> think having
> the accessor names match the field names is a pretty well known
> HotSpot rule
> so I'm not sure why we're talking about not renaming the accessors...
>
> Personally, I prefer "_fast_path_end" over "_current_end".
>
> Dan
>
>
> On 4/18/18 4:04 AM, Stefan Johansson wrote:
>> Hi,
>>
>> On 2018-04-18 02:02, Vladimir Kozlov wrote:
>>> ?> I think I like better not to add it. If no one is using it, there
>>> should be
>>> ?> no reason to add it? By not adding it, it also makes any future
>>> wish to
>>> ?> have it a nice indicator of: hey why do you want to see this?
>>> Same as
>>> ?> hard_end btw which is not visible. Am I missing something?
>>>
>>> I say "may" ;)
>>> You don't need new function if there is no use.
>>>
>>> ?>
>>> ?> So to summarize, the current consensus:
>>> ?>??? - _end can be renamed either to _current_end or
>>> _fast_path_end; that is
>>> ?> still up to a vote and choice :)
>>>
>>> Please, use _current_end. I was thinking about _sample_end but it
>>> does not reflect double usage.
>>
>> I'm not sure if you have seen the discussion about naming on
>> hotspot-gc-dev, but I and others think that _current_end doesn't
>> describe the usage at all. Naming it _fast_path_end would clearly
>> state what it is, _sample_end or something similar also crossed my
>> mind but I think the code reads a lot better in the compiler with the
>> name fast_path_end.
>>
>>>
>>> ?>??? - the access method end() and tlab_end_offset() remain the
>>> same to not
>>> ?> modify JIT/interpreter codes
>> I would find this very unfortunate, having accessors that don't match
>> the members can easily lead to misunderstanding, especially if we
>> have three different *_end members. Why do you think this is the best
>> way forward?
>>
>> My first thought was also that it would be nice to avoid all the
>> compiler changes, but then we would have to stick with _end being the
>> sample/current/fast-path end and I'm not sure that is a better
>> solution. I don't see the big problem with changing those accessors
>> to what they really access and I think the compiler code reads good
>> even after the change. For example:
>> cmpptr(end, Address(thread, JavaThread::tlab_fast_path_end_offset()));
>> jcc(Assembler::above, slow_case);
>>
>>> ?>
>>> ?> If all agree to this, then the consequences are:
>>> ?>??? - JDK-8201326 becomes useless
>>> ?>??? - The work for JEP-331 becomes smaller in terms of file changes
>>> ?>??? - I'll still be needing a decision on the renaming of the TLAB
>>> _end field
>>> ?> (current suggestions are _current_end and _fast_path_end).
>>
>> We'll see where we end up. If JDK-8201326 ends up being a separate
>> change I think it should be pushed at the same time as the rest of
>> the JEP changes. To me it only makes sense to have it in the code
>> base if we also have the rest of the changes.
>>
>> Thanks,
>> Stefan
>>
>>>
>>> Sounds good to me.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 4/17/18 4:51 PM, JC Beyler wrote:
>>>> Hi Vladimir and Dean,
>>>>
>>>> @Dean: seems that Vladimir is in agreement with you for renaming
>>>> just the
>>>> field and not the method names so ack to your answer that came at
>>>> the same
>>>> time :)
>>>>
>>>>
>>>>> Yes, from the beginning such changes should be discussed on common
>>>>> hotspot-dev list since all
>>>>> Hotspot's parts are affected.
>>>>>
>>>>
>>>> Sorry, being new to the scene, most of the conversation had been
>>>> going on
>>>> in serviceability-dev.
>>>>
>>>>
>>>>>
>>>>> Graal specific question could be send to hotspot-compiler-dev list
>>>>> with
>>>>> [Graal] in subject.
>>>>>
>>>>> I looked on JEP's changes
>>>>> http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.02/ to
>>>>> understand how
>>>>> it works.
>>>>>
>>>>> Few questions about proposed JEP changes so I can understand it.
>>>>>
>>>>> You introducing new TLAB end for sampling and adjust it so that
>>>>> allocations in JITed code and
>>>>> Interpreter it will trigger slow path allocation where you do
>>>>> sampling.
>>>>> Right?
>>>>>
>>>>
>>>> Yes that is correct; if sampling is enabled of course. Btw, this is
>>>> the current
>>>> webrev <http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.15/>.
>>>>
>>>>
>>>>>
>>>>> Do all changes to _end, _actual_end and other TLAB fields happen
>>>>> during
>>>>> slow allocation?
>>>>>
>>>>
>>>> Yes, to that effect, with Robbin's help, we finalized deprecating the
>>>> FastTLabRefill via JDK-8194084
>>>> <https://bugs.openjdk.java.net/browse/JDK-8194084>. Seems like I/we
>>>> missed
>>>> that Graal does this as well. I filed GRAAL-64
>>>> <https://bugs.openjdk.java.net/browse/GRAAL-64> to not forget that
>>>> Graal
>>>> would need to get that fixed.
>>>>
>>>>
>>>>
>>>>>
>>>>> I am concern about concurrent accesses to these fields from other
>>>>> threads
>>>>> if you have them (I don't
>>>>> see).
>>>>>
>>>>
>>>> Yes that is why we deprecated the FastTlabRefill. Other threads
>>>> should not
>>>> be changing the thread local data structure so I don't see an issue
>>>> there.
>>>> The major issue was that the fast paths could change the tlab
>>>> without going
>>>> via the slowpath.
>>>>
>>>> I had a fix to detect this issue but removed it once JDK-8194084
>>>> was done;
>>>> Graal was missed in that work so that is why if sampling were
>>>> enabled with
>>>> Graal, there is a chance things would break currently. That will
>>>> get fixed
>>>> via GRAAL-64 <https://bugs.openjdk.java.net/browse/GRAAL-64>
>>>> whether it is
>>>> rendering the code also obsolete and going to the slowpath or
>>>> whether it is
>>>> adding my fix again to detect a fastpath TLAB reallocation happened.
>>>>
>>>>
>>>>>
>>>>> Renaming. I am fine with renaming if it helps to understand code
>>>>> better. I
>>>>> agree with proposed
>>>>> changes to fields name:
>>>>>
>>>>> _current_end
>>>>> _allocation_end
>>>>>
>>>>> But, as Dean, I would suggest to keep names of access functions.
>>>>> This way
>>>>> we can say that allocation
>>>>> code in Interpreter and JITed code stay the same.
>>>>>
>>>>
>>>> Sounds good to me, then in that case, this webrev will disappear,
>>>> which
>>>> also makes me happy, since it simplifies a lot of things (and
>>>> reduces code
>>>> change).
>>>>
>>>>
>>>>>
>>>>> You may need only new method to access _allocation_end in places
>>>>> which
>>>>> look for real end of TLAB.
>>>>>
>>>>
>>>> I think I like better not to add it. If no one is using it, there
>>>> should be
>>>> no reason to add it? By not adding it, it also makes any future
>>>> wish to
>>>> have it a nice indicator of: hey why do you want to see this? Same as
>>>> hard_end btw which is not visible. Am I missing something?
>>>>
>>>> So to summarize, the current consensus:
>>>> ?? - _end can be renamed either to _current_end or _fast_path_end;
>>>> that is
>>>> still up to a vote and choice :)
>>>> ?? - the access method end() and tlab_end_offset() remain the same
>>>> to not
>>>> modify JIT/interpreter codes
>>>>
>>>> If all agree to this, then the consequences are:
>>>> ?? - JDK-8201326 becomes useless
>>>> ?? - The work for JEP-331 becomes smaller in terms of file changes
>>>> ?? - I'll still be needing a decision on the renaming of the TLAB
>>>> _end field
>>>> (current suggestions are _current_end and _fast_path_end).
>>>>
>>>> Thanks for your help!
>>>> Jc
>>>>
>>>>
>>>>>
>>>>> Regards,
>>>>> Vladimir
>>>>>
>>>>> On 4/16/18 4:42 PM, JC Beyler wrote:
>>>>>> Hi Dean,
>>>>>>
>>>>>> I think perhaps this is also an attempt to figure out the naming
>>>>>> of all
>>>>>> this because naming (or renaming like here) is often the start of
>>>>>> big
>>>>>> conversations :).
>>>>>>
>>>>>> Originally, in the JEP-331 work, I had left the _end field as is
>>>>>> and, by
>>>>>> doing so, this whole renaming webrev goes away. However, if we do
>>>>>> that,
>>>>>> then the TLAB code contains:
>>>>>>
>>>>>> _end: the fast path end, can be the allocation end or the
>>>>>> to-be-sampled
>>>>> end
>>>>>> _allocation_end: the actual allocation end of the current TLAB
>>>>>> hard_end: _allocation_end + reserved space
>>>>>>
>>>>>> With an early iteration of a webrev for JEP-331, a conversation
>>>>>> occurred
>>>>>> about whether or not that was clear or not and it was determined
>>>>>> that
>>>>> this
>>>>>> renaming was more clear:
>>>>>>
>>>>>> _current_end: the fast path end
>>>>>> _allocation_end: the actual allocation end of the current TLAB
>>>>>> reserved_end: _allocation_end + reserved space
>>>>>>
>>>>>> Because I'm trying to reduce the footprint of files changed, I
>>>>>> pulled out
>>>>>> the renaming changes into this webrev. While talking about it
>>>>>> with the GC
>>>>>> team, the renaming suggested became:
>>>>>>
>>>>>> _fast_path_end: the fast path end
>>>>>> _allocation_end: the actual allocation end of the current TLAB
>>>>>> hard_end: _allocation_end + reserved space
>>>>>>
>>>>>> Now, to be honest, any renaming or no renaming is fine by me. I
>>>>>> like not
>>>>>> renaming the fields to not change the code of every backend and
>>>>>> Graal; I
>>>>>> also like the fast_path_end rename due to it making the backend
>>>>>> code easy
>>>>>> to read as mentioned in the GC mailing lis thread.
>>>>>>
>>>>>> So there are two questions really:
>>>>>> ???? - Should we rename the _end field and thus provoke the
>>>>>> changes in
>>>>> this
>>>>>> webrev?
>>>>>> ???? - If we do want to change the field, should/could it go in
>>>>>> an initial
>>>>>> webrev or should it go in the JEP-331 webrev whenever/ifever it
>>>>>> goes in?
>>>>>> And if we do wait, could we at least converge on a renaming now
>>>>>> so that
>>>>>> this does not become a point of contention for that webrev's review?
>>>>>>
>>>>>> If I read your answer correctly:
>>>>>> ?????? - You are saying that we should keep the _end field
>>>>>> altogether; or
>>>>> at
>>>>>> least only rename the field not the methods to access it, thus
>>>>>> reducing
>>>>> the
>>>>>> change scope.
>>>>>> ?????? - You are also saying to wait for the JEP-331 webrev's final
>>>>> iteration
>>>>>> and integrate it in one step
>>>>>>
>>>>>> Have I understood your answer correctly?
>>>>>>
>>>>>> Again, I am fine with renaming to whatever or not renaming at
>>>>>> all. I just
>>>>>> am trying to get forward progress here :)
>>>>>>
>>>>>> Thanks for your help!
>>>>>> Jc
>>>>>>
>>>>>> On Mon, Apr 16, 2018 at 3:29 PM <dean.long at oracle.com> wrote:
>>>>>>
>>>>>>> Hi JC.? Others might disagree, but I would vote "no" on doing this
>>>>>>> renaming now, before the JEP, and even in the context of the JEP, I
>>>>>>> don't think renaming the field requires renaming all the uses.? The
>>>>>>> compiler code is only interested in the fast path, so it's
>>>>>>> implicitly
>>>>>>> understood.? Also, if there is a fast_path_end(), then isn't it
>>>>>>> logical
>>>>>>> to have fast_path_start() paired with it?? ("start" is already
>>>>>>> overloaded, but nobody is suggesting adding
>>>>>>> allocation_start()/current_start()/hard_start() are they?).? My
>>>>>>> opinion
>>>>>>> is that it's fine the way it is.
>>>>>>>
>>>>>>> dl
>>>>>>>
>>>>>>> On 4/16/18 1:43 PM, JC Beyler wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I've left the mail thread from the hotspot-gc-dev below for
>>>>>>>> tracking
>>>>>>>> purposes but will start a new request here.
>>>>>>>>
>>>>>>>> - I'm trying to push a renaming of a TLAB field to make my work
>>>>>>>> for
>>>>>>> JEP-331
>>>>>>>> <http://openjdk.java.net/jeps/331> easier
>>>>>>>> ????? - There is an understanding that if JEP-331 does not make
>>>>>>>> it, this
>>>>>>> might
>>>>>>>> be useless and I'll revert if that is what the community wants;
>>>>>>>> however
>>>>>>> the
>>>>>>>> new name seems better anyway so perhaps not?
>>>>>>>>
>>>>>>>> - The webrev renames a field used across the various back-ends and
>>>>> Graal
>>>>>>>> ????? - The webrev is here:
>>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.04/
>>>>>>>>
>>>>>>>> Could I please get some feedback on this?
>>>>>>>>
>>>>>>>> Thanks all for your help,
>>>>>>>> Jc
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Apr 13, 2018 at 2:37 AM Stefan Johansson <
>>>>>>>> stefan.johansson at oracle.com> wrote:
>>>>>>>>
>>>>>>>>> Hi JC,
>>>>>>>>>
>>>>>>>>> I don't have a name, but I've looked at bit more at the
>>>>>>>>> failures and I
>>>>>>>>> think they are unrelated and one of the local compiler engineers
>>>>> agree.
>>>>>>>>>
>>>>>>>>> I also ran some local testing and was not able to get any
>>>>>>>>> error with
>>>>> you
>>>>>>>>> latest changes, but verified that it doens't work without the
>>>>>>>>> graal
>>>>>>>>> parts. So they seem good. It might still be good to switch
>>>>>>>>> this over
>>>>> to
>>>>>>>>> the general hotspot-dev list to let someone with Graal
>>>>>>>>> knowledge to
>>>>> look
>>>>>>>>> at the change and make sure everything is correct.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Stefan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2018-04-12 17:26, JC Beyler wrote:
>>>>>>>>>> Hi Stefan,
>>>>>>>>>>
>>>>>>>>>> Thanks for testing :). I've renamed the bug title in the JBS
>>>>>>>>>> and will
>>>>>>>>>> emit a new webrev shortly. Do you have the name of a compiler
>>>>> engineer
>>>>>>>>>> in mind or should I perhaps now move this conversation to the
>>>>>>>>>> general
>>>>>>>>>> hotspot-dev mailing list and ask there?
>>>>>>>>>>
>>>>>>>>>> The alternative is to add the compiler-mailing list to this
>>>>>>>>>> email
>>>>>>> thread
>>>>>>>>>> and ask there before sending to the general list. What do you
>>>>>>>>>> think
>>>>> is
>>>>>>>>> best?
>>>>>>>>>> Thanks for all your help,
>>>>>>>>>> Jc
>>>>>>>>>>
>>>>>>>>>> On Thu, Apr 12, 2018 at 2:09 AM Stefan Johansson
>>>>>>>>>> <stefan.johansson at oracle.com
>>>>>>>>>> <mailto:stefan.johansson at oracle.com>>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ?????? On 2018-04-11 17:48, JC Beyler wrote:
>>>>>>>>>> ??????? > Hi Stefan,
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? > Sorry about that, I must have missed adding the
>>>>>>>>>> files or
>>>>>>>>>> ?????? something. Here
>>>>>>>>>> ??????? > is a webrev that added the changes for the SA file:
>>>>>>>>>> ??????? >
>>>>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/
>>>>>>>>>> ??????? >
>>>>>>>>>> ?????? No problem, this looks good. I kicked of a run in our
>>>>>>>>>> test
>>>>> system
>>>>>>> to
>>>>>>>>>> ?????? get
>>>>>>>>>> ?????? some more coverage and have tried to include some Graal
>>>>> testing.
>>>>>>> I'll
>>>>>>>>>> ?????? let you know the results once they are done.
>>>>>>>>>>
>>>>>>>>>> ?????? Please also update the bug title both in JBS and the
>>>>>>>>>> changeset.
>>>>>>>>>>
>>>>>>>>>> ?????? Cheers,
>>>>>>>>>> ?????? Stefan
>>>>>>>>>>
>>>>>>>>>> ??????? > I changed the method name, which propagated a
>>>>>>>>>> change to:
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
>>>>>
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? > I tried testing your test file. It exists in my
>>>>>>>>>> branch (if
>>>>> the
>>>>>>>>>> ?????? same) under:
>>>>>>>>>> ??????? > hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? > and interestingly (which generally means I did
>>>>>>>>>> something
>>>>>>> wrong),
>>>>>>>>> it
>>>>>>>>>> ??????? > passed before/after the change so I could not
>>>>>>>>>> verify that
>>>>> this
>>>>>>> is
>>>>>>>>>> ?????? a test
>>>>>>>>>> ??????? > showing that all is well in the world on my side.
>>>>>>>>>> Any ideas
>>>>> of
>>>>>>>>>> ?????? what I
>>>>>>>>>> ??????? > did wrong?
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? > I did again test it for hotspot/jtreg/compiler/aot/
>>>>>>>>>> and
>>>>>>>>>> ??????? > hotspot/jtreg/serviceability/jvmti and it passes
>>>>>>>>>> those.
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? > Thanks for all your help,
>>>>>>>>>> ??????? > Jc
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? > On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson
>>>>>>>>>> ??????? > <stefan.johansson at oracle.com <mailto:
>>>>>>> stefan.johansson at oracle.com>
>>>>>>>>>> <mailto:stefan.johansson at oracle.com
>>>>>>>>>> <mailto:stefan.johansson at oracle.com>>> wrote:
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? >???? Hi JC,
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? >???? On 2018-04-11 00:56, JC Beyler wrote:
>>>>>>>>>> ??????? >????? > Small update:
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? > Here is the fixed webrev for the '{' that
>>>>>>>>>> were out of
>>>>>>>>>> ?????? alignment.
>>>>>>>>>> ??????? >???? This
>>>>>>>>>> ??????? >????? > passed release build JTREG
>>>>>>>>>> ?????? for hotspot/jtreg/compiler/jvmti (just
>>>>>>>>>> ??????? >???? to run
>>>>>>>>>> ??????? >????? > something as a smoke screen)
>>>>>>>>>> ?????? and hotspot/jtreg/compiler/aot/ (to
>>>>>>>>>> ??????? >???? test
>>>>>>>>>> ??????? >????? > Graal).
>>>>>>>>>> ??????? >????? >
>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >???? I think this looks better, I agree that leaving
>>>>>>>>>> _end is
>>>>>>>>>> ?????? tempting to
>>>>>>>>>> ??????? >???? avoid a lot of change, but I think this will be
>>>>>>>>>> better
>>>>> in
>>>>>>> the
>>>>>>>>>> ?????? long run.
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? >???? I still miss the changes to make the SA work.
>>>>>>>>>> To see a
>>>>>>>>>> ?????? problem you
>>>>>>>>>> ??????? >???? can run:
>>>>>>>>>> ??????? >???? make CONF=fast run-test
>>>>>>>>>> ??????? >
>>>>>>> TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? >???? Cheers,
>>>>>>>>>> ??????? >???? Stefan
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? >????? > Let me know what you think,
>>>>>>>>>> ??????? >????? > Jc
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler
>>>>>>>>>> ?????? <jcbeyler at google.com <mailto:jcbeyler at google.com>
>>>>>>>>>> ??????? >???? <mailto:jcbeyler at google.com
>>>>>>>>>> <mailto:jcbeyler at google.com
>>>>>>>
>>>>>>>>>> ??????? >????? > <mailto:jcbeyler at google.com <mailto:
>>>>> jcbeyler at google.com
>>>>>>>>
>>>>>>>>>> <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>>>
>>>>>>> wrote:
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? Hi Karen and Stefan,
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? @Stefan: Naming is hard :)
>>>>>>>>>> ??????? >????? >???? @Karen: thanks for the Graal comment, I
>>>>>>>>>> fixed it
>>>>> in
>>>>>>>>>> ?????? the new
>>>>>>>>>> ??????? >???? webrev,
>>>>>>>>>> ??????? >????? >???? let me know what you think :)
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? I think the naming convention suggested
>>>>>>>>>> in this
>>>>>>> webrev
>>>>>>>>>> ?????? came from
>>>>>>>>>> ??????? >????? >???? conversations in for JEP-331 and I am
>>>>>>>>>> actually
>>>>>>>>> relatively
>>>>>>>>>> ??????? >????? > indifferent to the final result (as long as we
>>>>> have
>>>>>>>>>> ?????? some form of
>>>>>>>>>> ??????? >????? >???? forward progress :)). To be honest, I'd
>>>>>>>>>> also be
>>>>>>> happy
>>>>>>>>>> ?????? to just
>>>>>>>>>> ??????? >???? leave
>>>>>>>>>> ??????? >????? >???? _end as is for all architectures and
>>>>>>>>>> Graal and
>>>>> have
>>>>>>> a
>>>>>>>>> new
>>>>>>>>>> ??????? >????? > _allocation_end. However, during initial
>>>>>>>>>> reviews
>>>>> of
>>>>>>>>>> ?????? JEP-331
>>>>>>>>>> ??????? >???? it was
>>>>>>>>>> ??????? >????? >???? deemed complicated to understand:
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? _end -> the _end or sampling end
>>>>>>>>>> ??????? >????? >???? _allocation_end -> end pointer for the last
>>>>> possible
>>>>>>>>>> ?????? allocation
>>>>>>>>>> ??????? >????? >???? hard_end -> allocation end + reserved space
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? That is how this naming came up and why
>>>>>>>>>> hard_end
>>>>>>> went
>>>>>>>>> to
>>>>>>>>>> ??????? > "reserved_end".
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? I'm really indifferent, so I offer as a
>>>>>>>>>> perusal:
>>>>>>>>>> ??????? >????? >
>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? I noticed a few problems of alignement
>>>>>>>>>> of '{' so
>>>>>>> I'll
>>>>>>>>>> ?????? go fix
>>>>>>>>>> ??????? >???? that.
>>>>>>>>>> ??????? >????? >???? Basically this webrev does the following:
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? - Uses fast_path_end instead of end
>>>>>>>>>> ??????? >????? >???? - Reverts hard_end back to where it was
>>>>>>>>>> ??????? >????? >???? - Adds the changes to Graal; there is a
>>>>>>>>>> bunch of
>>>>>>>>>> ?????? changes in Graal
>>>>>>>>>> ??????? >????? >???? because Graal still contains a bit of
>>>>>>>>>> code doing
>>>>>>>>>> ?????? fasttlabrefills.
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? Let me know what you think!
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? Thanks,
>>>>>>>>>> ??????? >????? >???? Jc
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? On Tue, Apr 10, 2018 at 6:56 AM Karen
>>>>>>>>>> Kinnear
>>>>>>>>>> ??????? >????? > <karen.kinnear at oracle.com
>>>>>>>>>> ?????? <mailto:karen.kinnear at oracle.com> <mailto:
>>>>>>> karen.kinnear at oracle.com
>>>>>>>>>> <mailto:karen.kinnear at oracle.com>>
>>>>>>>>>> ??????? > <mailto:karen.kinnear at oracle.com
>>>>>>>>>> ?????? <mailto:karen.kinnear at oracle.com> <mailto:
>>>>>>> karen.kinnear at oracle.com
>>>>>>>>>> <mailto:karen.kinnear at oracle.com>>>>
>>>>>>>>>> ??????? >???? wrote:
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???????? Hi JC,
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???????? A comment about Graal. The impact on
>>>>>>>>>> Graal
>>>>> for
>>>>>>> this
>>>>>>>>>> ??????? > particular
>>>>>>>>>> ??????? >????? >???????? change would be to break it - so
>>>>>>>>>> you?ll need
>>>>>>>>>> ??????? >????? >???????? to complete the Graal changes for this
>>>>> renaming.
>>>>>>>>>> ?????? That isn?t
>>>>>>>>>> ??????? >????? >???????? optional or something that could be a
>>>>>>> follow-on. It
>>>>>>>>>> ??????? > > is not ok to break a feature, even an
>>>>>>> experimental
>>>>>>>>>> ?????? one.
>>>>>>>>>> ??????? >???? We will
>>>>>>>>>> ??????? >????? >???????? discuss in the other thread potential
>>>>> phasing of
>>>>>>>>>> ?????? adding
>>>>>>>>>> ??????? >???? sampling.
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???????? I did not do a thorough search -you
>>>>>>>>>> can do
>>>>> that
>>>>>>> -
>>>>>>>>>> ?????? I did find
>>>>>>>>>> ??????? >????? > src/jdk.internal.vm.compiler/share/classes/
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>
>>>>>>>>>> ??????? > >??????????? public final int threadTlabOffset =
>>>>>>>>>> ??????? >????? > getFieldOffset("Thread::_tlab",
>>>>> Integer.class,
>>>>>>>>>> ??????? > > "ThreadLocalAllocBuffer");
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>
>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>> ?????? threadLocalAllocBufferStartOffset =
>>>>>>>>>> ??????? >????? >
>>>>> ? getFieldOffset("ThreadLocalAllocBuffer::_start",
>>>>>>>>>> ??????? > Integer.class,
>>>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>
>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>> threadLocalAllocBufferEndOffset =
>>>>>>>>>> ??????? >????? >
>>>>> ? getFieldOffset("ThreadLocalAllocBuffer::_end",
>>>>>>>>>> ?????? Integer.class,
>>>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>
>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>> threadLocalAllocBufferTopOffset =
>>>>>>>>>> ??????? >????? >
>>>>> ? getFieldOffset("ThreadLocalAllocBuffer::_top",
>>>>>>>>>> ?????? Integer.class,
>>>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>
>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>> ?????? threadLocalAllocBufferPfTopOffset =
>>>>>>>>>> ??????? >????? >
>>>>>>> ?? getFieldOffset("ThreadLocalAllocBuffer::_pf_top",
>>>>>>>>>> ??????? > Integer.class,
>>>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>
>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>> ??????? > threadLocalAllocBufferSlowAllocationsOffset
>>>>>>>>>> ??????? >????? >???????? =
>>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
>>>>>>>>>> ??????? >????? >???????? Integer.class, "unsigned");
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>
>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>> ??????? > threadLocalAllocBufferFastRefillWasteOffset
>>>>>>>>>> ??????? >????? >???????? =
>>>>>>>>>> ??????? >
>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
>>>>>>>>>> ??????? > > Integer.class, "unsigned");
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>
>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>> ??????? > threadLocalAllocBufferNumberOfRefillsOffset
>>>>>>>>>> ??????? >????? >???????? =
>>>>>>>>>> ??????? >
>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
>>>>>>>>>> ??????? > > Integer.class, "unsigned");
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>
>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>> ??????? >????? > threadLocalAllocBufferRefillWasteLimitOffset
>>>>> =
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
>>>>>>>>>> ??????? >????? >???????? Integer.class, "size_t");
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>
>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>> ??????? > threadLocalAllocBufferDesiredSizeOffset =
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
>>>>>>>>>> ??????? >????? >???????? Integer.class, "size_t");
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>
>>>>>>>>>> ??????? > >??????????? public final int tlabAlignmentReserve =
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
>>>>>
>>>>>>>>>> ??????? > > Integer.class, "size_t?);
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???????? hope this helps,
>>>>>>>>>> ??????? >????? >???????? Karen
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >>???????? On Apr 10, 2018, at 7:04 AM, Stefan
>>>>> Johansson
>>>>>>>>>> ??????? > >>???????? <stefan.johansson at oracle.com
>>>>>>>>>> <mailto:stefan.johansson at oracle.com>
>>>>>>>>>> ??????? > <mailto:stefan.johansson at oracle.com
>>>>>>>>>> <mailto:stefan.johansson at oracle.com>>
>>>>>>>>>> ??????? >????? >> <mailto:stefan.johansson at oracle.com
>>>>>>>>>> <mailto:stefan.johansson at oracle.com>
>>>>>>>>>> ??????? > <mailto:stefan.johansson at oracle.com
>>>>>>>>>> <mailto:stefan.johansson at oracle.com>>>> wrote:
>>>>>>>>>> ??????? >????? >>
>>>>>>>>>> ??????? >????? >>???????? Hi JC,
>>>>>>>>>> ??????? >????? >>
>>>>>>>>>> ??????? >????? >>???????? I realize that the names have been
>>>>>>>>>> discussed
>>>>>>>>>> ?????? before but I'm
>>>>>>>>>> ??????? >????? >>???????? leaning towards suggesting
>>>>>>>>>> something new. We
>>>>>>>>>> ?????? discussed this
>>>>>>>>>> ??????? >????? >>???????? briefly here in the office and
>>>>>>>>>> others might
>>>>>>> have
>>>>>>>>>> ?????? different
>>>>>>>>>> ??????? >????? >>???????? opinions. One point that came up is
>>>>>>>>>> that if
>>>>> we
>>>>>>> do
>>>>>>>>>> ?????? this
>>>>>>>>>> ??????? >???? change
>>>>>>>>>> ??????? >????? >>???????? and change all usages of
>>>>>>>>>> ?????? JavaThread::tlab_end_offset() it
>>>>>>>>>> ??????? >????? >>???????? would be good to make sure the new
>>>>>>>>>> name is
>>>>>>> good.
>>>>>>>>>> ?????? To us
>>>>>>>>>> ??????? >????? >>???????? _current_end is not very
>>>>>>>>>> descriptive, but
>>>>>>> naming
>>>>>>>>>> ?????? is hard and
>>>>>>>>>> ??????? >????? >>???????? the best we could come up with is
>>>>>>> _fast_path_end
>>>>>>>>>> ?????? which would
>>>>>>>>>> ??????? >????? >>???????? give the code:
>>>>>>>>>> ??????? >????? >>????????? cmpptr(end, Address(thread,
>>>>>>>>>> ??????? >????? >> JavaThread::tlab_fast_path_end_offset()));
>>>>>>>>>> ??????? >????? >> jcc(Assembler::above, slow_case);
>>>>>>>>>> ??????? >????? >>
>>>>>>>>>> ??????? >????? >>???????? I think this reads pretty good and
>>>>>>>>>> is fairly
>>>>>>>>>> ?????? clear. If we do
>>>>>>>>>> ??????? >????? >>???????? this rename I think you can re-use
>>>>>>>>>> _end in
>>>>>>> JEP-331
>>>>>>>>>> ??????? >???? instead of
>>>>>>>>>> ??????? >????? >>???????? calling it _allocation_end. But
>>>>>>>>>> that is a
>>>>> later
>>>>>>>>>> ?????? review :)
>>>>>>>>>> ??????? >????? >>
>>>>>>>>>> ??????? >????? >>???????? Also, is there a good reason for
>>>>>>>>>> renaming
>>>>>>>>>> ?????? hard_end() to
>>>>>>>>>> ??????? >????? >> reserved_end()?
>>>>>>>>>> ??????? >????? >>
>>>>>>>>>> ??????? >????? >>???????? One additional thing, you need to
>>>>>>>>>> update
>>>>> the SA
>>>>>>>>>> ?????? to reflect
>>>>>>>>>> ??????? >????? >>???????? this change. I think the only place
>>>>>>>>>> you
>>>>> need to
>>>>>>>>>> ?????? fix is in:
>>>>>>>>>> ??????? >????? >>
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
>>>>>
>>>>>>>>>> ??????? >????? >>
>>>>>>>>>> ??????? >????? >>???????? Thanks,
>>>>>>>>>> ??????? >????? >>???????? Stefan
>>>>>>>>>> ??????? >????? >>
>>>>>>>>>> ??????? >????? >>???????? On 2018-04-09 19:24, JC Beyler wrote:
>>>>>>>>>> ??????? >????? >>>???????? Hi all,
>>>>>>>>>> ??????? >????? >>>???????? Small pre-amble to this request:
>>>>>>>>>> ??????? >????? >>>???????? In my work to try to get a heap
>>>>>>>>>> sampler in
>>>>>>>>>> ?????? OpenJDK (via JEP
>>>>>>>>>> ??????? >????? >>>???????? 331
>>>>>>>>>> ??????? > <https://bugs.openjdk.java.net/browse/JDK-8171119>),
>>>>> I'm
>>>>>>>>>> ??????? > >>>???????? trying to reduce the footprint of my
>>>>> change so
>>>>>>>>>> ?????? that the
>>>>>>>>>> ??????? >????? >>> integration can be easier. I was told that
>>>>>>>>>> ?????? generally a JEP
>>>>>>>>>> ??????? >????? >>>???????? webrev should be feature complete
>>>>>>>>>> and go in
>>>>>>>>> at-once.
>>>>>>>>>> ??????? >???? However,
>>>>>>>>>> ??????? >????? >>>???????? with the change touching quite a
>>>>>>>>>> bit of
>>>>>>> various
>>>>>>>>> code
>>>>>>>>>> ??????? >???? pieces,
>>>>>>>>>> ??????? >????? >>>???????? I was trying to figure out what
>>>>>>>>>> could be
>>>>>>>>>> ?????? separated as not
>>>>>>>>>> ??????? >????? >>>???????? "part of the feature".
>>>>>>>>>> ??????? >????? >>>???????? I asked around and said that
>>>>>>>>>> perhaps a
>>>>>>> solution
>>>>>>>>>> ?????? would be to
>>>>>>>>>> ??????? >????? >>>???????? cut up the renaming of TLAB's end
>>>>>>>>>> field
>>>>> that I
>>>>>>>>>> ?????? do in that
>>>>>>>>>> ??????? >????? >>>???????? webrev. Because I'm renaming a
>>>>>>>>>> field in
>>>>> TLAB
>>>>>>>>> used by
>>>>>>>>>> ??????? >???? various
>>>>>>>>>> ??????? >????? >>>???????? backends for that work, I have to
>>>>>>>>>> update
>>>>> every
>>>>>>>>>> ?????? architecture
>>>>>>>>>> ??????? >????? >>>???????? dependent code to reflect it.
>>>>>>>>>> ??????? >????? >>>???????? I entirely understand that perhaps
>>>>>>>>>> this is
>>>>> not
>>>>>>>>>> ?????? in the
>>>>>>>>>> ??????? >???? habits
>>>>>>>>>> ??????? >????? >>>???????? and very potentially might not be
>>>>>>>>>> the way
>>>>>>> things
>>>>>>>>> are
>>>>>>>>>> ??????? > >>>???????? generally done. If so, I apologize and let
>>>>> me
>>>>>>>>>> ?????? know if you
>>>>>>>>>> ??????? >????? >>>???????? would not want this to go in
>>>>>>>>>> separately :)
>>>>>>>>>> ??????? >????? >>>???????? Final note: there is still a
>>>>>>>>>> chance JEP-331
>>>>>>> does
>>>>>>>>>> ?????? not go in.
>>>>>>>>>> ??????? >????? >>>???????? If it does not, we can leave the
>>>>>>>>>> new name
>>>>> in
>>>>>>>>>> ?????? place or I'll
>>>>>>>>>> ??????? >????? >>>???????? happily revert it. I can even
>>>>>>>>>> create an
>>>>> issue
>>>>>>> to
>>>>>>>>>> ?????? track this
>>>>>>>>>> ??????? >????? >>>???????? if that makes it easier for all.
>>>>>>>>>> ??????? >????? >>>???????? End of the pre-amble.
>>>>>>>>>> ??????? >????? >>>???????? The 33-line change webrev in
>>>>>>>>>> question is
>>>>> here:
>>>>>>>>>> ??????? > >>>
>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
>>>>>>>>>> ??????? > >>>???????? I fixed all the architectures and JVMCI
>>>>>>>>>> and
>>>>>>> ran
>>>>>>>>>> ?????? a few
>>>>>>>>>> ??????? >???? sanity
>>>>>>>>>> ??????? >????? >>>???????? tests to ensure I had not missed
>>>>>>>>>> anything.
>>>>>>>>>> ??????? >????? >>>???????? Thanks for your help and I hope
>>>>>>>>>> this is not
>>>>>>> too
>>>>>>>>> much
>>>>>>>>>> ??????? >???? trouble,
>>>>>>>>>> ??????? >????? >>>???????? Jc
>>>>>>>>>> ??????? >????? >>>???????? Ps: there is a graal change that
>>>>>>>>>> needs to
>>>>>>> happen
>>>>>>>>>> ?????? but I was
>>>>>>>>>> ??????? >????? >>>???????? not sure who/where
>>>>> <https://teams.googleplex.com/u/where>
>>>>>>> <https://teams.googleplex.com/u/where>
>>>>>>>>> <https://teams.googleplex.com/u/where>
>>>>>>>>>> <https://teams.googleplex.com/u/where>
>>>>>>>>>> ??????? > <https://teams.googleplex.com/u/where>
>>>>>>>>>> ??????? > <https://teams.googleplex.com/u/where> to
>>>>>>>>>> ??????? >????? >>>???????? ask about it. I was told it could
>>>>>>>>>> happen
>>>>> in a
>>>>>>>>>> ?????? separate
>>>>>>>>>> ??????? >????? >>>???????? webrev. Can anyone point me to the
>>>>>>>>>> right
>>>>>>>>> direction?
>>>>>>>>>> ??????? >???? Should it
>>>>>>>>>> ??????? >????? >>>???????? just be hotspot-compiler-dev?
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>
From vladimir.kozlov at oracle.com Wed Apr 18 18:02:12 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 18 Apr 2018 11:02:12 -0700
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
fast_path_end
In-Reply-To: <ff9474cd-6f07-446c-12b5-2dafbca35ce3@oracle.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
<CAF9BGBz-=JqbaJ37B5G35u3Ziei53fjhf=JMaWFd06WeZUCLfQ@mail.gmail.com>
<CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
<3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>
<CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>
<5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
<CAF9BGBxEPXLTiyD-xG_ECyveyW0PXQL0+-z7jkw3Rv4QrkkszQ@mail.gmail.com>
<ec1a3e0e-ca9b-8668-b260-1fd3e612b7f7@oracle.com>
<CAF9BGBy-LBKCwJHQPdAQ65VRcSFBwVkk9dm8MLC_nrefE_JdEw@mail.gmail.com>
<e6528c19-5691-1215-1ac5-0349801b79b5@oracle.com>
<CAF9BGBwBgyOoJTfJU_YmqYJgSZ+1985yx_sSMJC4wNJELw1XDQ@mail.gmail.com>
<e63675e1-d693-cd25-75b2-32b593e266a2@oracle.com>
<CAF9BGBz3g4yXMjf9TxrqLdMbfaswoa3U13qYTEUtv-mZCDMd8Q@mail.gmail.com>
<735b3949-d9cd-3d37-ebb4-f59ee61f18ad@oracle.com>
<ba26dc77-a5ba-b490-2a03-cf4abd79ac3c@oracle.com>
<ff9474cd-6f07-446c-12b5-2dafbca35ce3@oracle.com>
Message-ID: <19c34a75-e1f5-f1b2-2cd7-91300e7979c3@oracle.com>
Ganging up on us ;)
Yes, I missed original discussion about renaming on GC list.
From my point of view next code looks better because it seems compare related values:
cmpptr(end, Address(thread, JavaThread::tlab_end_offset()));
But I would not strongly object renaming to move this JEP forward. Consider changes reviewed and approved by me.
Regards,
Vladimir
On 4/18/18 6:29 AM, Daniel D. Daugherty wrote:
> Greetings,
>
> The idea of splitting this change off from "8171119: Low-Overhead Heap Profiling"
> came up during the design review. It might have been me that suggested the split
> off or it was someone else. Sorry I don't remember.
>
> In any case, the rename of "end" to "fast_path_end" is just a clarity change to
> the existing code and I think that change can easily stand on its own. That is
> particularly true if the accessors are renamed at the same time. I think having
> the accessor names match the field names is a pretty well known HotSpot rule
> so I'm not sure why we're talking about not renaming the accessors...
>
> Personally, I prefer "_fast_path_end" over "_current_end".
>
> Dan
>
>
> On 4/18/18 4:04 AM, Stefan Johansson wrote:
>> Hi,
>>
>> On 2018-04-18 02:02, Vladimir Kozlov wrote:
>>> ?> I think I like better not to add it. If no one is using it, there should be
>>> ?> no reason to add it? By not adding it, it also makes any future wish to
>>> ?> have it a nice indicator of: hey why do you want to see this? Same as
>>> ?> hard_end btw which is not visible. Am I missing something?
>>>
>>> I say "may" ;)
>>> You don't need new function if there is no use.
>>>
>>> ?>
>>> ?> So to summarize, the current consensus:
>>> ?>??? - _end can be renamed either to _current_end or _fast_path_end; that is
>>> ?> still up to a vote and choice :)
>>>
>>> Please, use _current_end. I was thinking about _sample_end but it does not reflect double usage.
>>
>> I'm not sure if you have seen the discussion about naming on hotspot-gc-dev, but I and others think that _current_end
>> doesn't describe the usage at all. Naming it _fast_path_end would clearly state what it is, _sample_end or something
>> similar also crossed my mind but I think the code reads a lot better in the compiler with the name fast_path_end.
>>
>>>
>>> ?>??? - the access method end() and tlab_end_offset() remain the same to not
>>> ?> modify JIT/interpreter codes
>> I would find this very unfortunate, having accessors that don't match the members can easily lead to misunderstanding,
>> especially if we have three different *_end members. Why do you think this is the best way forward?
>>
>> My first thought was also that it would be nice to avoid all the compiler changes, but then we would have to stick
>> with _end being the sample/current/fast-path end and I'm not sure that is a better solution. I don't see the big
>> problem with changing those accessors to what they really access and I think the compiler code reads good even after
>> the change. For example:
>> cmpptr(end, Address(thread, JavaThread::tlab_fast_path_end_offset()));
>> jcc(Assembler::above, slow_case);
>>
>>> ?>
>>> ?> If all agree to this, then the consequences are:
>>> ?>??? - JDK-8201326 becomes useless
>>> ?>??? - The work for JEP-331 becomes smaller in terms of file changes
>>> ?>??? - I'll still be needing a decision on the renaming of the TLAB _end field
>>> ?> (current suggestions are _current_end and _fast_path_end).
>>
>> We'll see where we end up. If JDK-8201326 ends up being a separate change I think it should be pushed at the same time
>> as the rest of the JEP changes. To me it only makes sense to have it in the code base if we also have the rest of the
>> changes.
>>
>> Thanks,
>> Stefan
>>
>>>
>>> Sounds good to me.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 4/17/18 4:51 PM, JC Beyler wrote:
>>>> Hi Vladimir and Dean,
>>>>
>>>> @Dean: seems that Vladimir is in agreement with you for renaming just the
>>>> field and not the method names so ack to your answer that came at the same
>>>> time :)
>>>>
>>>>
>>>>> Yes, from the beginning such changes should be discussed on common
>>>>> hotspot-dev list since all
>>>>> Hotspot's parts are affected.
>>>>>
>>>>
>>>> Sorry, being new to the scene, most of the conversation had been going on
>>>> in serviceability-dev.
>>>>
>>>>
>>>>>
>>>>> Graal specific question could be send to hotspot-compiler-dev list with
>>>>> [Graal] in subject.
>>>>>
>>>>> I looked on JEP's changes
>>>>> http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.02/ to understand how
>>>>> it works.
>>>>>
>>>>> Few questions about proposed JEP changes so I can understand it.
>>>>>
>>>>> You introducing new TLAB end for sampling and adjust it so that
>>>>> allocations in JITed code and
>>>>> Interpreter it will trigger slow path allocation where you do sampling.
>>>>> Right?
>>>>>
>>>>
>>>> Yes that is correct; if sampling is enabled of course. Btw, this is the current
>>>> webrev <http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.15/>.
>>>>
>>>>
>>>>>
>>>>> Do all changes to _end, _actual_end and other TLAB fields happen during
>>>>> slow allocation?
>>>>>
>>>>
>>>> Yes, to that effect, with Robbin's help, we finalized deprecating the
>>>> FastTLabRefill via JDK-8194084
>>>> <https://bugs.openjdk.java.net/browse/JDK-8194084>. Seems like I/we missed
>>>> that Graal does this as well. I filed GRAAL-64
>>>> <https://bugs.openjdk.java.net/browse/GRAAL-64> to not forget that Graal
>>>> would need to get that fixed.
>>>>
>>>>
>>>>
>>>>>
>>>>> I am concern about concurrent accesses to these fields from other threads
>>>>> if you have them (I don't
>>>>> see).
>>>>>
>>>>
>>>> Yes that is why we deprecated the FastTlabRefill. Other threads should not
>>>> be changing the thread local data structure so I don't see an issue there.
>>>> The major issue was that the fast paths could change the tlab without going
>>>> via the slowpath.
>>>>
>>>> I had a fix to detect this issue but removed it once JDK-8194084 was done;
>>>> Graal was missed in that work so that is why if sampling were enabled with
>>>> Graal, there is a chance things would break currently. That will get fixed
>>>> via GRAAL-64 <https://bugs.openjdk.java.net/browse/GRAAL-64> whether it is
>>>> rendering the code also obsolete and going to the slowpath or whether it is
>>>> adding my fix again to detect a fastpath TLAB reallocation happened.
>>>>
>>>>
>>>>>
>>>>> Renaming. I am fine with renaming if it helps to understand code better. I
>>>>> agree with proposed
>>>>> changes to fields name:
>>>>>
>>>>> _current_end
>>>>> _allocation_end
>>>>>
>>>>> But, as Dean, I would suggest to keep names of access functions. This way
>>>>> we can say that allocation
>>>>> code in Interpreter and JITed code stay the same.
>>>>>
>>>>
>>>> Sounds good to me, then in that case, this webrev will disappear, which
>>>> also makes me happy, since it simplifies a lot of things (and reduces code
>>>> change).
>>>>
>>>>
>>>>>
>>>>> You may need only new method to access _allocation_end in places which
>>>>> look for real end of TLAB.
>>>>>
>>>>
>>>> I think I like better not to add it. If no one is using it, there should be
>>>> no reason to add it? By not adding it, it also makes any future wish to
>>>> have it a nice indicator of: hey why do you want to see this? Same as
>>>> hard_end btw which is not visible. Am I missing something?
>>>>
>>>> So to summarize, the current consensus:
>>>> ?? - _end can be renamed either to _current_end or _fast_path_end; that is
>>>> still up to a vote and choice :)
>>>> ?? - the access method end() and tlab_end_offset() remain the same to not
>>>> modify JIT/interpreter codes
>>>>
>>>> If all agree to this, then the consequences are:
>>>> ?? - JDK-8201326 becomes useless
>>>> ?? - The work for JEP-331 becomes smaller in terms of file changes
>>>> ?? - I'll still be needing a decision on the renaming of the TLAB _end field
>>>> (current suggestions are _current_end and _fast_path_end).
>>>>
>>>> Thanks for your help!
>>>> Jc
>>>>
>>>>
>>>>>
>>>>> Regards,
>>>>> Vladimir
>>>>>
>>>>> On 4/16/18 4:42 PM, JC Beyler wrote:
>>>>>> Hi Dean,
>>>>>>
>>>>>> I think perhaps this is also an attempt to figure out the naming of all
>>>>>> this because naming (or renaming like here) is often the start of big
>>>>>> conversations :).
>>>>>>
>>>>>> Originally, in the JEP-331 work, I had left the _end field as is and, by
>>>>>> doing so, this whole renaming webrev goes away. However, if we do that,
>>>>>> then the TLAB code contains:
>>>>>>
>>>>>> _end: the fast path end, can be the allocation end or the to-be-sampled
>>>>> end
>>>>>> _allocation_end: the actual allocation end of the current TLAB
>>>>>> hard_end: _allocation_end + reserved space
>>>>>>
>>>>>> With an early iteration of a webrev for JEP-331, a conversation occurred
>>>>>> about whether or not that was clear or not and it was determined that
>>>>> this
>>>>>> renaming was more clear:
>>>>>>
>>>>>> _current_end: the fast path end
>>>>>> _allocation_end: the actual allocation end of the current TLAB
>>>>>> reserved_end: _allocation_end + reserved space
>>>>>>
>>>>>> Because I'm trying to reduce the footprint of files changed, I pulled out
>>>>>> the renaming changes into this webrev. While talking about it with the GC
>>>>>> team, the renaming suggested became:
>>>>>>
>>>>>> _fast_path_end: the fast path end
>>>>>> _allocation_end: the actual allocation end of the current TLAB
>>>>>> hard_end: _allocation_end + reserved space
>>>>>>
>>>>>> Now, to be honest, any renaming or no renaming is fine by me. I like not
>>>>>> renaming the fields to not change the code of every backend and Graal; I
>>>>>> also like the fast_path_end rename due to it making the backend code easy
>>>>>> to read as mentioned in the GC mailing lis thread.
>>>>>>
>>>>>> So there are two questions really:
>>>>>> ???? - Should we rename the _end field and thus provoke the changes in
>>>>> this
>>>>>> webrev?
>>>>>> ???? - If we do want to change the field, should/could it go in an initial
>>>>>> webrev or should it go in the JEP-331 webrev whenever/ifever it goes in?
>>>>>> And if we do wait, could we at least converge on a renaming now so that
>>>>>> this does not become a point of contention for that webrev's review?
>>>>>>
>>>>>> If I read your answer correctly:
>>>>>> ?????? - You are saying that we should keep the _end field altogether; or
>>>>> at
>>>>>> least only rename the field not the methods to access it, thus reducing
>>>>> the
>>>>>> change scope.
>>>>>> ?????? - You are also saying to wait for the JEP-331 webrev's final
>>>>> iteration
>>>>>> and integrate it in one step
>>>>>>
>>>>>> Have I understood your answer correctly?
>>>>>>
>>>>>> Again, I am fine with renaming to whatever or not renaming at all. I just
>>>>>> am trying to get forward progress here :)
>>>>>>
>>>>>> Thanks for your help!
>>>>>> Jc
>>>>>>
>>>>>> On Mon, Apr 16, 2018 at 3:29 PM <dean.long at oracle.com> wrote:
>>>>>>
>>>>>>> Hi JC.? Others might disagree, but I would vote "no" on doing this
>>>>>>> renaming now, before the JEP, and even in the context of the JEP, I
>>>>>>> don't think renaming the field requires renaming all the uses.? The
>>>>>>> compiler code is only interested in the fast path, so it's implicitly
>>>>>>> understood.? Also, if there is a fast_path_end(), then isn't it logical
>>>>>>> to have fast_path_start() paired with it?? ("start" is already
>>>>>>> overloaded, but nobody is suggesting adding
>>>>>>> allocation_start()/current_start()/hard_start() are they?).? My opinion
>>>>>>> is that it's fine the way it is.
>>>>>>>
>>>>>>> dl
>>>>>>>
>>>>>>> On 4/16/18 1:43 PM, JC Beyler wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I've left the mail thread from the hotspot-gc-dev below for tracking
>>>>>>>> purposes but will start a new request here.
>>>>>>>>
>>>>>>>> - I'm trying to push a renaming of a TLAB field to make my work for
>>>>>>> JEP-331
>>>>>>>> <http://openjdk.java.net/jeps/331> easier
>>>>>>>> ????? - There is an understanding that if JEP-331 does not make it, this
>>>>>>> might
>>>>>>>> be useless and I'll revert if that is what the community wants; however
>>>>>>> the
>>>>>>>> new name seems better anyway so perhaps not?
>>>>>>>>
>>>>>>>> - The webrev renames a field used across the various back-ends and
>>>>> Graal
>>>>>>>> ????? - The webrev is here:
>>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.04/
>>>>>>>>
>>>>>>>> Could I please get some feedback on this?
>>>>>>>>
>>>>>>>> Thanks all for your help,
>>>>>>>> Jc
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Apr 13, 2018 at 2:37 AM Stefan Johansson <
>>>>>>>> stefan.johansson at oracle.com> wrote:
>>>>>>>>
>>>>>>>>> Hi JC,
>>>>>>>>>
>>>>>>>>> I don't have a name, but I've looked at bit more at the failures and I
>>>>>>>>> think they are unrelated and one of the local compiler engineers
>>>>> agree.
>>>>>>>>>
>>>>>>>>> I also ran some local testing and was not able to get any error with
>>>>> you
>>>>>>>>> latest changes, but verified that it doens't work without the graal
>>>>>>>>> parts. So they seem good. It might still be good to switch this over
>>>>> to
>>>>>>>>> the general hotspot-dev list to let someone with Graal knowledge to
>>>>> look
>>>>>>>>> at the change and make sure everything is correct.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Stefan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2018-04-12 17:26, JC Beyler wrote:
>>>>>>>>>> Hi Stefan,
>>>>>>>>>>
>>>>>>>>>> Thanks for testing :). I've renamed the bug title in the JBS and will
>>>>>>>>>> emit a new webrev shortly. Do you have the name of a compiler
>>>>> engineer
>>>>>>>>>> in mind or should I perhaps now move this conversation to the general
>>>>>>>>>> hotspot-dev mailing list and ask there?
>>>>>>>>>>
>>>>>>>>>> The alternative is to add the compiler-mailing list to this email
>>>>>>> thread
>>>>>>>>>> and ask there before sending to the general list. What do you think
>>>>> is
>>>>>>>>> best?
>>>>>>>>>> Thanks for all your help,
>>>>>>>>>> Jc
>>>>>>>>>>
>>>>>>>>>> On Thu, Apr 12, 2018 at 2:09 AM Stefan Johansson
>>>>>>>>>> <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ?????? On 2018-04-11 17:48, JC Beyler wrote:
>>>>>>>>>> ??????? > Hi Stefan,
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? > Sorry about that, I must have missed adding the files or
>>>>>>>>>> ?????? something. Here
>>>>>>>>>> ??????? > is a webrev that added the changes for the SA file:
>>>>>>>>>> ??????? > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/
>>>>>>>>>> ??????? >
>>>>>>>>>> ?????? No problem, this looks good. I kicked of a run in our test
>>>>> system
>>>>>>> to
>>>>>>>>>> ?????? get
>>>>>>>>>> ?????? some more coverage and have tried to include some Graal
>>>>> testing.
>>>>>>> I'll
>>>>>>>>>> ?????? let you know the results once they are done.
>>>>>>>>>>
>>>>>>>>>> ?????? Please also update the bug title both in JBS and the changeset.
>>>>>>>>>>
>>>>>>>>>> ?????? Cheers,
>>>>>>>>>> ?????? Stefan
>>>>>>>>>>
>>>>>>>>>> ??????? > I changed the method name, which propagated a change to:
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? > I tried testing your test file. It exists in my branch (if
>>>>> the
>>>>>>>>>> ?????? same) under:
>>>>>>>>>> ??????? > hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? > and interestingly (which generally means I did something
>>>>>>> wrong),
>>>>>>>>> it
>>>>>>>>>> ??????? > passed before/after the change so I could not verify that
>>>>> this
>>>>>>> is
>>>>>>>>>> ?????? a test
>>>>>>>>>> ??????? > showing that all is well in the world on my side. Any ideas
>>>>> of
>>>>>>>>>> ?????? what I
>>>>>>>>>> ??????? > did wrong?
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? > I did again test it for hotspot/jtreg/compiler/aot/ and
>>>>>>>>>> ??????? > hotspot/jtreg/serviceability/jvmti and it passes those.
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? > Thanks for all your help,
>>>>>>>>>> ??????? > Jc
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? > On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson
>>>>>>>>>> ??????? > <stefan.johansson at oracle.com <mailto:
>>>>>>> stefan.johansson at oracle.com>
>>>>>>>>>> <mailto:stefan.johansson at oracle.com
>>>>>>>>>> <mailto:stefan.johansson at oracle.com>>> wrote:
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? >???? Hi JC,
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? >???? On 2018-04-11 00:56, JC Beyler wrote:
>>>>>>>>>> ??????? >????? > Small update:
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? > Here is the fixed webrev for the '{' that were out of
>>>>>>>>>> ?????? alignment.
>>>>>>>>>> ??????? >???? This
>>>>>>>>>> ??????? >????? > passed release build JTREG
>>>>>>>>>> ?????? for hotspot/jtreg/compiler/jvmti (just
>>>>>>>>>> ??????? >???? to run
>>>>>>>>>> ??????? >????? > something as a smoke screen)
>>>>>>>>>> ?????? and hotspot/jtreg/compiler/aot/ (to
>>>>>>>>>> ??????? >???? test
>>>>>>>>>> ??????? >????? > Graal).
>>>>>>>>>> ??????? >????? >
>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >???? I think this looks better, I agree that leaving _end is
>>>>>>>>>> ?????? tempting to
>>>>>>>>>> ??????? >???? avoid a lot of change, but I think this will be better
>>>>> in
>>>>>>> the
>>>>>>>>>> ?????? long run.
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? >???? I still miss the changes to make the SA work. To see a
>>>>>>>>>> ?????? problem you
>>>>>>>>>> ??????? >???? can run:
>>>>>>>>>> ??????? >???? make CONF=fast run-test
>>>>>>>>>> ??????? >
>>>>>>> TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? >???? Cheers,
>>>>>>>>>> ??????? >???? Stefan
>>>>>>>>>> ??????? >
>>>>>>>>>> ??????? >????? > Let me know what you think,
>>>>>>>>>> ??????? >????? > Jc
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler
>>>>>>>>>> ?????? <jcbeyler at google.com <mailto:jcbeyler at google.com>
>>>>>>>>>> ??????? >???? <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com
>>>>>>>
>>>>>>>>>> ??????? >????? > <mailto:jcbeyler at google.com <mailto:
>>>>> jcbeyler at google.com
>>>>>>>>
>>>>>>>>>> <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>>>
>>>>>>> wrote:
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? Hi Karen and Stefan,
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? @Stefan: Naming is hard :)
>>>>>>>>>> ??????? >????? >???? @Karen: thanks for the Graal comment, I fixed it
>>>>> in
>>>>>>>>>> ?????? the new
>>>>>>>>>> ??????? >???? webrev,
>>>>>>>>>> ??????? >????? >???? let me know what you think :)
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? I think the naming convention suggested in this
>>>>>>> webrev
>>>>>>>>>> ?????? came from
>>>>>>>>>> ??????? >????? >???? conversations in for JEP-331 and I am actually
>>>>>>>>> relatively
>>>>>>>>>> ??????? >????? > indifferent to the final result (as long as we
>>>>> have
>>>>>>>>>> ?????? some form of
>>>>>>>>>> ??????? >????? >???? forward progress :)). To be honest, I'd also be
>>>>>>> happy
>>>>>>>>>> ?????? to just
>>>>>>>>>> ??????? >???? leave
>>>>>>>>>> ??????? >????? >???? _end as is for all architectures and Graal and
>>>>> have
>>>>>>> a
>>>>>>>>> new
>>>>>>>>>> ??????? >????? > _allocation_end. However, during initial reviews
>>>>> of
>>>>>>>>>> ?????? JEP-331
>>>>>>>>>> ??????? >???? it was
>>>>>>>>>> ??????? >????? >???? deemed complicated to understand:
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? _end -> the _end or sampling end
>>>>>>>>>> ??????? >????? >???? _allocation_end -> end pointer for the last
>>>>> possible
>>>>>>>>>> ?????? allocation
>>>>>>>>>> ??????? >????? >???? hard_end -> allocation end + reserved space
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? That is how this naming came up and why hard_end
>>>>>>> went
>>>>>>>>> to
>>>>>>>>>> ??????? > "reserved_end".
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? I'm really indifferent, so I offer as a perusal:
>>>>>>>>>> ??????? >????? >
>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? I noticed a few problems of alignement of '{' so
>>>>>>> I'll
>>>>>>>>>> ?????? go fix
>>>>>>>>>> ??????? >???? that.
>>>>>>>>>> ??????? >????? >???? Basically this webrev does the following:
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? - Uses fast_path_end instead of end
>>>>>>>>>> ??????? >????? >???? - Reverts hard_end back to where it was
>>>>>>>>>> ??????? >????? >???? - Adds the changes to Graal; there is a bunch of
>>>>>>>>>> ?????? changes in Graal
>>>>>>>>>> ??????? >????? >???? because Graal still contains a bit of code doing
>>>>>>>>>> ?????? fasttlabrefills.
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? Let me know what you think!
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? Thanks,
>>>>>>>>>> ??????? >????? >???? Jc
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???? On Tue, Apr 10, 2018 at 6:56 AM Karen Kinnear
>>>>>>>>>> ??????? >????? > <karen.kinnear at oracle.com
>>>>>>>>>> ?????? <mailto:karen.kinnear at oracle.com> <mailto:
>>>>>>> karen.kinnear at oracle.com
>>>>>>>>>> <mailto:karen.kinnear at oracle.com>>
>>>>>>>>>> ??????? > <mailto:karen.kinnear at oracle.com
>>>>>>>>>> ?????? <mailto:karen.kinnear at oracle.com> <mailto:
>>>>>>> karen.kinnear at oracle.com
>>>>>>>>>> <mailto:karen.kinnear at oracle.com>>>>
>>>>>>>>>> ??????? >???? wrote:
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???????? Hi JC,
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???????? A comment about Graal. The impact on Graal
>>>>> for
>>>>>>> this
>>>>>>>>>> ??????? >???? particular
>>>>>>>>>> ??????? >????? >???????? change would be to break it - so you?ll need
>>>>>>>>>> ??????? >????? >???????? to complete the Graal changes for this
>>>>> renaming.
>>>>>>>>>> ?????? That isn?t
>>>>>>>>>> ??????? >????? >???????? optional or something that could be a
>>>>>>> follow-on. It
>>>>>>>>>> ??????? > >???????? is not ok to break a feature, even an
>>>>>>> experimental
>>>>>>>>>> ?????? one.
>>>>>>>>>> ??????? >???? We will
>>>>>>>>>> ??????? >????? >???????? discuss in the other thread potential
>>>>> phasing of
>>>>>>>>>> ?????? adding
>>>>>>>>>> ??????? >???? sampling.
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???????? I did not do a thorough search -you can do
>>>>> that
>>>>>>> -
>>>>>>>>>> ?????? I did find
>>>>>>>>>> ??????? >????? > src/jdk.internal.vm.compiler/share/classes/
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>> ??????? > >??????????? public final int threadTlabOffset =
>>>>>>>>>> ??????? >????? > getFieldOffset("Thread::_tlab",
>>>>> Integer.class,
>>>>>>>>>> ??????? > >???????? "ThreadLocalAllocBuffer");
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>> ?????? threadLocalAllocBufferStartOffset =
>>>>>>>>>> ??????? >????? >
>>>>> ? getFieldOffset("ThreadLocalAllocBuffer::_start",
>>>>>>>>>> ??????? > Integer.class,
>>>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>> threadLocalAllocBufferEndOffset =
>>>>>>>>>> ??????? >????? >
>>>>> ? getFieldOffset("ThreadLocalAllocBuffer::_end",
>>>>>>>>>> ?????? Integer.class,
>>>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>> threadLocalAllocBufferTopOffset =
>>>>>>>>>> ??????? >????? >
>>>>> ? getFieldOffset("ThreadLocalAllocBuffer::_top",
>>>>>>>>>> ?????? Integer.class,
>>>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>> ?????? threadLocalAllocBufferPfTopOffset =
>>>>>>>>>> ??????? >????? >
>>>>>>> ?? getFieldOffset("ThreadLocalAllocBuffer::_pf_top",
>>>>>>>>>> ??????? > Integer.class,
>>>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>> ??????? > threadLocalAllocBufferSlowAllocationsOffset
>>>>>>>>>> ??????? >????? >???????? =
>>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
>>>>>>>>>> ??????? >????? >???????? Integer.class, "unsigned");
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>> ??????? > threadLocalAllocBufferFastRefillWasteOffset
>>>>>>>>>> ??????? >????? >???????? =
>>>>>>>>>> ??????? >
>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
>>>>>>>>>> ??????? > >???????? Integer.class, "unsigned");
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>> ??????? > threadLocalAllocBufferNumberOfRefillsOffset
>>>>>>>>>> ??????? >????? >???????? =
>>>>>>>>>> ??????? >
>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
>>>>>>>>>> ??????? > >???????? Integer.class, "unsigned");
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>> ??????? >????? > threadLocalAllocBufferRefillWasteLimitOffset
>>>>> =
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
>>>>>>>>>> ??????? >????? >???????? Integer.class, "size_t");
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>> ??????? > threadLocalAllocBufferDesiredSizeOffset =
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
>>>>>>>>>> ??????? >????? >???????? Integer.class, "size_t");
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>> ??????? > >??????????? public final int tlabAlignmentReserve =
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
>>>>>>>>>> ??????? > >???????? Integer.class, "size_t?);
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >???????? hope this helps,
>>>>>>>>>> ??????? >????? >???????? Karen
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >????? >>???????? On Apr 10, 2018, at 7:04 AM, Stefan
>>>>> Johansson
>>>>>>>>>> ??????? > >>???????? <stefan.johansson at oracle.com
>>>>>>>>>> ?????? <mailto:stefan.johansson at oracle.com>
>>>>>>>>>> ??????? > <mailto:stefan.johansson at oracle.com
>>>>>>>>>> <mailto:stefan.johansson at oracle.com>>
>>>>>>>>>> ??????? >????? >> <mailto:stefan.johansson at oracle.com
>>>>>>>>>> ?????? <mailto:stefan.johansson at oracle.com>
>>>>>>>>>> ??????? > <mailto:stefan.johansson at oracle.com
>>>>>>>>>> <mailto:stefan.johansson at oracle.com>>>> wrote:
>>>>>>>>>> ??????? >????? >>
>>>>>>>>>> ??????? >????? >>???????? Hi JC,
>>>>>>>>>> ??????? >????? >>
>>>>>>>>>> ??????? >????? >>???????? I realize that the names have been discussed
>>>>>>>>>> ?????? before but I'm
>>>>>>>>>> ??????? >????? >>???????? leaning towards suggesting something new. We
>>>>>>>>>> ?????? discussed this
>>>>>>>>>> ??????? >????? >>???????? briefly here in the office and others might
>>>>>>> have
>>>>>>>>>> ?????? different
>>>>>>>>>> ??????? >????? >>???????? opinions. One point that came up is that if
>>>>> we
>>>>>>> do
>>>>>>>>>> ?????? this
>>>>>>>>>> ??????? >???? change
>>>>>>>>>> ??????? >????? >>???????? and change all usages of
>>>>>>>>>> ?????? JavaThread::tlab_end_offset() it
>>>>>>>>>> ??????? >????? >>???????? would be good to make sure the new name is
>>>>>>> good.
>>>>>>>>>> ?????? To us
>>>>>>>>>> ??????? >????? >>???????? _current_end is not very descriptive, but
>>>>>>> naming
>>>>>>>>>> ?????? is hard and
>>>>>>>>>> ??????? >????? >>???????? the best we could come up with is
>>>>>>> _fast_path_end
>>>>>>>>>> ?????? which would
>>>>>>>>>> ??????? >????? >>???????? give the code:
>>>>>>>>>> ??????? >????? >>????????? cmpptr(end, Address(thread,
>>>>>>>>>> ??????? >????? >> JavaThread::tlab_fast_path_end_offset()));
>>>>>>>>>> ??????? >????? >> jcc(Assembler::above, slow_case);
>>>>>>>>>> ??????? >????? >>
>>>>>>>>>> ??????? >????? >>???????? I think this reads pretty good and is fairly
>>>>>>>>>> ?????? clear. If we do
>>>>>>>>>> ??????? >????? >>???????? this rename I think you can re-use _end in
>>>>>>> JEP-331
>>>>>>>>>> ??????? >???? instead of
>>>>>>>>>> ??????? >????? >>???????? calling it _allocation_end. But that is a
>>>>> later
>>>>>>>>>> ?????? review :)
>>>>>>>>>> ??????? >????? >>
>>>>>>>>>> ??????? >????? >>???????? Also, is there a good reason for renaming
>>>>>>>>>> ?????? hard_end() to
>>>>>>>>>> ??????? >????? >>???????? reserved_end()?
>>>>>>>>>> ??????? >????? >>
>>>>>>>>>> ??????? >????? >>???????? One additional thing, you need to update
>>>>> the SA
>>>>>>>>>> ?????? to reflect
>>>>>>>>>> ??????? >????? >>???????? this change. I think the only place you
>>>>> need to
>>>>>>>>>> ?????? fix is in:
>>>>>>>>>> ??????? >????? >>
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
>>>>>>>>>> ??????? >????? >>
>>>>>>>>>> ??????? >????? >>???????? Thanks,
>>>>>>>>>> ??????? >????? >>???????? Stefan
>>>>>>>>>> ??????? >????? >>
>>>>>>>>>> ??????? >????? >>???????? On 2018-04-09 19:24, JC Beyler wrote:
>>>>>>>>>> ??????? >????? >>>???????? Hi all,
>>>>>>>>>> ??????? >????? >>>???????? Small pre-amble to this request:
>>>>>>>>>> ??????? >????? >>>???????? In my work to try to get a heap sampler in
>>>>>>>>>> ?????? OpenJDK (via JEP
>>>>>>>>>> ??????? >????? >>>???????? 331
>>>>>>>>>> ??????? > <https://bugs.openjdk.java.net/browse/JDK-8171119>),
>>>>> I'm
>>>>>>>>>> ??????? > >>>???????? trying to reduce the footprint of my
>>>>> change so
>>>>>>>>>> ?????? that the
>>>>>>>>>> ??????? >????? >>>???????? integration can be easier. I was told that
>>>>>>>>>> ?????? generally a JEP
>>>>>>>>>> ??????? >????? >>>???????? webrev should be feature complete and go in
>>>>>>>>> at-once.
>>>>>>>>>> ??????? >???? However,
>>>>>>>>>> ??????? >????? >>>???????? with the change touching quite a bit of
>>>>>>> various
>>>>>>>>> code
>>>>>>>>>> ??????? >???? pieces,
>>>>>>>>>> ??????? >????? >>>???????? I was trying to figure out what could be
>>>>>>>>>> ?????? separated as not
>>>>>>>>>> ??????? >????? >>>???????? "part of the feature".
>>>>>>>>>> ??????? >????? >>>???????? I asked around and said that perhaps a
>>>>>>> solution
>>>>>>>>>> ?????? would be to
>>>>>>>>>> ??????? >????? >>>???????? cut up the renaming of TLAB's end field
>>>>> that I
>>>>>>>>>> ?????? do in that
>>>>>>>>>> ??????? >????? >>>???????? webrev. Because I'm renaming a field in
>>>>> TLAB
>>>>>>>>> used by
>>>>>>>>>> ??????? >???? various
>>>>>>>>>> ??????? >????? >>>???????? backends for that work, I have to update
>>>>> every
>>>>>>>>>> ?????? architecture
>>>>>>>>>> ??????? >????? >>>???????? dependent code to reflect it.
>>>>>>>>>> ??????? >????? >>>???????? I entirely understand that perhaps this is
>>>>> not
>>>>>>>>>> ?????? in the
>>>>>>>>>> ??????? >???? habits
>>>>>>>>>> ??????? >????? >>>???????? and very potentially might not be the way
>>>>>>> things
>>>>>>>>> are
>>>>>>>>>> ??????? > >>>???????? generally done. If so, I apologize and let
>>>>> me
>>>>>>>>>> ?????? know if you
>>>>>>>>>> ??????? >????? >>>???????? would not want this to go in separately :)
>>>>>>>>>> ??????? >????? >>>???????? Final note: there is still a chance JEP-331
>>>>>>> does
>>>>>>>>>> ?????? not go in.
>>>>>>>>>> ??????? >????? >>>???????? If it does not, we can leave the new name
>>>>> in
>>>>>>>>>> ?????? place or I'll
>>>>>>>>>> ??????? >????? >>>???????? happily revert it. I can even create an
>>>>> issue
>>>>>>> to
>>>>>>>>>> ?????? track this
>>>>>>>>>> ??????? >????? >>>???????? if that makes it easier for all.
>>>>>>>>>> ??????? >????? >>>???????? End of the pre-amble.
>>>>>>>>>> ??????? >????? >>>???????? The 33-line change webrev in question is
>>>>> here:
>>>>>>>>>> ??????? > >>>
>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
>>>>>>>>>> ??????? > >>>???????? I fixed all the architectures and JVMCI and
>>>>>>> ran
>>>>>>>>>> ?????? a few
>>>>>>>>>> ??????? >???? sanity
>>>>>>>>>> ??????? >????? >>>???????? tests to ensure I had not missed anything.
>>>>>>>>>> ??????? >????? >>>???????? Thanks for your help and I hope this is not
>>>>>>> too
>>>>>>>>> much
>>>>>>>>>> ??????? >???? trouble,
>>>>>>>>>> ??????? >????? >>>???????? Jc
>>>>>>>>>> ??????? >????? >>>???????? Ps: there is a graal change that needs to
>>>>>>> happen
>>>>>>>>>> ?????? but I was
>>>>>>>>>> ??????? >????? >>>???????? not sure who/where
>>>>> <https://teams.googleplex.com/u/where>
>>>>>>> <https://teams.googleplex.com/u/where>
>>>>>>>>> <https://teams.googleplex.com/u/where>
>>>>>>>>>> <https://teams.googleplex.com/u/where>
>>>>>>>>>> ??????? > <https://teams.googleplex.com/u/where>
>>>>>>>>>> ??????? > <https://teams.googleplex.com/u/where> to
>>>>>>>>>> ??????? >????? >>>???????? ask about it. I was told it could happen
>>>>> in a
>>>>>>>>>> ?????? separate
>>>>>>>>>> ??????? >????? >>>???????? webrev. Can anyone point me to the right
>>>>>>>>> direction?
>>>>>>>>>> ??????? >???? Should it
>>>>>>>>>> ??????? >????? >>>???????? just be hotspot-compiler-dev?
>>>>>>>>>> ??????? >????? >
>>>>>>>>>> ??????? >
>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>
From dean.long at oracle.com Wed Apr 18 19:15:52 2018
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Wed, 18 Apr 2018 12:15:52 -0700
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
fast_path_end
In-Reply-To: <19c34a75-e1f5-f1b2-2cd7-91300e7979c3@oracle.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
<CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
<3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>
<CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>
<5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
<CAF9BGBxEPXLTiyD-xG_ECyveyW0PXQL0+-z7jkw3Rv4QrkkszQ@mail.gmail.com>
<ec1a3e0e-ca9b-8668-b260-1fd3e612b7f7@oracle.com>
<CAF9BGBy-LBKCwJHQPdAQ65VRcSFBwVkk9dm8MLC_nrefE_JdEw@mail.gmail.com>
<e6528c19-5691-1215-1ac5-0349801b79b5@oracle.com>
<CAF9BGBwBgyOoJTfJU_YmqYJgSZ+1985yx_sSMJC4wNJELw1XDQ@mail.gmail.com>
<e63675e1-d693-cd25-75b2-32b593e266a2@oracle.com>
<CAF9BGBz3g4yXMjf9TxrqLdMbfaswoa3U13qYTEUtv-mZCDMd8Q@mail.gmail.com>
<735b3949-d9cd-3d37-ebb4-f59ee61f18ad@oracle.com>
<ba26dc77-a5ba-b490-2a03-cf4abd79ac3c@oracle.com>
<ff9474cd-6f07-446c-12b5-2dafbca35ce3@oracle.com>
<19c34a75-e1f5-f1b2-2cd7-91300e7979c3@oracle.com>
Message-ID: <30260bf8-765b-3227-87c0-85f001ca4c55@oracle.com>
I will defer to Vladimir, but I would have been happy with something like:
// preserve simple start/end abstraction for compiler
HeapWord* end() const ? ? ?? { return fast_path_end(); }
static ByteSize end_offset() { return fast_path_end_offset(); }
even though end_offset() would then refer to a virtual "end" field.
Vladimir, are you also approving the Graal changes? :-)
dl
On 4/18/18 11:02 AM, Vladimir Kozlov wrote:
> Ganging up on us ;)
>
> Yes, I missed original discussion about renaming on GC list.
>
> From my point of view next code looks better because it seems compare
> related values:
>
> cmpptr(end, Address(thread, JavaThread::tlab_end_offset()));
>
> But I would not strongly object renaming to move this JEP forward.
> Consider changes reviewed and approved by me.
>
> Regards,
> Vladimir
>
> On 4/18/18 6:29 AM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> The idea of splitting this change off from "8171119: Low-Overhead
>> Heap Profiling"
>> came up during the design review. It might have been me that
>> suggested the split
>> off or it was someone else. Sorry I don't remember.
>>
>> In any case, the rename of "end" to "fast_path_end" is just a clarity
>> change to
>> the existing code and I think that change can easily stand on its
>> own. That is
>> particularly true if the accessors are renamed at the same time. I
>> think having
>> the accessor names match the field names is a pretty well known
>> HotSpot rule
>> so I'm not sure why we're talking about not renaming the accessors...
>>
>> Personally, I prefer "_fast_path_end" over "_current_end".
>>
>> Dan
>>
>>
>> On 4/18/18 4:04 AM, Stefan Johansson wrote:
>>> Hi,
>>>
>>> On 2018-04-18 02:02, Vladimir Kozlov wrote:
>>>> ?> I think I like better not to add it. If no one is using it,
>>>> there should be
>>>> ?> no reason to add it? By not adding it, it also makes any future
>>>> wish to
>>>> ?> have it a nice indicator of: hey why do you want to see this?
>>>> Same as
>>>> ?> hard_end btw which is not visible. Am I missing something?
>>>>
>>>> I say "may" ;)
>>>> You don't need new function if there is no use.
>>>>
>>>> ?>
>>>> ?> So to summarize, the current consensus:
>>>> ?>??? - _end can be renamed either to _current_end or
>>>> _fast_path_end; that is
>>>> ?> still up to a vote and choice :)
>>>>
>>>> Please, use _current_end. I was thinking about _sample_end but it
>>>> does not reflect double usage.
>>>
>>> I'm not sure if you have seen the discussion about naming on
>>> hotspot-gc-dev, but I and others think that _current_end doesn't
>>> describe the usage at all. Naming it _fast_path_end would clearly
>>> state what it is, _sample_end or something similar also crossed my
>>> mind but I think the code reads a lot better in the compiler with
>>> the name fast_path_end.
>>>
>>>>
>>>> ?>??? - the access method end() and tlab_end_offset() remain the
>>>> same to not
>>>> ?> modify JIT/interpreter codes
>>> I would find this very unfortunate, having accessors that don't
>>> match the members can easily lead to misunderstanding, especially if
>>> we have three different *_end members. Why do you think this is the
>>> best way forward?
>>>
>>> My first thought was also that it would be nice to avoid all the
>>> compiler changes, but then we would have to stick with _end being
>>> the sample/current/fast-path end and I'm not sure that is a better
>>> solution. I don't see the big problem with changing those accessors
>>> to what they really access and I think the compiler code reads good
>>> even after the change. For example:
>>> cmpptr(end, Address(thread, JavaThread::tlab_fast_path_end_offset()));
>>> jcc(Assembler::above, slow_case);
>>>
>>>> ?>
>>>> ?> If all agree to this, then the consequences are:
>>>> ?>??? - JDK-8201326 becomes useless
>>>> ?>??? - The work for JEP-331 becomes smaller in terms of file changes
>>>> ?>??? - I'll still be needing a decision on the renaming of the
>>>> TLAB _end field
>>>> ?> (current suggestions are _current_end and _fast_path_end).
>>>
>>> We'll see where we end up. If JDK-8201326 ends up being a separate
>>> change I think it should be pushed at the same time as the rest of
>>> the JEP changes. To me it only makes sense to have it in the code
>>> base if we also have the rest of the changes.
>>>
>>> Thanks,
>>> Stefan
>>>
>>>>
>>>> Sounds good to me.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 4/17/18 4:51 PM, JC Beyler wrote:
>>>>> Hi Vladimir and Dean,
>>>>>
>>>>> @Dean: seems that Vladimir is in agreement with you for renaming
>>>>> just the
>>>>> field and not the method names so ack to your answer that came at
>>>>> the same
>>>>> time :)
>>>>>
>>>>>
>>>>>> Yes, from the beginning such changes should be discussed on common
>>>>>> hotspot-dev list since all
>>>>>> Hotspot's parts are affected.
>>>>>>
>>>>>
>>>>> Sorry, being new to the scene, most of the conversation had been
>>>>> going on
>>>>> in serviceability-dev.
>>>>>
>>>>>
>>>>>>
>>>>>> Graal specific question could be send to hotspot-compiler-dev
>>>>>> list with
>>>>>> [Graal] in subject.
>>>>>>
>>>>>> I looked on JEP's changes
>>>>>> http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.02/ to
>>>>>> understand how
>>>>>> it works.
>>>>>>
>>>>>> Few questions about proposed JEP changes so I can understand it.
>>>>>>
>>>>>> You introducing new TLAB end for sampling and adjust it so that
>>>>>> allocations in JITed code and
>>>>>> Interpreter it will trigger slow path allocation where you do
>>>>>> sampling.
>>>>>> Right?
>>>>>>
>>>>>
>>>>> Yes that is correct; if sampling is enabled of course. Btw, this
>>>>> is the current
>>>>> webrev <http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.15/>.
>>>>>
>>>>>
>>>>>>
>>>>>> Do all changes to _end, _actual_end and other TLAB fields happen
>>>>>> during
>>>>>> slow allocation?
>>>>>>
>>>>>
>>>>> Yes, to that effect, with Robbin's help, we finalized deprecating the
>>>>> FastTLabRefill via JDK-8194084
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8194084>. Seems like
>>>>> I/we missed
>>>>> that Graal does this as well. I filed GRAAL-64
>>>>> <https://bugs.openjdk.java.net/browse/GRAAL-64> to not forget that
>>>>> Graal
>>>>> would need to get that fixed.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> I am concern about concurrent accesses to these fields from other
>>>>>> threads
>>>>>> if you have them (I don't
>>>>>> see).
>>>>>>
>>>>>
>>>>> Yes that is why we deprecated the FastTlabRefill. Other threads
>>>>> should not
>>>>> be changing the thread local data structure so I don't see an
>>>>> issue there.
>>>>> The major issue was that the fast paths could change the tlab
>>>>> without going
>>>>> via the slowpath.
>>>>>
>>>>> I had a fix to detect this issue but removed it once JDK-8194084
>>>>> was done;
>>>>> Graal was missed in that work so that is why if sampling were
>>>>> enabled with
>>>>> Graal, there is a chance things would break currently. That will
>>>>> get fixed
>>>>> via GRAAL-64 <https://bugs.openjdk.java.net/browse/GRAAL-64>
>>>>> whether it is
>>>>> rendering the code also obsolete and going to the slowpath or
>>>>> whether it is
>>>>> adding my fix again to detect a fastpath TLAB reallocation happened.
>>>>>
>>>>>
>>>>>>
>>>>>> Renaming. I am fine with renaming if it helps to understand code
>>>>>> better. I
>>>>>> agree with proposed
>>>>>> changes to fields name:
>>>>>>
>>>>>> _current_end
>>>>>> _allocation_end
>>>>>>
>>>>>> But, as Dean, I would suggest to keep names of access functions.
>>>>>> This way
>>>>>> we can say that allocation
>>>>>> code in Interpreter and JITed code stay the same.
>>>>>>
>>>>>
>>>>> Sounds good to me, then in that case, this webrev will disappear,
>>>>> which
>>>>> also makes me happy, since it simplifies a lot of things (and
>>>>> reduces code
>>>>> change).
>>>>>
>>>>>
>>>>>>
>>>>>> You may need only new method to access _allocation_end in places
>>>>>> which
>>>>>> look for real end of TLAB.
>>>>>>
>>>>>
>>>>> I think I like better not to add it. If no one is using it, there
>>>>> should be
>>>>> no reason to add it? By not adding it, it also makes any future
>>>>> wish to
>>>>> have it a nice indicator of: hey why do you want to see this? Same as
>>>>> hard_end btw which is not visible. Am I missing something?
>>>>>
>>>>> So to summarize, the current consensus:
>>>>> ?? - _end can be renamed either to _current_end or _fast_path_end;
>>>>> that is
>>>>> still up to a vote and choice :)
>>>>> ?? - the access method end() and tlab_end_offset() remain the same
>>>>> to not
>>>>> modify JIT/interpreter codes
>>>>>
>>>>> If all agree to this, then the consequences are:
>>>>> ?? - JDK-8201326 becomes useless
>>>>> ?? - The work for JEP-331 becomes smaller in terms of file changes
>>>>> ?? - I'll still be needing a decision on the renaming of the TLAB
>>>>> _end field
>>>>> (current suggestions are _current_end and _fast_path_end).
>>>>>
>>>>> Thanks for your help!
>>>>> Jc
>>>>>
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Vladimir
>>>>>>
>>>>>> On 4/16/18 4:42 PM, JC Beyler wrote:
>>>>>>> Hi Dean,
>>>>>>>
>>>>>>> I think perhaps this is also an attempt to figure out the naming
>>>>>>> of all
>>>>>>> this because naming (or renaming like here) is often the start
>>>>>>> of big
>>>>>>> conversations :).
>>>>>>>
>>>>>>> Originally, in the JEP-331 work, I had left the _end field as is
>>>>>>> and, by
>>>>>>> doing so, this whole renaming webrev goes away. However, if we
>>>>>>> do that,
>>>>>>> then the TLAB code contains:
>>>>>>>
>>>>>>> _end: the fast path end, can be the allocation end or the
>>>>>>> to-be-sampled
>>>>>> end
>>>>>>> _allocation_end: the actual allocation end of the current TLAB
>>>>>>> hard_end: _allocation_end + reserved space
>>>>>>>
>>>>>>> With an early iteration of a webrev for JEP-331, a conversation
>>>>>>> occurred
>>>>>>> about whether or not that was clear or not and it was determined
>>>>>>> that
>>>>>> this
>>>>>>> renaming was more clear:
>>>>>>>
>>>>>>> _current_end: the fast path end
>>>>>>> _allocation_end: the actual allocation end of the current TLAB
>>>>>>> reserved_end: _allocation_end + reserved space
>>>>>>>
>>>>>>> Because I'm trying to reduce the footprint of files changed, I
>>>>>>> pulled out
>>>>>>> the renaming changes into this webrev. While talking about it
>>>>>>> with the GC
>>>>>>> team, the renaming suggested became:
>>>>>>>
>>>>>>> _fast_path_end: the fast path end
>>>>>>> _allocation_end: the actual allocation end of the current TLAB
>>>>>>> hard_end: _allocation_end + reserved space
>>>>>>>
>>>>>>> Now, to be honest, any renaming or no renaming is fine by me. I
>>>>>>> like not
>>>>>>> renaming the fields to not change the code of every backend and
>>>>>>> Graal; I
>>>>>>> also like the fast_path_end rename due to it making the backend
>>>>>>> code easy
>>>>>>> to read as mentioned in the GC mailing lis thread.
>>>>>>>
>>>>>>> So there are two questions really:
>>>>>>> ???? - Should we rename the _end field and thus provoke the
>>>>>>> changes in
>>>>>> this
>>>>>>> webrev?
>>>>>>> ???? - If we do want to change the field, should/could it go in
>>>>>>> an initial
>>>>>>> webrev or should it go in the JEP-331 webrev whenever/ifever it
>>>>>>> goes in?
>>>>>>> And if we do wait, could we at least converge on a renaming now
>>>>>>> so that
>>>>>>> this does not become a point of contention for that webrev's
>>>>>>> review?
>>>>>>>
>>>>>>> If I read your answer correctly:
>>>>>>> ?????? - You are saying that we should keep the _end field
>>>>>>> altogether; or
>>>>>> at
>>>>>>> least only rename the field not the methods to access it, thus
>>>>>>> reducing
>>>>>> the
>>>>>>> change scope.
>>>>>>> ?????? - You are also saying to wait for the JEP-331 webrev's final
>>>>>> iteration
>>>>>>> and integrate it in one step
>>>>>>>
>>>>>>> Have I understood your answer correctly?
>>>>>>>
>>>>>>> Again, I am fine with renaming to whatever or not renaming at
>>>>>>> all. I just
>>>>>>> am trying to get forward progress here :)
>>>>>>>
>>>>>>> Thanks for your help!
>>>>>>> Jc
>>>>>>>
>>>>>>> On Mon, Apr 16, 2018 at 3:29 PM <dean.long at oracle.com> wrote:
>>>>>>>
>>>>>>>> Hi JC.? Others might disagree, but I would vote "no" on doing this
>>>>>>>> renaming now, before the JEP, and even in the context of the
>>>>>>>> JEP, I
>>>>>>>> don't think renaming the field requires renaming all the uses.?
>>>>>>>> The
>>>>>>>> compiler code is only interested in the fast path, so it's
>>>>>>>> implicitly
>>>>>>>> understood.? Also, if there is a fast_path_end(), then isn't it
>>>>>>>> logical
>>>>>>>> to have fast_path_start() paired with it?? ("start" is already
>>>>>>>> overloaded, but nobody is suggesting adding
>>>>>>>> allocation_start()/current_start()/hard_start() are they?).? My
>>>>>>>> opinion
>>>>>>>> is that it's fine the way it is.
>>>>>>>>
>>>>>>>> dl
>>>>>>>>
>>>>>>>> On 4/16/18 1:43 PM, JC Beyler wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I've left the mail thread from the hotspot-gc-dev below for
>>>>>>>>> tracking
>>>>>>>>> purposes but will start a new request here.
>>>>>>>>>
>>>>>>>>> - I'm trying to push a renaming of a TLAB field to make my
>>>>>>>>> work for
>>>>>>>> JEP-331
>>>>>>>>> <http://openjdk.java.net/jeps/331> easier
>>>>>>>>> ????? - There is an understanding that if JEP-331 does not
>>>>>>>>> make it, this
>>>>>>>> might
>>>>>>>>> be useless and I'll revert if that is what the community
>>>>>>>>> wants; however
>>>>>>>> the
>>>>>>>>> new name seems better anyway so perhaps not?
>>>>>>>>>
>>>>>>>>> - The webrev renames a field used across the various back-ends
>>>>>>>>> and
>>>>>> Graal
>>>>>>>>> ????? - The webrev is here:
>>>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.04/
>>>>>>>>>
>>>>>>>>> Could I please get some feedback on this?
>>>>>>>>>
>>>>>>>>> Thanks all for your help,
>>>>>>>>> Jc
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Apr 13, 2018 at 2:37 AM Stefan Johansson <
>>>>>>>>> stefan.johansson at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi JC,
>>>>>>>>>>
>>>>>>>>>> I don't have a name, but I've looked at bit more at the
>>>>>>>>>> failures and I
>>>>>>>>>> think they are unrelated and one of the local compiler engineers
>>>>>> agree.
>>>>>>>>>>
>>>>>>>>>> I also ran some local testing and was not able to get any
>>>>>>>>>> error with
>>>>>> you
>>>>>>>>>> latest changes, but verified that it doens't work without the
>>>>>>>>>> graal
>>>>>>>>>> parts. So they seem good. It might still be good to switch
>>>>>>>>>> this over
>>>>>> to
>>>>>>>>>> the general hotspot-dev list to let someone with Graal
>>>>>>>>>> knowledge to
>>>>>> look
>>>>>>>>>> at the change and make sure everything is correct.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Stefan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2018-04-12 17:26, JC Beyler wrote:
>>>>>>>>>>> Hi Stefan,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for testing :). I've renamed the bug title in the JBS
>>>>>>>>>>> and will
>>>>>>>>>>> emit a new webrev shortly. Do you have the name of a compiler
>>>>>> engineer
>>>>>>>>>>> in mind or should I perhaps now move this conversation to
>>>>>>>>>>> the general
>>>>>>>>>>> hotspot-dev mailing list and ask there?
>>>>>>>>>>>
>>>>>>>>>>> The alternative is to add the compiler-mailing list to this
>>>>>>>>>>> email
>>>>>>>> thread
>>>>>>>>>>> and ask there before sending to the general list. What do
>>>>>>>>>>> you think
>>>>>> is
>>>>>>>>>> best?
>>>>>>>>>>> Thanks for all your help,
>>>>>>>>>>> Jc
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Apr 12, 2018 at 2:09 AM Stefan Johansson
>>>>>>>>>>> <stefan.johansson at oracle.com
>>>>>>>>>>> <mailto:stefan.johansson at oracle.com>>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ?????? On 2018-04-11 17:48, JC Beyler wrote:
>>>>>>>>>>> ??????? > Hi Stefan,
>>>>>>>>>>> ??????? >
>>>>>>>>>>> ??????? > Sorry about that, I must have missed adding the
>>>>>>>>>>> files or
>>>>>>>>>>> ?????? something. Here
>>>>>>>>>>> ??????? > is a webrev that added the changes for the SA file:
>>>>>>>>>>> ??????? >
>>>>>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/
>>>>>>>>>>> ??????? >
>>>>>>>>>>> ?????? No problem, this looks good. I kicked of a run in our
>>>>>>>>>>> test
>>>>>> system
>>>>>>>> to
>>>>>>>>>>> ?????? get
>>>>>>>>>>> ?????? some more coverage and have tried to include some Graal
>>>>>> testing.
>>>>>>>> I'll
>>>>>>>>>>> ?????? let you know the results once they are done.
>>>>>>>>>>>
>>>>>>>>>>> ?????? Please also update the bug title both in JBS and the
>>>>>>>>>>> changeset.
>>>>>>>>>>>
>>>>>>>>>>> ?????? Cheers,
>>>>>>>>>>> ?????? Stefan
>>>>>>>>>>>
>>>>>>>>>>> ??????? > I changed the method name, which propagated a
>>>>>>>>>>> change to:
>>>>>>>>>>> ??????? >
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
>>>>>>
>>>>>>>>>>> ??????? >
>>>>>>>>>>> ??????? > I tried testing your test file. It exists in my
>>>>>>>>>>> branch (if
>>>>>> the
>>>>>>>>>>> ?????? same) under:
>>>>>>>>>>> ??????? > hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
>>>>>>>>>>> ??????? >
>>>>>>>>>>> ??????? > and interestingly (which generally means I did
>>>>>>>>>>> something
>>>>>>>> wrong),
>>>>>>>>>> it
>>>>>>>>>>> ??????? > passed before/after the change so I could not
>>>>>>>>>>> verify that
>>>>>> this
>>>>>>>> is
>>>>>>>>>>> ?????? a test
>>>>>>>>>>> ??????? > showing that all is well in the world on my side.
>>>>>>>>>>> Any ideas
>>>>>> of
>>>>>>>>>>> ?????? what I
>>>>>>>>>>> ??????? > did wrong?
>>>>>>>>>>> ??????? >
>>>>>>>>>>> ??????? > I did again test it for
>>>>>>>>>>> hotspot/jtreg/compiler/aot/ and
>>>>>>>>>>> ??????? > hotspot/jtreg/serviceability/jvmti and it passes
>>>>>>>>>>> those.
>>>>>>>>>>> ??????? >
>>>>>>>>>>> ??????? > Thanks for all your help,
>>>>>>>>>>> ??????? > Jc
>>>>>>>>>>> ??????? >
>>>>>>>>>>> ??????? >
>>>>>>>>>>> ??????? >
>>>>>>>>>>> ??????? > On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson
>>>>>>>>>>> ??????? > <stefan.johansson at oracle.com <mailto:
>>>>>>>> stefan.johansson at oracle.com>
>>>>>>>>>>> <mailto:stefan.johansson at oracle.com
>>>>>>>>>>> <mailto:stefan.johansson at oracle.com>>> wrote:
>>>>>>>>>>> ??????? >
>>>>>>>>>>> ??????? >???? Hi JC,
>>>>>>>>>>> ??????? >
>>>>>>>>>>> ??????? >???? On 2018-04-11 00:56, JC Beyler wrote:
>>>>>>>>>>> ??????? >????? > Small update:
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >????? > Here is the fixed webrev for the '{' that
>>>>>>>>>>> were out of
>>>>>>>>>>> ?????? alignment.
>>>>>>>>>>> ??????? >???? This
>>>>>>>>>>> ??????? >????? > passed release build JTREG
>>>>>>>>>>> ?????? for hotspot/jtreg/compiler/jvmti (just
>>>>>>>>>>> ??????? >???? to run
>>>>>>>>>>> ??????? >????? > something as a smoke screen)
>>>>>>>>>>> ?????? and hotspot/jtreg/compiler/aot/ (to
>>>>>>>>>>> ??????? >???? test
>>>>>>>>>>> ??????? >????? > Graal).
>>>>>>>>>>> ??????? >????? >
>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >???? I think this looks better, I agree that
>>>>>>>>>>> leaving _end is
>>>>>>>>>>> ?????? tempting to
>>>>>>>>>>> ??????? >???? avoid a lot of change, but I think this will
>>>>>>>>>>> be better
>>>>>> in
>>>>>>>> the
>>>>>>>>>>> ?????? long run.
>>>>>>>>>>> ??????? >
>>>>>>>>>>> ??????? >???? I still miss the changes to make the SA work.
>>>>>>>>>>> To see a
>>>>>>>>>>> ?????? problem you
>>>>>>>>>>> ??????? >???? can run:
>>>>>>>>>>> ??????? >???? make CONF=fast run-test
>>>>>>>>>>> ??????? >
>>>>>>>> TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
>>>>>>>>>>> ??????? >
>>>>>>>>>>> ??????? >???? Cheers,
>>>>>>>>>>> ??????? >???? Stefan
>>>>>>>>>>> ??????? >
>>>>>>>>>>> ??????? >????? > Let me know what you think,
>>>>>>>>>>> ??????? >????? > Jc
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >????? > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler
>>>>>>>>>>> ?????? <jcbeyler at google.com <mailto:jcbeyler at google.com>
>>>>>>>>>>> ??????? > <mailto:jcbeyler at google.com
>>>>>>>>>>> <mailto:jcbeyler at google.com
>>>>>>>>
>>>>>>>>>>> ??????? >????? > <mailto:jcbeyler at google.com <mailto:
>>>>>> jcbeyler at google.com
>>>>>>>>>
>>>>>>>>>>> <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>>>
>>>>>>>> wrote:
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >????? >???? Hi Karen and Stefan,
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >????? >???? @Stefan: Naming is hard :)
>>>>>>>>>>> ??????? >????? >???? @Karen: thanks for the Graal comment, I
>>>>>>>>>>> fixed it
>>>>>> in
>>>>>>>>>>> ?????? the new
>>>>>>>>>>> ??????? >???? webrev,
>>>>>>>>>>> ??????? >????? >???? let me know what you think :)
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >????? >???? I think the naming convention suggested
>>>>>>>>>>> in this
>>>>>>>> webrev
>>>>>>>>>>> ?????? came from
>>>>>>>>>>> ??????? >????? >???? conversations in for JEP-331 and I am
>>>>>>>>>>> actually
>>>>>>>>>> relatively
>>>>>>>>>>> ??????? >????? > indifferent to the final result (as long as we
>>>>>> have
>>>>>>>>>>> ?????? some form of
>>>>>>>>>>> ??????? >????? >???? forward progress :)). To be honest, I'd
>>>>>>>>>>> also be
>>>>>>>> happy
>>>>>>>>>>> ?????? to just
>>>>>>>>>>> ??????? >???? leave
>>>>>>>>>>> ??????? >????? >???? _end as is for all architectures and
>>>>>>>>>>> Graal and
>>>>>> have
>>>>>>>> a
>>>>>>>>>> new
>>>>>>>>>>> ??????? >????? > _allocation_end. However, during initial
>>>>>>>>>>> reviews
>>>>>> of
>>>>>>>>>>> ?????? JEP-331
>>>>>>>>>>> ??????? >???? it was
>>>>>>>>>>> ??????? >????? >???? deemed complicated to understand:
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >????? >???? _end -> the _end or sampling end
>>>>>>>>>>> ??????? >????? >???? _allocation_end -> end pointer for the
>>>>>>>>>>> last
>>>>>> possible
>>>>>>>>>>> ?????? allocation
>>>>>>>>>>> ??????? >????? >???? hard_end -> allocation end + reserved
>>>>>>>>>>> space
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >????? >???? That is how this naming came up and why
>>>>>>>>>>> hard_end
>>>>>>>> went
>>>>>>>>>> to
>>>>>>>>>>> ??????? > "reserved_end".
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >????? >???? I'm really indifferent, so I offer as a
>>>>>>>>>>> perusal:
>>>>>>>>>>> ??????? >????? >
>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >????? >???? I noticed a few problems of alignement
>>>>>>>>>>> of '{' so
>>>>>>>> I'll
>>>>>>>>>>> ?????? go fix
>>>>>>>>>>> ??????? >???? that.
>>>>>>>>>>> ??????? >????? >???? Basically this webrev does the following:
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >????? >???? - Uses fast_path_end instead of end
>>>>>>>>>>> ??????? >????? >???? - Reverts hard_end back to where it was
>>>>>>>>>>> ??????? >????? >???? - Adds the changes to Graal; there is a
>>>>>>>>>>> bunch of
>>>>>>>>>>> ?????? changes in Graal
>>>>>>>>>>> ??????? >????? >???? because Graal still contains a bit of
>>>>>>>>>>> code doing
>>>>>>>>>>> ?????? fasttlabrefills.
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >????? >???? Let me know what you think!
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >????? >???? Thanks,
>>>>>>>>>>> ??????? >????? >???? Jc
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >????? >???? On Tue, Apr 10, 2018 at 6:56 AM Karen
>>>>>>>>>>> Kinnear
>>>>>>>>>>> ??????? >????? > <karen.kinnear at oracle.com
>>>>>>>>>>> ?????? <mailto:karen.kinnear at oracle.com> <mailto:
>>>>>>>> karen.kinnear at oracle.com
>>>>>>>>>>> <mailto:karen.kinnear at oracle.com>>
>>>>>>>>>>> ??????? > <mailto:karen.kinnear at oracle.com
>>>>>>>>>>> ?????? <mailto:karen.kinnear at oracle.com> <mailto:
>>>>>>>> karen.kinnear at oracle.com
>>>>>>>>>>> <mailto:karen.kinnear at oracle.com>>>>
>>>>>>>>>>> ??????? >???? wrote:
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >????? >???????? Hi JC,
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >????? >???????? A comment about Graal. The impact
>>>>>>>>>>> on Graal
>>>>>> for
>>>>>>>> this
>>>>>>>>>>> ??????? > particular
>>>>>>>>>>> ??????? >????? >???????? change would be to break it - so
>>>>>>>>>>> you?ll need
>>>>>>>>>>> ??????? >????? >???????? to complete the Graal changes for this
>>>>>> renaming.
>>>>>>>>>>> ?????? That isn?t
>>>>>>>>>>> ??????? >????? >???????? optional or something that could be a
>>>>>>>> follow-on. It
>>>>>>>>>>> ??????? > >???????? is not ok to break a feature, even an
>>>>>>>> experimental
>>>>>>>>>>> ?????? one.
>>>>>>>>>>> ??????? >???? We will
>>>>>>>>>>> ??????? >????? >???????? discuss in the other thread potential
>>>>>> phasing of
>>>>>>>>>>> ?????? adding
>>>>>>>>>>> ??????? >???? sampling.
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >????? >???????? I did not do a thorough search -you
>>>>>>>>>>> can do
>>>>>> that
>>>>>>>> -
>>>>>>>>>>> ?????? I did find
>>>>>>>>>>> ??????? >????? > src/jdk.internal.vm.compiler/share/classes/
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>
>>>>>>>>>>> ??????? > >??????????? public final int threadTlabOffset =
>>>>>>>>>>> ??????? >????? > getFieldOffset("Thread::_tlab",
>>>>>> Integer.class,
>>>>>>>>>>> ??????? > >???????? "ThreadLocalAllocBuffer");
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>
>>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>>> ?????? threadLocalAllocBufferStartOffset =
>>>>>>>>>>> ??????? >????? >
>>>>>> ? getFieldOffset("ThreadLocalAllocBuffer::_start",
>>>>>>>>>>> ??????? > Integer.class,
>>>>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>
>>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>> threadLocalAllocBufferEndOffset =
>>>>>>>>>>> ??????? >????? >
>>>>>> ? getFieldOffset("ThreadLocalAllocBuffer::_end",
>>>>>>>>>>> ?????? Integer.class,
>>>>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>
>>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>> threadLocalAllocBufferTopOffset =
>>>>>>>>>>> ??????? >????? >
>>>>>> ? getFieldOffset("ThreadLocalAllocBuffer::_top",
>>>>>>>>>>> ?????? Integer.class,
>>>>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>
>>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>>> ?????? threadLocalAllocBufferPfTopOffset =
>>>>>>>>>>> ??????? >????? >
>>>>>>>> ?? getFieldOffset("ThreadLocalAllocBuffer::_pf_top",
>>>>>>>>>>> ??????? > Integer.class,
>>>>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>
>>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>>> ??????? > threadLocalAllocBufferSlowAllocationsOffset
>>>>>>>>>>> ??????? >????? >???????? =
>>>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
>>>>>>>>>>> ??????? >????? >???????? Integer.class, "unsigned");
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>
>>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>>> ??????? > threadLocalAllocBufferFastRefillWasteOffset
>>>>>>>>>>> ??????? >????? >???????? =
>>>>>>>>>>> ??????? >
>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
>>>>>>>>>>> ??????? > >???????? Integer.class, "unsigned");
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>
>>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>>> ??????? > threadLocalAllocBufferNumberOfRefillsOffset
>>>>>>>>>>> ??????? >????? >???????? =
>>>>>>>>>>> ??????? >
>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
>>>>>>>>>>> ??????? > >???????? Integer.class, "unsigned");
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>
>>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>>> ??????? >????? > threadLocalAllocBufferRefillWasteLimitOffset
>>>>>> =
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
>>>>>>>>>>> ??????? >????? >???????? Integer.class, "size_t");
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>
>>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>>> ??????? > threadLocalAllocBufferDesiredSizeOffset =
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
>>>>>>>>>>> ??????? >????? >???????? Integer.class, "size_t");
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>
>>>>>>>>>>> ??????? > >??????????? public final int tlabAlignmentReserve =
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>> getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
>>>>>>
>>>>>>>>>>> ??????? > >???????? Integer.class, "size_t?);
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >????? >???????? hope this helps,
>>>>>>>>>>> ??????? >????? >???????? Karen
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >????? >>???????? On Apr 10, 2018, at 7:04 AM, Stefan
>>>>>> Johansson
>>>>>>>>>>> ??????? > >> <stefan.johansson at oracle.com
>>>>>>>>>>> <mailto:stefan.johansson at oracle.com>
>>>>>>>>>>> ??????? > <mailto:stefan.johansson at oracle.com
>>>>>>>>>>> <mailto:stefan.johansson at oracle.com>>
>>>>>>>>>>> ??????? >????? >> <mailto:stefan.johansson at oracle.com
>>>>>>>>>>> <mailto:stefan.johansson at oracle.com>
>>>>>>>>>>> ??????? > <mailto:stefan.johansson at oracle.com
>>>>>>>>>>> <mailto:stefan.johansson at oracle.com>>>> wrote:
>>>>>>>>>>> ??????? >????? >>
>>>>>>>>>>> ??????? >????? >>???????? Hi JC,
>>>>>>>>>>> ??????? >????? >>
>>>>>>>>>>> ??????? >????? >>???????? I realize that the names have been
>>>>>>>>>>> discussed
>>>>>>>>>>> ?????? before but I'm
>>>>>>>>>>> ??????? >????? >>???????? leaning towards suggesting
>>>>>>>>>>> something new. We
>>>>>>>>>>> ?????? discussed this
>>>>>>>>>>> ??????? >????? >>???????? briefly here in the office and
>>>>>>>>>>> others might
>>>>>>>> have
>>>>>>>>>>> ?????? different
>>>>>>>>>>> ??????? >????? >>???????? opinions. One point that came up
>>>>>>>>>>> is that if
>>>>>> we
>>>>>>>> do
>>>>>>>>>>> ?????? this
>>>>>>>>>>> ??????? >???? change
>>>>>>>>>>> ??????? >????? >>???????? and change all usages of
>>>>>>>>>>> ?????? JavaThread::tlab_end_offset() it
>>>>>>>>>>> ??????? >????? >>???????? would be good to make sure the new
>>>>>>>>>>> name is
>>>>>>>> good.
>>>>>>>>>>> ?????? To us
>>>>>>>>>>> ??????? >????? >> _current_end is not very descriptive, but
>>>>>>>> naming
>>>>>>>>>>> ?????? is hard and
>>>>>>>>>>> ??????? >????? >>???????? the best we could come up with is
>>>>>>>> _fast_path_end
>>>>>>>>>>> ?????? which would
>>>>>>>>>>> ??????? >????? >>???????? give the code:
>>>>>>>>>>> ??????? >????? >> cmpptr(end, Address(thread,
>>>>>>>>>>> ??????? >????? >> JavaThread::tlab_fast_path_end_offset()));
>>>>>>>>>>> ??????? >????? >> jcc(Assembler::above, slow_case);
>>>>>>>>>>> ??????? >????? >>
>>>>>>>>>>> ??????? >????? >>???????? I think this reads pretty good and
>>>>>>>>>>> is fairly
>>>>>>>>>>> ?????? clear. If we do
>>>>>>>>>>> ??????? >????? >>???????? this rename I think you can re-use
>>>>>>>>>>> _end in
>>>>>>>> JEP-331
>>>>>>>>>>> ??????? >???? instead of
>>>>>>>>>>> ??????? >????? >>???????? calling it _allocation_end. But
>>>>>>>>>>> that is a
>>>>>> later
>>>>>>>>>>> ?????? review :)
>>>>>>>>>>> ??????? >????? >>
>>>>>>>>>>> ??????? >????? >>???????? Also, is there a good reason for
>>>>>>>>>>> renaming
>>>>>>>>>>> ?????? hard_end() to
>>>>>>>>>>> ??????? >????? >> reserved_end()?
>>>>>>>>>>> ??????? >????? >>
>>>>>>>>>>> ??????? >????? >>???????? One additional thing, you need to
>>>>>>>>>>> update
>>>>>> the SA
>>>>>>>>>>> ?????? to reflect
>>>>>>>>>>> ??????? >????? >>???????? this change. I think the only
>>>>>>>>>>> place you
>>>>>> need to
>>>>>>>>>>> ?????? fix is in:
>>>>>>>>>>> ??????? >????? >>
>>>>>>>>>>> ??????? >
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
>>>>>>
>>>>>>>>>>> ??????? > >>
>>>>>>>>>>> ??????? >????? >>???????? Thanks,
>>>>>>>>>>> ??????? >????? >>???????? Stefan
>>>>>>>>>>> ??????? >????? >>
>>>>>>>>>>> ??????? >????? >>???????? On 2018-04-09 19:24, JC Beyler wrote:
>>>>>>>>>>> ??????? >????? >>>???????? Hi all,
>>>>>>>>>>> ??????? >????? >>>???????? Small pre-amble to this request:
>>>>>>>>>>> ??????? >????? >>>???????? In my work to try to get a heap
>>>>>>>>>>> sampler in
>>>>>>>>>>> ?????? OpenJDK (via JEP
>>>>>>>>>>> ??????? >????? >>>???????? 331
>>>>>>>>>>> ??????? > <https://bugs.openjdk.java.net/browse/JDK-8171119>),
>>>>>> I'm
>>>>>>>>>>> ??????? > >>>???????? trying to reduce the footprint of my
>>>>>> change so
>>>>>>>>>>> ?????? that the
>>>>>>>>>>> ??????? >????? >>> integration can be easier. I was told that
>>>>>>>>>>> ?????? generally a JEP
>>>>>>>>>>> ??????? >????? >>>???????? webrev should be feature complete
>>>>>>>>>>> and go in
>>>>>>>>>> at-once.
>>>>>>>>>>> ??????? > However,
>>>>>>>>>>> ??????? >????? >>>???????? with the change touching quite a
>>>>>>>>>>> bit of
>>>>>>>> various
>>>>>>>>>> code
>>>>>>>>>>> ??????? >???? pieces,
>>>>>>>>>>> ??????? >????? >>>???????? I was trying to figure out what
>>>>>>>>>>> could be
>>>>>>>>>>> ?????? separated as not
>>>>>>>>>>> ??????? >????? >>>???????? "part of the feature".
>>>>>>>>>>> ??????? >????? >>>???????? I asked around and said that
>>>>>>>>>>> perhaps a
>>>>>>>> solution
>>>>>>>>>>> ?????? would be to
>>>>>>>>>>> ??????? >????? >>>???????? cut up the renaming of TLAB's end
>>>>>>>>>>> field
>>>>>> that I
>>>>>>>>>>> ?????? do in that
>>>>>>>>>>> ??????? >????? >>>???????? webrev. Because I'm renaming a
>>>>>>>>>>> field in
>>>>>> TLAB
>>>>>>>>>> used by
>>>>>>>>>>> ??????? >???? various
>>>>>>>>>>> ??????? >????? >>> backends for that work, I have to update
>>>>>> every
>>>>>>>>>>> ?????? architecture
>>>>>>>>>>> ??????? >????? >>> dependent code to reflect it.
>>>>>>>>>>> ??????? >????? >>>???????? I entirely understand that
>>>>>>>>>>> perhaps this is
>>>>>> not
>>>>>>>>>>> ?????? in the
>>>>>>>>>>> ??????? >???? habits
>>>>>>>>>>> ??????? >????? >>>???????? and very potentially might not be
>>>>>>>>>>> the way
>>>>>>>> things
>>>>>>>>>> are
>>>>>>>>>>> ??????? > >>>???????? generally done. If so, I apologize and
>>>>>>>>>>> let
>>>>>> me
>>>>>>>>>>> ?????? know if you
>>>>>>>>>>> ??????? >????? >>>???????? would not want this to go in
>>>>>>>>>>> separately :)
>>>>>>>>>>> ??????? >????? >>>???????? Final note: there is still a
>>>>>>>>>>> chance JEP-331
>>>>>>>> does
>>>>>>>>>>> ?????? not go in.
>>>>>>>>>>> ??????? >????? >>>???????? If it does not, we can leave the
>>>>>>>>>>> new name
>>>>>> in
>>>>>>>>>>> ?????? place or I'll
>>>>>>>>>>> ??????? >????? >>>???????? happily revert it. I can even
>>>>>>>>>>> create an
>>>>>> issue
>>>>>>>> to
>>>>>>>>>>> ?????? track this
>>>>>>>>>>> ??????? >????? >>>???????? if that makes it easier for all.
>>>>>>>>>>> ??????? >????? >>>???????? End of the pre-amble.
>>>>>>>>>>> ??????? >????? >>>???????? The 33-line change webrev in
>>>>>>>>>>> question is
>>>>>> here:
>>>>>>>>>>> ??????? > >>>
>>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
>>>>>>>>>>> ??????? > >>>???????? I fixed all the architectures and
>>>>>>>>>>> JVMCI and
>>>>>>>> ran
>>>>>>>>>>> ?????? a few
>>>>>>>>>>> ??????? >???? sanity
>>>>>>>>>>> ??????? >????? >>>???????? tests to ensure I had not missed
>>>>>>>>>>> anything.
>>>>>>>>>>> ??????? >????? >>>???????? Thanks for your help and I hope
>>>>>>>>>>> this is not
>>>>>>>> too
>>>>>>>>>> much
>>>>>>>>>>> ??????? > trouble,
>>>>>>>>>>> ??????? >????? >>>???????? Jc
>>>>>>>>>>> ??????? >????? >>>???????? Ps: there is a graal change that
>>>>>>>>>>> needs to
>>>>>>>> happen
>>>>>>>>>>> ?????? but I was
>>>>>>>>>>> ??????? >????? >>>???????? not sure who/where
>>>>>> <https://teams.googleplex.com/u/where>
>>>>>>>> <https://teams.googleplex.com/u/where>
>>>>>>>>>> <https://teams.googleplex.com/u/where>
>>>>>>>>>>> <https://teams.googleplex.com/u/where>
>>>>>>>>>>> ??????? > <https://teams.googleplex.com/u/where>
>>>>>>>>>>> ??????? > <https://teams.googleplex.com/u/where> to
>>>>>>>>>>> ??????? >????? >>>???????? ask about it. I was told it could
>>>>>>>>>>> happen
>>>>>> in a
>>>>>>>>>>> ?????? separate
>>>>>>>>>>> ??????? >????? >>>???????? webrev. Can anyone point me to
>>>>>>>>>>> the right
>>>>>>>>>> direction?
>>>>>>>>>>> ??????? >???? Should it
>>>>>>>>>>> ??????? >????? >>>???????? just be hotspot-compiler-dev?
>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>> ??????? >
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>
From vladimir.kozlov at oracle.com Wed Apr 18 19:46:33 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 18 Apr 2018 12:46:33 -0700
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
fast_path_end
In-Reply-To: <30260bf8-765b-3227-87c0-85f001ca4c55@oracle.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
<CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
<3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>
<CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>
<5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
<CAF9BGBxEPXLTiyD-xG_ECyveyW0PXQL0+-z7jkw3Rv4QrkkszQ@mail.gmail.com>
<ec1a3e0e-ca9b-8668-b260-1fd3e612b7f7@oracle.com>
<CAF9BGBy-LBKCwJHQPdAQ65VRcSFBwVkk9dm8MLC_nrefE_JdEw@mail.gmail.com>
<e6528c19-5691-1215-1ac5-0349801b79b5@oracle.com>
<CAF9BGBwBgyOoJTfJU_YmqYJgSZ+1985yx_sSMJC4wNJELw1XDQ@mail.gmail.com>
<e63675e1-d693-cd25-75b2-32b593e266a2@oracle.com>
<CAF9BGBz3g4yXMjf9TxrqLdMbfaswoa3U13qYTEUtv-mZCDMd8Q@mail.gmail.com>
<735b3949-d9cd-3d37-ebb4-f59ee61f18ad@oracle.com>
<ba26dc77-a5ba-b490-2a03-cf4abd79ac3c@oracle.com>
<ff9474cd-6f07-446c-12b5-2dafbca35ce3@oracle.com>
<19c34a75-e1f5-f1b2-2cd7-91300e7979c3@oracle.com>
<30260bf8-765b-3227-87c0-85f001ca4c55@oracle.com>
Message-ID: <129b0875-52e8-eabc-258a-5ad4f36aa226@oracle.com>
On 4/18/18 12:15 PM, dean.long at oracle.com wrote:
> I will defer to Vladimir, but I would have been happy with something like:
>
> // preserve simple start/end abstraction for compiler
> HeapWord* end() const ? ? ?? { return fast_path_end(); }
> static ByteSize end_offset() { return fast_path_end_offset(); }
This is ugly.
>
> even though end_offset() would then refer to a virtual "end" field.
>
> Vladimir, are you also approving the Graal changes? :-)
You really made my day :(
S..t! We can't make this change in Graal as suggested because we will break Graal's JDK 8 support.
Graal has direct access to VM's fields through JVMCI. You have to guard change with JDK version check.
Labs start addressing multi-releases so it may be not big issue anymore. See Doug's comment for 8201318 RFR.
Anyway you have to file new PR (pull request) for Graal changes on https://github.com/graalvm/mx/pulls.
And I am not sponsoring this. I don't think such renaming worse all our efforts.
Good luck,
Vladimir
>
> dl
>
> On 4/18/18 11:02 AM, Vladimir Kozlov wrote:
>> Ganging up on us ;)
>>
>> Yes, I missed original discussion about renaming on GC list.
>>
>> From my point of view next code looks better because it seems compare related values:
>>
>> cmpptr(end, Address(thread, JavaThread::tlab_end_offset()));
>>
>> But I would not strongly object renaming to move this JEP forward. Consider changes reviewed and approved by me.
>>
>> Regards,
>> Vladimir
>>
>> On 4/18/18 6:29 AM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> The idea of splitting this change off from "8171119: Low-Overhead Heap Profiling"
>>> came up during the design review. It might have been me that suggested the split
>>> off or it was someone else. Sorry I don't remember.
>>>
>>> In any case, the rename of "end" to "fast_path_end" is just a clarity change to
>>> the existing code and I think that change can easily stand on its own. That is
>>> particularly true if the accessors are renamed at the same time. I think having
>>> the accessor names match the field names is a pretty well known HotSpot rule
>>> so I'm not sure why we're talking about not renaming the accessors...
>>>
>>> Personally, I prefer "_fast_path_end" over "_current_end".
>>>
>>> Dan
>>>
>>>
>>> On 4/18/18 4:04 AM, Stefan Johansson wrote:
>>>> Hi,
>>>>
>>>> On 2018-04-18 02:02, Vladimir Kozlov wrote:
>>>>> ?> I think I like better not to add it. If no one is using it, there should be
>>>>> ?> no reason to add it? By not adding it, it also makes any future wish to
>>>>> ?> have it a nice indicator of: hey why do you want to see this? Same as
>>>>> ?> hard_end btw which is not visible. Am I missing something?
>>>>>
>>>>> I say "may" ;)
>>>>> You don't need new function if there is no use.
>>>>>
>>>>> ?>
>>>>> ?> So to summarize, the current consensus:
>>>>> ?>??? - _end can be renamed either to _current_end or _fast_path_end; that is
>>>>> ?> still up to a vote and choice :)
>>>>>
>>>>> Please, use _current_end. I was thinking about _sample_end but it does not reflect double usage.
>>>>
>>>> I'm not sure if you have seen the discussion about naming on hotspot-gc-dev, but I and others think that
>>>> _current_end doesn't describe the usage at all. Naming it _fast_path_end would clearly state what it is, _sample_end
>>>> or something similar also crossed my mind but I think the code reads a lot better in the compiler with the name
>>>> fast_path_end.
>>>>
>>>>>
>>>>> ?>??? - the access method end() and tlab_end_offset() remain the same to not
>>>>> ?> modify JIT/interpreter codes
>>>> I would find this very unfortunate, having accessors that don't match the members can easily lead to
>>>> misunderstanding, especially if we have three different *_end members. Why do you think this is the best way forward?
>>>>
>>>> My first thought was also that it would be nice to avoid all the compiler changes, but then we would have to stick
>>>> with _end being the sample/current/fast-path end and I'm not sure that is a better solution. I don't see the big
>>>> problem with changing those accessors to what they really access and I think the compiler code reads good even after
>>>> the change. For example:
>>>> cmpptr(end, Address(thread, JavaThread::tlab_fast_path_end_offset()));
>>>> jcc(Assembler::above, slow_case);
>>>>
>>>>> ?>
>>>>> ?> If all agree to this, then the consequences are:
>>>>> ?>??? - JDK-8201326 becomes useless
>>>>> ?>??? - The work for JEP-331 becomes smaller in terms of file changes
>>>>> ?>??? - I'll still be needing a decision on the renaming of the TLAB _end field
>>>>> ?> (current suggestions are _current_end and _fast_path_end).
>>>>
>>>> We'll see where we end up. If JDK-8201326 ends up being a separate change I think it should be pushed at the same
>>>> time as the rest of the JEP changes. To me it only makes sense to have it in the code base if we also have the rest
>>>> of the changes.
>>>>
>>>> Thanks,
>>>> Stefan
>>>>
>>>>>
>>>>> Sounds good to me.
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 4/17/18 4:51 PM, JC Beyler wrote:
>>>>>> Hi Vladimir and Dean,
>>>>>>
>>>>>> @Dean: seems that Vladimir is in agreement with you for renaming just the
>>>>>> field and not the method names so ack to your answer that came at the same
>>>>>> time :)
>>>>>>
>>>>>>
>>>>>>> Yes, from the beginning such changes should be discussed on common
>>>>>>> hotspot-dev list since all
>>>>>>> Hotspot's parts are affected.
>>>>>>>
>>>>>>
>>>>>> Sorry, being new to the scene, most of the conversation had been going on
>>>>>> in serviceability-dev.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Graal specific question could be send to hotspot-compiler-dev list with
>>>>>>> [Graal] in subject.
>>>>>>>
>>>>>>> I looked on JEP's changes
>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.02/ to understand how
>>>>>>> it works.
>>>>>>>
>>>>>>> Few questions about proposed JEP changes so I can understand it.
>>>>>>>
>>>>>>> You introducing new TLAB end for sampling and adjust it so that
>>>>>>> allocations in JITed code and
>>>>>>> Interpreter it will trigger slow path allocation where you do sampling.
>>>>>>> Right?
>>>>>>>
>>>>>>
>>>>>> Yes that is correct; if sampling is enabled of course. Btw, this is the current
>>>>>> webrev <http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.15/>.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Do all changes to _end, _actual_end and other TLAB fields happen during
>>>>>>> slow allocation?
>>>>>>>
>>>>>>
>>>>>> Yes, to that effect, with Robbin's help, we finalized deprecating the
>>>>>> FastTLabRefill via JDK-8194084
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8194084>. Seems like I/we missed
>>>>>> that Graal does this as well. I filed GRAAL-64
>>>>>> <https://bugs.openjdk.java.net/browse/GRAAL-64> to not forget that Graal
>>>>>> would need to get that fixed.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> I am concern about concurrent accesses to these fields from other threads
>>>>>>> if you have them (I don't
>>>>>>> see).
>>>>>>>
>>>>>>
>>>>>> Yes that is why we deprecated the FastTlabRefill. Other threads should not
>>>>>> be changing the thread local data structure so I don't see an issue there.
>>>>>> The major issue was that the fast paths could change the tlab without going
>>>>>> via the slowpath.
>>>>>>
>>>>>> I had a fix to detect this issue but removed it once JDK-8194084 was done;
>>>>>> Graal was missed in that work so that is why if sampling were enabled with
>>>>>> Graal, there is a chance things would break currently. That will get fixed
>>>>>> via GRAAL-64 <https://bugs.openjdk.java.net/browse/GRAAL-64> whether it is
>>>>>> rendering the code also obsolete and going to the slowpath or whether it is
>>>>>> adding my fix again to detect a fastpath TLAB reallocation happened.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Renaming. I am fine with renaming if it helps to understand code better. I
>>>>>>> agree with proposed
>>>>>>> changes to fields name:
>>>>>>>
>>>>>>> _current_end
>>>>>>> _allocation_end
>>>>>>>
>>>>>>> But, as Dean, I would suggest to keep names of access functions. This way
>>>>>>> we can say that allocation
>>>>>>> code in Interpreter and JITed code stay the same.
>>>>>>>
>>>>>>
>>>>>> Sounds good to me, then in that case, this webrev will disappear, which
>>>>>> also makes me happy, since it simplifies a lot of things (and reduces code
>>>>>> change).
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> You may need only new method to access _allocation_end in places which
>>>>>>> look for real end of TLAB.
>>>>>>>
>>>>>>
>>>>>> I think I like better not to add it. If no one is using it, there should be
>>>>>> no reason to add it? By not adding it, it also makes any future wish to
>>>>>> have it a nice indicator of: hey why do you want to see this? Same as
>>>>>> hard_end btw which is not visible. Am I missing something?
>>>>>>
>>>>>> So to summarize, the current consensus:
>>>>>> ?? - _end can be renamed either to _current_end or _fast_path_end; that is
>>>>>> still up to a vote and choice :)
>>>>>> ?? - the access method end() and tlab_end_offset() remain the same to not
>>>>>> modify JIT/interpreter codes
>>>>>>
>>>>>> If all agree to this, then the consequences are:
>>>>>> ?? - JDK-8201326 becomes useless
>>>>>> ?? - The work for JEP-331 becomes smaller in terms of file changes
>>>>>> ?? - I'll still be needing a decision on the renaming of the TLAB _end field
>>>>>> (current suggestions are _current_end and _fast_path_end).
>>>>>>
>>>>>> Thanks for your help!
>>>>>> Jc
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 4/16/18 4:42 PM, JC Beyler wrote:
>>>>>>>> Hi Dean,
>>>>>>>>
>>>>>>>> I think perhaps this is also an attempt to figure out the naming of all
>>>>>>>> this because naming (or renaming like here) is often the start of big
>>>>>>>> conversations :).
>>>>>>>>
>>>>>>>> Originally, in the JEP-331 work, I had left the _end field as is and, by
>>>>>>>> doing so, this whole renaming webrev goes away. However, if we do that,
>>>>>>>> then the TLAB code contains:
>>>>>>>>
>>>>>>>> _end: the fast path end, can be the allocation end or the to-be-sampled
>>>>>>> end
>>>>>>>> _allocation_end: the actual allocation end of the current TLAB
>>>>>>>> hard_end: _allocation_end + reserved space
>>>>>>>>
>>>>>>>> With an early iteration of a webrev for JEP-331, a conversation occurred
>>>>>>>> about whether or not that was clear or not and it was determined that
>>>>>>> this
>>>>>>>> renaming was more clear:
>>>>>>>>
>>>>>>>> _current_end: the fast path end
>>>>>>>> _allocation_end: the actual allocation end of the current TLAB
>>>>>>>> reserved_end: _allocation_end + reserved space
>>>>>>>>
>>>>>>>> Because I'm trying to reduce the footprint of files changed, I pulled out
>>>>>>>> the renaming changes into this webrev. While talking about it with the GC
>>>>>>>> team, the renaming suggested became:
>>>>>>>>
>>>>>>>> _fast_path_end: the fast path end
>>>>>>>> _allocation_end: the actual allocation end of the current TLAB
>>>>>>>> hard_end: _allocation_end + reserved space
>>>>>>>>
>>>>>>>> Now, to be honest, any renaming or no renaming is fine by me. I like not
>>>>>>>> renaming the fields to not change the code of every backend and Graal; I
>>>>>>>> also like the fast_path_end rename due to it making the backend code easy
>>>>>>>> to read as mentioned in the GC mailing lis thread.
>>>>>>>>
>>>>>>>> So there are two questions really:
>>>>>>>> ???? - Should we rename the _end field and thus provoke the changes in
>>>>>>> this
>>>>>>>> webrev?
>>>>>>>> ???? - If we do want to change the field, should/could it go in an initial
>>>>>>>> webrev or should it go in the JEP-331 webrev whenever/ifever it goes in?
>>>>>>>> And if we do wait, could we at least converge on a renaming now so that
>>>>>>>> this does not become a point of contention for that webrev's review?
>>>>>>>>
>>>>>>>> If I read your answer correctly:
>>>>>>>> ?????? - You are saying that we should keep the _end field altogether; or
>>>>>>> at
>>>>>>>> least only rename the field not the methods to access it, thus reducing
>>>>>>> the
>>>>>>>> change scope.
>>>>>>>> ?????? - You are also saying to wait for the JEP-331 webrev's final
>>>>>>> iteration
>>>>>>>> and integrate it in one step
>>>>>>>>
>>>>>>>> Have I understood your answer correctly?
>>>>>>>>
>>>>>>>> Again, I am fine with renaming to whatever or not renaming at all. I just
>>>>>>>> am trying to get forward progress here :)
>>>>>>>>
>>>>>>>> Thanks for your help!
>>>>>>>> Jc
>>>>>>>>
>>>>>>>> On Mon, Apr 16, 2018 at 3:29 PM <dean.long at oracle.com> wrote:
>>>>>>>>
>>>>>>>>> Hi JC.? Others might disagree, but I would vote "no" on doing this
>>>>>>>>> renaming now, before the JEP, and even in the context of the JEP, I
>>>>>>>>> don't think renaming the field requires renaming all the uses.? The
>>>>>>>>> compiler code is only interested in the fast path, so it's implicitly
>>>>>>>>> understood.? Also, if there is a fast_path_end(), then isn't it logical
>>>>>>>>> to have fast_path_start() paired with it?? ("start" is already
>>>>>>>>> overloaded, but nobody is suggesting adding
>>>>>>>>> allocation_start()/current_start()/hard_start() are they?).? My opinion
>>>>>>>>> is that it's fine the way it is.
>>>>>>>>>
>>>>>>>>> dl
>>>>>>>>>
>>>>>>>>> On 4/16/18 1:43 PM, JC Beyler wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I've left the mail thread from the hotspot-gc-dev below for tracking
>>>>>>>>>> purposes but will start a new request here.
>>>>>>>>>>
>>>>>>>>>> - I'm trying to push a renaming of a TLAB field to make my work for
>>>>>>>>> JEP-331
>>>>>>>>>> <http://openjdk.java.net/jeps/331> easier
>>>>>>>>>> ????? - There is an understanding that if JEP-331 does not make it, this
>>>>>>>>> might
>>>>>>>>>> be useless and I'll revert if that is what the community wants; however
>>>>>>>>> the
>>>>>>>>>> new name seems better anyway so perhaps not?
>>>>>>>>>>
>>>>>>>>>> - The webrev renames a field used across the various back-ends and
>>>>>>> Graal
>>>>>>>>>> ????? - The webrev is here:
>>>>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.04/
>>>>>>>>>>
>>>>>>>>>> Could I please get some feedback on this?
>>>>>>>>>>
>>>>>>>>>> Thanks all for your help,
>>>>>>>>>> Jc
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Apr 13, 2018 at 2:37 AM Stefan Johansson <
>>>>>>>>>> stefan.johansson at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi JC,
>>>>>>>>>>>
>>>>>>>>>>> I don't have a name, but I've looked at bit more at the failures and I
>>>>>>>>>>> think they are unrelated and one of the local compiler engineers
>>>>>>> agree.
>>>>>>>>>>>
>>>>>>>>>>> I also ran some local testing and was not able to get any error with
>>>>>>> you
>>>>>>>>>>> latest changes, but verified that it doens't work without the graal
>>>>>>>>>>> parts. So they seem good. It might still be good to switch this over
>>>>>>> to
>>>>>>>>>>> the general hotspot-dev list to let someone with Graal knowledge to
>>>>>>> look
>>>>>>>>>>> at the change and make sure everything is correct.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Stefan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 2018-04-12 17:26, JC Beyler wrote:
>>>>>>>>>>>> Hi Stefan,
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for testing :). I've renamed the bug title in the JBS and will
>>>>>>>>>>>> emit a new webrev shortly. Do you have the name of a compiler
>>>>>>> engineer
>>>>>>>>>>>> in mind or should I perhaps now move this conversation to the general
>>>>>>>>>>>> hotspot-dev mailing list and ask there?
>>>>>>>>>>>>
>>>>>>>>>>>> The alternative is to add the compiler-mailing list to this email
>>>>>>>>> thread
>>>>>>>>>>>> and ask there before sending to the general list. What do you think
>>>>>>> is
>>>>>>>>>>> best?
>>>>>>>>>>>> Thanks for all your help,
>>>>>>>>>>>> Jc
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Apr 12, 2018 at 2:09 AM Stefan Johansson
>>>>>>>>>>>> <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ?????? On 2018-04-11 17:48, JC Beyler wrote:
>>>>>>>>>>>> ??????? > Hi Stefan,
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>> ??????? > Sorry about that, I must have missed adding the files or
>>>>>>>>>>>> ?????? something. Here
>>>>>>>>>>>> ??????? > is a webrev that added the changes for the SA file:
>>>>>>>>>>>> ??????? > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>> ?????? No problem, this looks good. I kicked of a run in our test
>>>>>>> system
>>>>>>>>> to
>>>>>>>>>>>> ?????? get
>>>>>>>>>>>> ?????? some more coverage and have tried to include some Graal
>>>>>>> testing.
>>>>>>>>> I'll
>>>>>>>>>>>> ?????? let you know the results once they are done.
>>>>>>>>>>>>
>>>>>>>>>>>> ?????? Please also update the bug title both in JBS and the changeset.
>>>>>>>>>>>>
>>>>>>>>>>>> ?????? Cheers,
>>>>>>>>>>>> ?????? Stefan
>>>>>>>>>>>>
>>>>>>>>>>>> ??????? > I changed the method name, which propagated a change to:
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>> ??????? > I tried testing your test file. It exists in my branch (if
>>>>>>> the
>>>>>>>>>>>> ?????? same) under:
>>>>>>>>>>>> ??????? > hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>> ??????? > and interestingly (which generally means I did something
>>>>>>>>> wrong),
>>>>>>>>>>> it
>>>>>>>>>>>> ??????? > passed before/after the change so I could not verify that
>>>>>>> this
>>>>>>>>> is
>>>>>>>>>>>> ?????? a test
>>>>>>>>>>>> ??????? > showing that all is well in the world on my side. Any ideas
>>>>>>> of
>>>>>>>>>>>> ?????? what I
>>>>>>>>>>>> ??????? > did wrong?
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>> ??????? > I did again test it for hotspot/jtreg/compiler/aot/ and
>>>>>>>>>>>> ??????? > hotspot/jtreg/serviceability/jvmti and it passes those.
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>> ??????? > Thanks for all your help,
>>>>>>>>>>>> ??????? > Jc
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>> ??????? > On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson
>>>>>>>>>>>> ??????? > <stefan.johansson at oracle.com <mailto:
>>>>>>>>> stefan.johansson at oracle.com>
>>>>>>>>>>>> <mailto:stefan.johansson at oracle.com
>>>>>>>>>>>> <mailto:stefan.johansson at oracle.com>>> wrote:
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>> ??????? >???? Hi JC,
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>> ??????? >???? On 2018-04-11 00:56, JC Beyler wrote:
>>>>>>>>>>>> ??????? >????? > Small update:
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >????? > Here is the fixed webrev for the '{' that were out of
>>>>>>>>>>>> ?????? alignment.
>>>>>>>>>>>> ??????? >???? This
>>>>>>>>>>>> ??????? >????? > passed release build JTREG
>>>>>>>>>>>> ?????? for hotspot/jtreg/compiler/jvmti (just
>>>>>>>>>>>> ??????? >???? to run
>>>>>>>>>>>> ??????? >????? > something as a smoke screen)
>>>>>>>>>>>> ?????? and hotspot/jtreg/compiler/aot/ (to
>>>>>>>>>>>> ??????? >???? test
>>>>>>>>>>>> ??????? >????? > Graal).
>>>>>>>>>>>> ??????? >????? >
>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >???? I think this looks better, I agree that leaving _end is
>>>>>>>>>>>> ?????? tempting to
>>>>>>>>>>>> ??????? >???? avoid a lot of change, but I think this will be better
>>>>>>> in
>>>>>>>>> the
>>>>>>>>>>>> ?????? long run.
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>> ??????? >???? I still miss the changes to make the SA work. To see a
>>>>>>>>>>>> ?????? problem you
>>>>>>>>>>>> ??????? >???? can run:
>>>>>>>>>>>> ??????? >???? make CONF=fast run-test
>>>>>>>>>>>> ??????? >
>>>>>>>>> TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>> ??????? >???? Cheers,
>>>>>>>>>>>> ??????? >???? Stefan
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>> ??????? >????? > Let me know what you think,
>>>>>>>>>>>> ??????? >????? > Jc
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >????? > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler
>>>>>>>>>>>> ?????? <jcbeyler at google.com <mailto:jcbeyler at google.com>
>>>>>>>>>>>> ??????? > <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com
>>>>>>>>>
>>>>>>>>>>>> ??????? >????? > <mailto:jcbeyler at google.com <mailto:
>>>>>>> jcbeyler at google.com
>>>>>>>>>>
>>>>>>>>>>>> <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>>>
>>>>>>>>> wrote:
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >????? >???? Hi Karen and Stefan,
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >????? >???? @Stefan: Naming is hard :)
>>>>>>>>>>>> ??????? >????? >???? @Karen: thanks for the Graal comment, I fixed it
>>>>>>> in
>>>>>>>>>>>> ?????? the new
>>>>>>>>>>>> ??????? >???? webrev,
>>>>>>>>>>>> ??????? >????? >???? let me know what you think :)
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >????? >???? I think the naming convention suggested in this
>>>>>>>>> webrev
>>>>>>>>>>>> ?????? came from
>>>>>>>>>>>> ??????? >????? >???? conversations in for JEP-331 and I am actually
>>>>>>>>>>> relatively
>>>>>>>>>>>> ??????? >????? > indifferent to the final result (as long as we
>>>>>>> have
>>>>>>>>>>>> ?????? some form of
>>>>>>>>>>>> ??????? >????? >???? forward progress :)). To be honest, I'd also be
>>>>>>>>> happy
>>>>>>>>>>>> ?????? to just
>>>>>>>>>>>> ??????? >???? leave
>>>>>>>>>>>> ??????? >????? >???? _end as is for all architectures and Graal and
>>>>>>> have
>>>>>>>>> a
>>>>>>>>>>> new
>>>>>>>>>>>> ??????? >????? > _allocation_end. However, during initial reviews
>>>>>>> of
>>>>>>>>>>>> ?????? JEP-331
>>>>>>>>>>>> ??????? >???? it was
>>>>>>>>>>>> ??????? >????? >???? deemed complicated to understand:
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >????? >???? _end -> the _end or sampling end
>>>>>>>>>>>> ??????? >????? >???? _allocation_end -> end pointer for the last
>>>>>>> possible
>>>>>>>>>>>> ?????? allocation
>>>>>>>>>>>> ??????? >????? >???? hard_end -> allocation end + reserved space
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >????? >???? That is how this naming came up and why hard_end
>>>>>>>>> went
>>>>>>>>>>> to
>>>>>>>>>>>> ??????? > "reserved_end".
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >????? >???? I'm really indifferent, so I offer as a perusal:
>>>>>>>>>>>> ??????? >????? >
>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >????? >???? I noticed a few problems of alignement of '{' so
>>>>>>>>> I'll
>>>>>>>>>>>> ?????? go fix
>>>>>>>>>>>> ??????? >???? that.
>>>>>>>>>>>> ??????? >????? >???? Basically this webrev does the following:
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >????? >???? - Uses fast_path_end instead of end
>>>>>>>>>>>> ??????? >????? >???? - Reverts hard_end back to where it was
>>>>>>>>>>>> ??????? >????? >???? - Adds the changes to Graal; there is a bunch of
>>>>>>>>>>>> ?????? changes in Graal
>>>>>>>>>>>> ??????? >????? >???? because Graal still contains a bit of code doing
>>>>>>>>>>>> ?????? fasttlabrefills.
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >????? >???? Let me know what you think!
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >????? >???? Thanks,
>>>>>>>>>>>> ??????? >????? >???? Jc
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >????? >???? On Tue, Apr 10, 2018 at 6:56 AM Karen Kinnear
>>>>>>>>>>>> ??????? >????? > <karen.kinnear at oracle.com
>>>>>>>>>>>> <mailto:karen.kinnear at oracle.com> <mailto:
>>>>>>>>> karen.kinnear at oracle.com
>>>>>>>>>>>> <mailto:karen.kinnear at oracle.com>>
>>>>>>>>>>>> ??????? > <mailto:karen.kinnear at oracle.com
>>>>>>>>>>>> <mailto:karen.kinnear at oracle.com> <mailto:
>>>>>>>>> karen.kinnear at oracle.com
>>>>>>>>>>>> <mailto:karen.kinnear at oracle.com>>>>
>>>>>>>>>>>> ??????? >???? wrote:
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >????? >???????? Hi JC,
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >????? >???????? A comment about Graal. The impact on Graal
>>>>>>> for
>>>>>>>>> this
>>>>>>>>>>>> ??????? > particular
>>>>>>>>>>>> ??????? >????? >???????? change would be to break it - so you?ll need
>>>>>>>>>>>> ??????? >????? >???????? to complete the Graal changes for this
>>>>>>> renaming.
>>>>>>>>>>>> ?????? That isn?t
>>>>>>>>>>>> ??????? >????? >???????? optional or something that could be a
>>>>>>>>> follow-on. It
>>>>>>>>>>>> ??????? > >???????? is not ok to break a feature, even an
>>>>>>>>> experimental
>>>>>>>>>>>> ?????? one.
>>>>>>>>>>>> ??????? >???? We will
>>>>>>>>>>>> ??????? >????? >???????? discuss in the other thread potential
>>>>>>> phasing of
>>>>>>>>>>>> ?????? adding
>>>>>>>>>>>> ??????? >???? sampling.
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >????? >???????? I did not do a thorough search -you can do
>>>>>>> that
>>>>>>>>> -
>>>>>>>>>>>> ?????? I did find
>>>>>>>>>>>> ??????? >????? > src/jdk.internal.vm.compiler/share/classes/
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>>>> ??????? > >??????????? public final int threadTlabOffset =
>>>>>>>>>>>> ??????? >????? > getFieldOffset("Thread::_tlab",
>>>>>>> Integer.class,
>>>>>>>>>>>> ??????? > >???????? "ThreadLocalAllocBuffer");
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>>>> ?????? threadLocalAllocBufferStartOffset =
>>>>>>>>>>>> ??????? >????? >
>>>>>>> ? getFieldOffset("ThreadLocalAllocBuffer::_start",
>>>>>>>>>>>> ??????? > Integer.class,
>>>>>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>>> threadLocalAllocBufferEndOffset =
>>>>>>>>>>>> ??????? >????? >
>>>>>>> ? getFieldOffset("ThreadLocalAllocBuffer::_end",
>>>>>>>>>>>> ?????? Integer.class,
>>>>>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>>> threadLocalAllocBufferTopOffset =
>>>>>>>>>>>> ??????? >????? >
>>>>>>> ? getFieldOffset("ThreadLocalAllocBuffer::_top",
>>>>>>>>>>>> ?????? Integer.class,
>>>>>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>>>> ?????? threadLocalAllocBufferPfTopOffset =
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>> ?? getFieldOffset("ThreadLocalAllocBuffer::_pf_top",
>>>>>>>>>>>> ??????? > Integer.class,
>>>>>>>>>>>> ??????? >????? >???????? "HeapWord*");
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>>>> ??????? > threadLocalAllocBufferSlowAllocationsOffset
>>>>>>>>>>>> ??????? >????? >???????? =
>>>>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
>>>>>>>>>>>> ??????? >????? >???????? Integer.class, "unsigned");
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>>>> ??????? > threadLocalAllocBufferFastRefillWasteOffset
>>>>>>>>>>>> ??????? >????? >???????? =
>>>>>>>>>>>> ??????? >
>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
>>>>>>>>>>>> ??????? > >???????? Integer.class, "unsigned");
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>>>> ??????? > threadLocalAllocBufferNumberOfRefillsOffset
>>>>>>>>>>>> ??????? >????? >???????? =
>>>>>>>>>>>> ??????? >
>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
>>>>>>>>>>>> ??????? > >???????? Integer.class, "unsigned");
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>>>> ??????? >????? > threadLocalAllocBufferRefillWasteLimitOffset
>>>>>>> =
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
>>>>>>>>>>>> ??????? >????? >???????? Integer.class, "size_t");
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>>>> ??????? > >??????????? private final int
>>>>>>>>>>>> ??????? > threadLocalAllocBufferDesiredSizeOffset =
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
>>>>>>>>>>>> ??????? >????? >???????? Integer.class, "size_t");
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>>>>>>>>>>> ??????? > >??????????? public final int tlabAlignmentReserve =
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>> getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
>>>>>>>>>>>> ??????? > >???????? Integer.class, "size_t?);
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >????? >???????? hope this helps,
>>>>>>>>>>>> ??????? >????? >???????? Karen
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >????? >>???????? On Apr 10, 2018, at 7:04 AM, Stefan
>>>>>>> Johansson
>>>>>>>>>>>> ??????? > >> <stefan.johansson at oracle.com
>>>>>>>>>>>> <mailto:stefan.johansson at oracle.com>
>>>>>>>>>>>> ??????? > <mailto:stefan.johansson at oracle.com
>>>>>>>>>>>> <mailto:stefan.johansson at oracle.com>>
>>>>>>>>>>>> ??????? >????? >> <mailto:stefan.johansson at oracle.com
>>>>>>>>>>>> <mailto:stefan.johansson at oracle.com>
>>>>>>>>>>>> ??????? > <mailto:stefan.johansson at oracle.com
>>>>>>>>>>>> <mailto:stefan.johansson at oracle.com>>>> wrote:
>>>>>>>>>>>> ??????? >????? >>
>>>>>>>>>>>> ??????? >????? >>???????? Hi JC,
>>>>>>>>>>>> ??????? >????? >>
>>>>>>>>>>>> ??????? >????? >>???????? I realize that the names have been discussed
>>>>>>>>>>>> ?????? before but I'm
>>>>>>>>>>>> ??????? >????? >>???????? leaning towards suggesting something new. We
>>>>>>>>>>>> ?????? discussed this
>>>>>>>>>>>> ??????? >????? >>???????? briefly here in the office and others might
>>>>>>>>> have
>>>>>>>>>>>> ?????? different
>>>>>>>>>>>> ??????? >????? >>???????? opinions. One point that came up is that if
>>>>>>> we
>>>>>>>>> do
>>>>>>>>>>>> ?????? this
>>>>>>>>>>>> ??????? >???? change
>>>>>>>>>>>> ??????? >????? >>???????? and change all usages of
>>>>>>>>>>>> ?????? JavaThread::tlab_end_offset() it
>>>>>>>>>>>> ??????? >????? >>???????? would be good to make sure the new name is
>>>>>>>>> good.
>>>>>>>>>>>> ?????? To us
>>>>>>>>>>>> ??????? >????? >> _current_end is not very descriptive, but
>>>>>>>>> naming
>>>>>>>>>>>> ?????? is hard and
>>>>>>>>>>>> ??????? >????? >>???????? the best we could come up with is
>>>>>>>>> _fast_path_end
>>>>>>>>>>>> ?????? which would
>>>>>>>>>>>> ??????? >????? >>???????? give the code:
>>>>>>>>>>>> ??????? >????? >> cmpptr(end, Address(thread,
>>>>>>>>>>>> ??????? >????? >> JavaThread::tlab_fast_path_end_offset()));
>>>>>>>>>>>> ??????? >????? >> jcc(Assembler::above, slow_case);
>>>>>>>>>>>> ??????? >????? >>
>>>>>>>>>>>> ??????? >????? >>???????? I think this reads pretty good and is fairly
>>>>>>>>>>>> ?????? clear. If we do
>>>>>>>>>>>> ??????? >????? >>???????? this rename I think you can re-use _end in
>>>>>>>>> JEP-331
>>>>>>>>>>>> ??????? >???? instead of
>>>>>>>>>>>> ??????? >????? >>???????? calling it _allocation_end. But that is a
>>>>>>> later
>>>>>>>>>>>> ?????? review :)
>>>>>>>>>>>> ??????? >????? >>
>>>>>>>>>>>> ??????? >????? >>???????? Also, is there a good reason for renaming
>>>>>>>>>>>> ?????? hard_end() to
>>>>>>>>>>>> ??????? >????? >> reserved_end()?
>>>>>>>>>>>> ??????? >????? >>
>>>>>>>>>>>> ??????? >????? >>???????? One additional thing, you need to update
>>>>>>> the SA
>>>>>>>>>>>> ?????? to reflect
>>>>>>>>>>>> ??????? >????? >>???????? this change. I think the only place you
>>>>>>> need to
>>>>>>>>>>>> ?????? fix is in:
>>>>>>>>>>>> ??????? >????? >>
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
>>>>>>>>>>>> ??????? > >>
>>>>>>>>>>>> ??????? >????? >>???????? Thanks,
>>>>>>>>>>>> ??????? >????? >>???????? Stefan
>>>>>>>>>>>> ??????? >????? >>
>>>>>>>>>>>> ??????? >????? >>???????? On 2018-04-09 19:24, JC Beyler wrote:
>>>>>>>>>>>> ??????? >????? >>>???????? Hi all,
>>>>>>>>>>>> ??????? >????? >>>???????? Small pre-amble to this request:
>>>>>>>>>>>> ??????? >????? >>>???????? In my work to try to get a heap sampler in
>>>>>>>>>>>> ?????? OpenJDK (via JEP
>>>>>>>>>>>> ??????? >????? >>>???????? 331
>>>>>>>>>>>> ??????? > <https://bugs.openjdk.java.net/browse/JDK-8171119>),
>>>>>>> I'm
>>>>>>>>>>>> ??????? > >>>???????? trying to reduce the footprint of my
>>>>>>> change so
>>>>>>>>>>>> ?????? that the
>>>>>>>>>>>> ??????? >????? >>> integration can be easier. I was told that
>>>>>>>>>>>> ?????? generally a JEP
>>>>>>>>>>>> ??????? >????? >>>???????? webrev should be feature complete and go in
>>>>>>>>>>> at-once.
>>>>>>>>>>>> ??????? > However,
>>>>>>>>>>>> ??????? >????? >>>???????? with the change touching quite a bit of
>>>>>>>>> various
>>>>>>>>>>> code
>>>>>>>>>>>> ??????? >???? pieces,
>>>>>>>>>>>> ??????? >????? >>>???????? I was trying to figure out what could be
>>>>>>>>>>>> ?????? separated as not
>>>>>>>>>>>> ??????? >????? >>>???????? "part of the feature".
>>>>>>>>>>>> ??????? >????? >>>???????? I asked around and said that perhaps a
>>>>>>>>> solution
>>>>>>>>>>>> ?????? would be to
>>>>>>>>>>>> ??????? >????? >>>???????? cut up the renaming of TLAB's end field
>>>>>>> that I
>>>>>>>>>>>> ?????? do in that
>>>>>>>>>>>> ??????? >????? >>>???????? webrev. Because I'm renaming a field in
>>>>>>> TLAB
>>>>>>>>>>> used by
>>>>>>>>>>>> ??????? >???? various
>>>>>>>>>>>> ??????? >????? >>> backends for that work, I have to update
>>>>>>> every
>>>>>>>>>>>> ?????? architecture
>>>>>>>>>>>> ??????? >????? >>> dependent code to reflect it.
>>>>>>>>>>>> ??????? >????? >>>???????? I entirely understand that perhaps this is
>>>>>>> not
>>>>>>>>>>>> ?????? in the
>>>>>>>>>>>> ??????? >???? habits
>>>>>>>>>>>> ??????? >????? >>>???????? and very potentially might not be the way
>>>>>>>>> things
>>>>>>>>>>> are
>>>>>>>>>>>> ??????? > >>>???????? generally done. If so, I apologize and let
>>>>>>> me
>>>>>>>>>>>> ?????? know if you
>>>>>>>>>>>> ??????? >????? >>>???????? would not want this to go in separately :)
>>>>>>>>>>>> ??????? >????? >>>???????? Final note: there is still a chance JEP-331
>>>>>>>>> does
>>>>>>>>>>>> ?????? not go in.
>>>>>>>>>>>> ??????? >????? >>>???????? If it does not, we can leave the new name
>>>>>>> in
>>>>>>>>>>>> ?????? place or I'll
>>>>>>>>>>>> ??????? >????? >>>???????? happily revert it. I can even create an
>>>>>>> issue
>>>>>>>>> to
>>>>>>>>>>>> ?????? track this
>>>>>>>>>>>> ??????? >????? >>>???????? if that makes it easier for all.
>>>>>>>>>>>> ??????? >????? >>>???????? End of the pre-amble.
>>>>>>>>>>>> ??????? >????? >>>???????? The 33-line change webrev in question is
>>>>>>> here:
>>>>>>>>>>>> ??????? > >>>
>>>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
>>>>>>>>>>>> ??????? > >>>???????? I fixed all the architectures and JVMCI and
>>>>>>>>> ran
>>>>>>>>>>>> ?????? a few
>>>>>>>>>>>> ??????? >???? sanity
>>>>>>>>>>>> ??????? >????? >>>???????? tests to ensure I had not missed anything.
>>>>>>>>>>>> ??????? >????? >>>???????? Thanks for your help and I hope this is not
>>>>>>>>> too
>>>>>>>>>>> much
>>>>>>>>>>>> ??????? > trouble,
>>>>>>>>>>>> ??????? >????? >>>???????? Jc
>>>>>>>>>>>> ??????? >????? >>>???????? Ps: there is a graal change that needs to
>>>>>>>>> happen
>>>>>>>>>>>> ?????? but I was
>>>>>>>>>>>> ??????? >????? >>>???????? not sure who/where
>>>>>>> <https://teams.googleplex.com/u/where>
>>>>>>>>> <https://teams.googleplex.com/u/where>
>>>>>>>>>>> <https://teams.googleplex.com/u/where>
>>>>>>>>>>>> <https://teams.googleplex.com/u/where>
>>>>>>>>>>>> ??????? > <https://teams.googleplex.com/u/where>
>>>>>>>>>>>> ??????? > <https://teams.googleplex.com/u/where> to
>>>>>>>>>>>> ??????? >????? >>>???????? ask about it. I was told it could happen
>>>>>>> in a
>>>>>>>>>>>> ?????? separate
>>>>>>>>>>>> ??????? >????? >>>???????? webrev. Can anyone point me to the right
>>>>>>>>>>> direction?
>>>>>>>>>>>> ??????? >???? Should it
>>>>>>>>>>>> ??????? >????? >>>???????? just be hotspot-compiler-dev?
>>>>>>>>>>>> ??????? >????? >
>>>>>>>>>>>> ??????? >
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>
>
From jcbeyler at google.com Wed Apr 18 21:54:42 2018
From: jcbeyler at google.com (JC Beyler)
Date: Wed, 18 Apr 2018 21:54:42 +0000
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
fast_path_end
In-Reply-To: <129b0875-52e8-eabc-258a-5ad4f36aa226@oracle.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
<CAF9BGBxHGo=SZf1F-LsUJYB=kYgmzH0v1x=Hqid9fMNE-xFzXQ@mail.gmail.com>
<3c42c0dc-e013-38e3-af10-aa474fd8e16c@oracle.com>
<CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>
<5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
<CAF9BGBxEPXLTiyD-xG_ECyveyW0PXQL0+-z7jkw3Rv4QrkkszQ@mail.gmail.com>
<ec1a3e0e-ca9b-8668-b260-1fd3e612b7f7@oracle.com>
<CAF9BGBy-LBKCwJHQPdAQ65VRcSFBwVkk9dm8MLC_nrefE_JdEw@mail.gmail.com>
<e6528c19-5691-1215-1ac5-0349801b79b5@oracle.com>
<CAF9BGBwBgyOoJTfJU_YmqYJgSZ+1985yx_sSMJC4wNJELw1XDQ@mail.gmail.com>
<e63675e1-d693-cd25-75b2-32b593e266a2@oracle.com>
<CAF9BGBz3g4yXMjf9TxrqLdMbfaswoa3U13qYTEUtv-mZCDMd8Q@mail.gmail.com>
<735b3949-d9cd-3d37-ebb4-f59ee61f18ad@oracle.com>
<ba26dc77-a5ba-b490-2a03-cf4abd79ac3c@oracle.com>
<ff9474cd-6f07-446c-12b5-2dafbca35ce3@oracle.com>
<19c34a75-e1f5-f1b2-2cd7-91300e7979c3@oracle.com>
<30260bf8-765b-3227-87c0-85f001ca4c55@oracle.com>
<129b0875-52e8-eabc-258a-5ad4f36aa226@oracle.com>
Message-ID: <CAF9BGBypU+AexV5vt-mJD5rLAqxfORwYa0f16s9iWwRhF2Z+3w@mail.gmail.com>
Seems like there is no consensus really except that changing it has a few
headaches involved. Should we then do the implementation of "8171119:
Low-Overhead Heap Profiling" without changing the _end field and postpone
this conversation to afterwards when Graal handles multi-release in a more
mature manner (read has been doing it for a while).
Or is there still a path forward? (Re)Naming is hard, this is proof of that.
That puts us back to what I had originally:
_end: the fast path end, can be the allocation end or the to-be-sampled end
_allocation_end: the actual allocation end of the current TLAB
hard_end: _allocation_end + reserved space
Thanks for all of your input and help on this,
Jc
On Wed, Apr 18, 2018 at 12:46 PM Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:
> On 4/18/18 12:15 PM, dean.long at oracle.com wrote:
> > I will defer to Vladimir, but I would have been happy with something
> like:
> >
> > // preserve simple start/end abstraction for compiler
> > HeapWord* end() const { return fast_path_end(); }
> > static ByteSize end_offset() { return fast_path_end_offset(); }
>
> This is ugly.
>
> >
> > even though end_offset() would then refer to a virtual "end" field.
> >
> > Vladimir, are you also approving the Graal changes? :-)
>
> You really made my day :(
>
> S..t! We can't make this change in Graal as suggested because we will
> break Graal's JDK 8 support.
> Graal has direct access to VM's fields through JVMCI. You have to guard
> change with JDK version check.
>
> Labs start addressing multi-releases so it may be not big issue anymore.
> See Doug's comment for 8201318 RFR.
>
> Anyway you have to file new PR (pull request) for Graal changes on
> https://github.com/graalvm/mx/pulls.
> And I am not sponsoring this. I don't think such renaming worse all our
> efforts.
>
> Good luck,
> Vladimir
>
> >
> > dl
> >
> > On 4/18/18 11:02 AM, Vladimir Kozlov wrote:
> >> Ganging up on us ;)
> >>
> >> Yes, I missed original discussion about renaming on GC list.
> >>
> >> From my point of view next code looks better because it seems compare
> related values:
> >>
> >> cmpptr(end, Address(thread, JavaThread::tlab_end_offset()));
> >>
> >> But I would not strongly object renaming to move this JEP forward.
> Consider changes reviewed and approved by me.
> >>
> >> Regards,
> >> Vladimir
> >>
> >> On 4/18/18 6:29 AM, Daniel D. Daugherty wrote:
> >>> Greetings,
> >>>
> >>> The idea of splitting this change off from "8171119: Low-Overhead Heap
> Profiling"
> >>> came up during the design review. It might have been me that suggested
> the split
> >>> off or it was someone else. Sorry I don't remember.
> >>>
> >>> In any case, the rename of "end" to "fast_path_end" is just a clarity
> change to
> >>> the existing code and I think that change can easily stand on its own.
> That is
> >>> particularly true if the accessors are renamed at the same time. I
> think having
> >>> the accessor names match the field names is a pretty well known
> HotSpot rule
> >>> so I'm not sure why we're talking about not renaming the accessors...
> >>>
> >>> Personally, I prefer "_fast_path_end" over "_current_end".
> >>>
> >>> Dan
> >>>
> >>>
> >>> On 4/18/18 4:04 AM, Stefan Johansson wrote:
> >>>> Hi,
> >>>>
> >>>> On 2018-04-18 02:02, Vladimir Kozlov wrote:
> >>>>> > I think I like better not to add it. If no one is using it, there
> should be
> >>>>> > no reason to add it? By not adding it, it also makes any future
> wish to
> >>>>> > have it a nice indicator of: hey why do you want to see this?
> Same as
> >>>>> > hard_end btw which is not visible. Am I missing something?
> >>>>>
> >>>>> I say "may" ;)
> >>>>> You don't need new function if there is no use.
> >>>>>
> >>>>> >
> >>>>> > So to summarize, the current consensus:
> >>>>> > - _end can be renamed either to _current_end or
> _fast_path_end; that is
> >>>>> > still up to a vote and choice :)
> >>>>>
> >>>>> Please, use _current_end. I was thinking about _sample_end but it
> does not reflect double usage.
> >>>>
> >>>> I'm not sure if you have seen the discussion about naming on
> hotspot-gc-dev, but I and others think that
> >>>> _current_end doesn't describe the usage at all. Naming it
> _fast_path_end would clearly state what it is, _sample_end
> >>>> or something similar also crossed my mind but I think the code reads
> a lot better in the compiler with the name
> >>>> fast_path_end.
> >>>>
> >>>>>
> >>>>> > - the access method end() and tlab_end_offset() remain the
> same to not
> >>>>> > modify JIT/interpreter codes
> >>>> I would find this very unfortunate, having accessors that don't match
> the members can easily lead to
> >>>> misunderstanding, especially if we have three different *_end
> members. Why do you think this is the best way forward?
> >>>>
> >>>> My first thought was also that it would be nice to avoid all the
> compiler changes, but then we would have to stick
> >>>> with _end being the sample/current/fast-path end and I'm not sure
> that is a better solution. I don't see the big
> >>>> problem with changing those accessors to what they really access and
> I think the compiler code reads good even after
> >>>> the change. For example:
> >>>> cmpptr(end, Address(thread, JavaThread::tlab_fast_path_end_offset()));
> >>>> jcc(Assembler::above, slow_case);
> >>>>
> >>>>> >
> >>>>> > If all agree to this, then the consequences are:
> >>>>> > - JDK-8201326 becomes useless
> >>>>> > - The work for JEP-331 becomes smaller in terms of file changes
> >>>>> > - I'll still be needing a decision on the renaming of the TLAB
> _end field
> >>>>> > (current suggestions are _current_end and _fast_path_end).
> >>>>
> >>>> We'll see where we end up. If JDK-8201326 ends up being a separate
> change I think it should be pushed at the same
> >>>> time as the rest of the JEP changes. To me it only makes sense to
> have it in the code base if we also have the rest
> >>>> of the changes.
> >>>>
> >>>> Thanks,
> >>>> Stefan
> >>>>
> >>>>>
> >>>>> Sounds good to me.
> >>>>>
> >>>>> Thanks,
> >>>>> Vladimir
> >>>>>
> >>>>> On 4/17/18 4:51 PM, JC Beyler wrote:
> >>>>>> Hi Vladimir and Dean,
> >>>>>>
> >>>>>> @Dean: seems that Vladimir is in agreement with you for renaming
> just the
> >>>>>> field and not the method names so ack to your answer that came at
> the same
> >>>>>> time :)
> >>>>>>
> >>>>>>
> >>>>>>> Yes, from the beginning such changes should be discussed on common
> >>>>>>> hotspot-dev list since all
> >>>>>>> Hotspot's parts are affected.
> >>>>>>>
> >>>>>>
> >>>>>> Sorry, being new to the scene, most of the conversation had been
> going on
> >>>>>> in serviceability-dev.
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Graal specific question could be send to hotspot-compiler-dev list
> with
> >>>>>>> [Graal] in subject.
> >>>>>>>
> >>>>>>> I looked on JEP's changes
> >>>>>>> http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.02/ to
> understand how
> >>>>>>> it works.
> >>>>>>>
> >>>>>>> Few questions about proposed JEP changes so I can understand it.
> >>>>>>>
> >>>>>>> You introducing new TLAB end for sampling and adjust it so that
> >>>>>>> allocations in JITed code and
> >>>>>>> Interpreter it will trigger slow path allocation where you do
> sampling.
> >>>>>>> Right?
> >>>>>>>
> >>>>>>
> >>>>>> Yes that is correct; if sampling is enabled of course. Btw, this is
> the current
> >>>>>> webrev <http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.15/
> >.
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Do all changes to _end, _actual_end and other TLAB fields happen
> during
> >>>>>>> slow allocation?
> >>>>>>>
> >>>>>>
> >>>>>> Yes, to that effect, with Robbin's help, we finalized deprecating
> the
> >>>>>> FastTLabRefill via JDK-8194084
> >>>>>> <https://bugs.openjdk.java.net/browse/JDK-8194084>. Seems like
> I/we missed
> >>>>>> that Graal does this as well. I filed GRAAL-64
> >>>>>> <https://bugs.openjdk.java.net/browse/GRAAL-64> to not forget that
> Graal
> >>>>>> would need to get that fixed.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> I am concern about concurrent accesses to these fields from other
> threads
> >>>>>>> if you have them (I don't
> >>>>>>> see).
> >>>>>>>
> >>>>>>
> >>>>>> Yes that is why we deprecated the FastTlabRefill. Other threads
> should not
> >>>>>> be changing the thread local data structure so I don't see an issue
> there.
> >>>>>> The major issue was that the fast paths could change the tlab
> without going
> >>>>>> via the slowpath.
> >>>>>>
> >>>>>> I had a fix to detect this issue but removed it once JDK-8194084
> was done;
> >>>>>> Graal was missed in that work so that is why if sampling were
> enabled with
> >>>>>> Graal, there is a chance things would break currently. That will
> get fixed
> >>>>>> via GRAAL-64 <https://bugs.openjdk.java.net/browse/GRAAL-64>
> whether it is
> >>>>>> rendering the code also obsolete and going to the slowpath or
> whether it is
> >>>>>> adding my fix again to detect a fastpath TLAB reallocation happened.
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Renaming. I am fine with renaming if it helps to understand code
> better. I
> >>>>>>> agree with proposed
> >>>>>>> changes to fields name:
> >>>>>>>
> >>>>>>> _current_end
> >>>>>>> _allocation_end
> >>>>>>>
> >>>>>>> But, as Dean, I would suggest to keep names of access functions.
> This way
> >>>>>>> we can say that allocation
> >>>>>>> code in Interpreter and JITed code stay the same.
> >>>>>>>
> >>>>>>
> >>>>>> Sounds good to me, then in that case, this webrev will disappear,
> which
> >>>>>> also makes me happy, since it simplifies a lot of things (and
> reduces code
> >>>>>> change).
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> You may need only new method to access _allocation_end in places
> which
> >>>>>>> look for real end of TLAB.
> >>>>>>>
> >>>>>>
> >>>>>> I think I like better not to add it. If no one is using it, there
> should be
> >>>>>> no reason to add it? By not adding it, it also makes any future
> wish to
> >>>>>> have it a nice indicator of: hey why do you want to see this? Same
> as
> >>>>>> hard_end btw which is not visible. Am I missing something?
> >>>>>>
> >>>>>> So to summarize, the current consensus:
> >>>>>> - _end can be renamed either to _current_end or _fast_path_end;
> that is
> >>>>>> still up to a vote and choice :)
> >>>>>> - the access method end() and tlab_end_offset() remain the same
> to not
> >>>>>> modify JIT/interpreter codes
> >>>>>>
> >>>>>> If all agree to this, then the consequences are:
> >>>>>> - JDK-8201326 becomes useless
> >>>>>> - The work for JEP-331 becomes smaller in terms of file changes
> >>>>>> - I'll still be needing a decision on the renaming of the TLAB
> _end field
> >>>>>> (current suggestions are _current_end and _fast_path_end).
> >>>>>>
> >>>>>> Thanks for your help!
> >>>>>> Jc
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Vladimir
> >>>>>>>
> >>>>>>> On 4/16/18 4:42 PM, JC Beyler wrote:
> >>>>>>>> Hi Dean,
> >>>>>>>>
> >>>>>>>> I think perhaps this is also an attempt to figure out the naming
> of all
> >>>>>>>> this because naming (or renaming like here) is often the start of
> big
> >>>>>>>> conversations :).
> >>>>>>>>
> >>>>>>>> Originally, in the JEP-331 work, I had left the _end field as is
> and, by
> >>>>>>>> doing so, this whole renaming webrev goes away. However, if we do
> that,
> >>>>>>>> then the TLAB code contains:
> >>>>>>>>
> >>>>>>>> _end: the fast path end, can be the allocation end or the
> to-be-sampled
> >>>>>>> end
> >>>>>>>> _allocation_end: the actual allocation end of the current TLAB
> >>>>>>>> hard_end: _allocation_end + reserved space
> >>>>>>>>
> >>>>>>>> With an early iteration of a webrev for JEP-331, a conversation
> occurred
> >>>>>>>> about whether or not that was clear or not and it was determined
> that
> >>>>>>> this
> >>>>>>>> renaming was more clear:
> >>>>>>>>
> >>>>>>>> _current_end: the fast path end
> >>>>>>>> _allocation_end: the actual allocation end of the current TLAB
> >>>>>>>> reserved_end: _allocation_end + reserved space
> >>>>>>>>
> >>>>>>>> Because I'm trying to reduce the footprint of files changed, I
> pulled out
> >>>>>>>> the renaming changes into this webrev. While talking about it
> with the GC
> >>>>>>>> team, the renaming suggested became:
> >>>>>>>>
> >>>>>>>> _fast_path_end: the fast path end
> >>>>>>>> _allocation_end: the actual allocation end of the current TLAB
> >>>>>>>> hard_end: _allocation_end + reserved space
> >>>>>>>>
> >>>>>>>> Now, to be honest, any renaming or no renaming is fine by me. I
> like not
> >>>>>>>> renaming the fields to not change the code of every backend and
> Graal; I
> >>>>>>>> also like the fast_path_end rename due to it making the backend
> code easy
> >>>>>>>> to read as mentioned in the GC mailing lis thread.
> >>>>>>>>
> >>>>>>>> So there are two questions really:
> >>>>>>>> - Should we rename the _end field and thus provoke the
> changes in
> >>>>>>> this
> >>>>>>>> webrev?
> >>>>>>>> - If we do want to change the field, should/could it go in
> an initial
> >>>>>>>> webrev or should it go in the JEP-331 webrev whenever/ifever it
> goes in?
> >>>>>>>> And if we do wait, could we at least converge on a renaming now
> so that
> >>>>>>>> this does not become a point of contention for that webrev's
> review?
> >>>>>>>>
> >>>>>>>> If I read your answer correctly:
> >>>>>>>> - You are saying that we should keep the _end field
> altogether; or
> >>>>>>> at
> >>>>>>>> least only rename the field not the methods to access it, thus
> reducing
> >>>>>>> the
> >>>>>>>> change scope.
> >>>>>>>> - You are also saying to wait for the JEP-331 webrev's
> final
> >>>>>>> iteration
> >>>>>>>> and integrate it in one step
> >>>>>>>>
> >>>>>>>> Have I understood your answer correctly?
> >>>>>>>>
> >>>>>>>> Again, I am fine with renaming to whatever or not renaming at
> all. I just
> >>>>>>>> am trying to get forward progress here :)
> >>>>>>>>
> >>>>>>>> Thanks for your help!
> >>>>>>>> Jc
> >>>>>>>>
> >>>>>>>> On Mon, Apr 16, 2018 at 3:29 PM <dean.long at oracle.com> wrote:
> >>>>>>>>
> >>>>>>>>> Hi JC. Others might disagree, but I would vote "no" on doing
> this
> >>>>>>>>> renaming now, before the JEP, and even in the context of the
> JEP, I
> >>>>>>>>> don't think renaming the field requires renaming all the uses.
> The
> >>>>>>>>> compiler code is only interested in the fast path, so it's
> implicitly
> >>>>>>>>> understood. Also, if there is a fast_path_end(), then isn't it
> logical
> >>>>>>>>> to have fast_path_start() paired with it? ("start" is already
> >>>>>>>>> overloaded, but nobody is suggesting adding
> >>>>>>>>> allocation_start()/current_start()/hard_start() are they?). My
> opinion
> >>>>>>>>> is that it's fine the way it is.
> >>>>>>>>>
> >>>>>>>>> dl
> >>>>>>>>>
> >>>>>>>>> On 4/16/18 1:43 PM, JC Beyler wrote:
> >>>>>>>>>> Hi all,
> >>>>>>>>>>
> >>>>>>>>>> I've left the mail thread from the hotspot-gc-dev below for
> tracking
> >>>>>>>>>> purposes but will start a new request here.
> >>>>>>>>>>
> >>>>>>>>>> - I'm trying to push a renaming of a TLAB field to make my work
> for
> >>>>>>>>> JEP-331
> >>>>>>>>>> <http://openjdk.java.net/jeps/331> easier
> >>>>>>>>>> - There is an understanding that if JEP-331 does not make
> it, this
> >>>>>>>>> might
> >>>>>>>>>> be useless and I'll revert if that is what the community wants;
> however
> >>>>>>>>> the
> >>>>>>>>>> new name seems better anyway so perhaps not?
> >>>>>>>>>>
> >>>>>>>>>> - The webrev renames a field used across the various back-ends
> and
> >>>>>>> Graal
> >>>>>>>>>> - The webrev is here:
> >>>>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.04/
> >>>>>>>>>>
> >>>>>>>>>> Could I please get some feedback on this?
> >>>>>>>>>>
> >>>>>>>>>> Thanks all for your help,
> >>>>>>>>>> Jc
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Apr 13, 2018 at 2:37 AM Stefan Johansson <
> >>>>>>>>>> stefan.johansson at oracle.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hi JC,
> >>>>>>>>>>>
> >>>>>>>>>>> I don't have a name, but I've looked at bit more at the
> failures and I
> >>>>>>>>>>> think they are unrelated and one of the local compiler
> engineers
> >>>>>>> agree.
> >>>>>>>>>>>
> >>>>>>>>>>> I also ran some local testing and was not able to get any
> error with
> >>>>>>> you
> >>>>>>>>>>> latest changes, but verified that it doens't work without the
> graal
> >>>>>>>>>>> parts. So they seem good. It might still be good to switch
> this over
> >>>>>>> to
> >>>>>>>>>>> the general hotspot-dev list to let someone with Graal
> knowledge to
> >>>>>>> look
> >>>>>>>>>>> at the change and make sure everything is correct.
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>> Stefan
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On 2018-04-12 17:26, JC Beyler wrote:
> >>>>>>>>>>>> Hi Stefan,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks for testing :). I've renamed the bug title in the JBS
> and will
> >>>>>>>>>>>> emit a new webrev shortly. Do you have the name of a compiler
> >>>>>>> engineer
> >>>>>>>>>>>> in mind or should I perhaps now move this conversation to the
> general
> >>>>>>>>>>>> hotspot-dev mailing list and ask there?
> >>>>>>>>>>>>
> >>>>>>>>>>>> The alternative is to add the compiler-mailing list to this
> email
> >>>>>>>>> thread
> >>>>>>>>>>>> and ask there before sending to the general list. What do you
> think
> >>>>>>> is
> >>>>>>>>>>> best?
> >>>>>>>>>>>> Thanks for all your help,
> >>>>>>>>>>>> Jc
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Thu, Apr 12, 2018 at 2:09 AM Stefan Johansson
> >>>>>>>>>>>> <stefan.johansson at oracle.com <mailto:
> stefan.johansson at oracle.com>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 2018-04-11 17:48, JC Beyler wrote:
> >>>>>>>>>>>> > Hi Stefan,
> >>>>>>>>>>>> >
> >>>>>>>>>>>> > Sorry about that, I must have missed adding the
> files or
> >>>>>>>>>>>> something. Here
> >>>>>>>>>>>> > is a webrev that added the changes for the SA file:
> >>>>>>>>>>>> >
> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/
> >>>>>>>>>>>> >
> >>>>>>>>>>>> No problem, this looks good. I kicked of a run in our
> test
> >>>>>>> system
> >>>>>>>>> to
> >>>>>>>>>>>> get
> >>>>>>>>>>>> some more coverage and have tried to include some Graal
> >>>>>>> testing.
> >>>>>>>>> I'll
> >>>>>>>>>>>> let you know the results once they are done.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please also update the bug title both in JBS and the
> changeset.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Cheers,
> >>>>>>>>>>>> Stefan
> >>>>>>>>>>>>
> >>>>>>>>>>>> > I changed the method name, which propagated a
> change to:
> >>>>>>>>>>>> >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
> >>>>>>>>>>>> >
> >>>>>>>>>>>> > I tried testing your test file. It exists in my
> branch (if
> >>>>>>> the
> >>>>>>>>>>>> same) under:
> >>>>>>>>>>>> > hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
> >>>>>>>>>>>> >
> >>>>>>>>>>>> > and interestingly (which generally means I did
> something
> >>>>>>>>> wrong),
> >>>>>>>>>>> it
> >>>>>>>>>>>> > passed before/after the change so I could not
> verify that
> >>>>>>> this
> >>>>>>>>> is
> >>>>>>>>>>>> a test
> >>>>>>>>>>>> > showing that all is well in the world on my side.
> Any ideas
> >>>>>>> of
> >>>>>>>>>>>> what I
> >>>>>>>>>>>> > did wrong?
> >>>>>>>>>>>> >
> >>>>>>>>>>>> > I did again test it for hotspot/jtreg/compiler/aot/
> and
> >>>>>>>>>>>> > hotspot/jtreg/serviceability/jvmti and it passes
> those.
> >>>>>>>>>>>> >
> >>>>>>>>>>>> > Thanks for all your help,
> >>>>>>>>>>>> > Jc
> >>>>>>>>>>>> >
> >>>>>>>>>>>> >
> >>>>>>>>>>>> >
> >>>>>>>>>>>> > On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson
> >>>>>>>>>>>> > <stefan.johansson at oracle.com <mailto:
> >>>>>>>>> stefan.johansson at oracle.com>
> >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com
> >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com>>> wrote:
> >>>>>>>>>>>> >
> >>>>>>>>>>>> > Hi JC,
> >>>>>>>>>>>> >
> >>>>>>>>>>>> > On 2018-04-11 00:56, JC Beyler wrote:
> >>>>>>>>>>>> > > Small update:
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> > > Here is the fixed webrev for the '{' that
> were out of
> >>>>>>>>>>>> alignment.
> >>>>>>>>>>>> > This
> >>>>>>>>>>>> > > passed release build JTREG
> >>>>>>>>>>>> for hotspot/jtreg/compiler/jvmti (just
> >>>>>>>>>>>> > to run
> >>>>>>>>>>>> > > something as a smoke screen)
> >>>>>>>>>>>> and hotspot/jtreg/compiler/aot/ (to
> >>>>>>>>>>>> > test
> >>>>>>>>>>>> > > Graal).
> >>>>>>>>>>>> > >
> >>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> > I think this looks better, I agree that leaving
> _end is
> >>>>>>>>>>>> tempting to
> >>>>>>>>>>>> > avoid a lot of change, but I think this will be
> better
> >>>>>>> in
> >>>>>>>>> the
> >>>>>>>>>>>> long run.
> >>>>>>>>>>>> >
> >>>>>>>>>>>> > I still miss the changes to make the SA work.
> To see a
> >>>>>>>>>>>> problem you
> >>>>>>>>>>>> > can run:
> >>>>>>>>>>>> > make CONF=fast run-test
> >>>>>>>>>>>> >
> >>>>>>>>> TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
> >>>>>>>>>>>> >
> >>>>>>>>>>>> > Cheers,
> >>>>>>>>>>>> > Stefan
> >>>>>>>>>>>> >
> >>>>>>>>>>>> > > Let me know what you think,
> >>>>>>>>>>>> > > Jc
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> > > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler
> >>>>>>>>>>>> <jcbeyler at google.com <mailto:jcbeyler at google.com>
> >>>>>>>>>>>> > <mailto:jcbeyler at google.com <mailto:
> jcbeyler at google.com
> >>>>>>>>>
> >>>>>>>>>>>> > > <mailto:jcbeyler at google.com <mailto:
> >>>>>>> jcbeyler at google.com
> >>>>>>>>>>
> >>>>>>>>>>>> <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> > > Hi Karen and Stefan,
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> > > @Stefan: Naming is hard :)
> >>>>>>>>>>>> > > @Karen: thanks for the Graal comment, I
> fixed it
> >>>>>>> in
> >>>>>>>>>>>> the new
> >>>>>>>>>>>> > webrev,
> >>>>>>>>>>>> > > let me know what you think :)
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> > > I think the naming convention suggested
> in this
> >>>>>>>>> webrev
> >>>>>>>>>>>> came from
> >>>>>>>>>>>> > > conversations in for JEP-331 and I am
> actually
> >>>>>>>>>>> relatively
> >>>>>>>>>>>> > > indifferent to the final result (as long as
> we
> >>>>>>> have
> >>>>>>>>>>>> some form of
> >>>>>>>>>>>> > > forward progress :)). To be honest, I'd
> also be
> >>>>>>>>> happy
> >>>>>>>>>>>> to just
> >>>>>>>>>>>> > leave
> >>>>>>>>>>>> > > _end as is for all architectures and
> Graal and
> >>>>>>> have
> >>>>>>>>> a
> >>>>>>>>>>> new
> >>>>>>>>>>>> > > _allocation_end. However, during initial
> reviews
> >>>>>>> of
> >>>>>>>>>>>> JEP-331
> >>>>>>>>>>>> > it was
> >>>>>>>>>>>> > > deemed complicated to understand:
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> > > _end -> the _end or sampling end
> >>>>>>>>>>>> > > _allocation_end -> end pointer for the
> last
> >>>>>>> possible
> >>>>>>>>>>>> allocation
> >>>>>>>>>>>> > > hard_end -> allocation end + reserved
> space
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> > > That is how this naming came up and why
> hard_end
> >>>>>>>>> went
> >>>>>>>>>>> to
> >>>>>>>>>>>> > "reserved_end".
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> > > I'm really indifferent, so I offer as a
> perusal:
> >>>>>>>>>>>> > >
> >>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> > > I noticed a few problems of alignement
> of '{' so
> >>>>>>>>> I'll
> >>>>>>>>>>>> go fix
> >>>>>>>>>>>> > that.
> >>>>>>>>>>>> > > Basically this webrev does the following:
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> > > - Uses fast_path_end instead of end
> >>>>>>>>>>>> > > - Reverts hard_end back to where it was
> >>>>>>>>>>>> > > - Adds the changes to Graal; there is a
> bunch of
> >>>>>>>>>>>> changes in Graal
> >>>>>>>>>>>> > > because Graal still contains a bit of
> code doing
> >>>>>>>>>>>> fasttlabrefills.
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> > > Let me know what you think!
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> > > Thanks,
> >>>>>>>>>>>> > > Jc
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> > > On Tue, Apr 10, 2018 at 6:56 AM Karen
> Kinnear
> >>>>>>>>>>>> > > <karen.kinnear at oracle.com
> >>>>>>>>>>>> <mailto:karen.kinnear at oracle.com> <mailto:
> >>>>>>>>> karen.kinnear at oracle.com
> >>>>>>>>>>>> <mailto:karen.kinnear at oracle.com>>
> >>>>>>>>>>>> > <mailto:karen.kinnear at oracle.com
> >>>>>>>>>>>> <mailto:karen.kinnear at oracle.com> <mailto:
> >>>>>>>>> karen.kinnear at oracle.com
> >>>>>>>>>>>> <mailto:karen.kinnear at oracle.com>>>>
> >>>>>>>>>>>> > wrote:
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> > > Hi JC,
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> > > A comment about Graal. The impact on
> Graal
> >>>>>>> for
> >>>>>>>>> this
> >>>>>>>>>>>> > particular
> >>>>>>>>>>>> > > change would be to break it - so
> you?ll need
> >>>>>>>>>>>> > > to complete the Graal changes for
> this
> >>>>>>> renaming.
> >>>>>>>>>>>> That isn?t
> >>>>>>>>>>>> > > optional or something that could be a
> >>>>>>>>> follow-on. It
> >>>>>>>>>>>> > > is not ok to break a feature, even an
> >>>>>>>>> experimental
> >>>>>>>>>>>> one.
> >>>>>>>>>>>> > We will
> >>>>>>>>>>>> > > discuss in the other thread potential
> >>>>>>> phasing of
> >>>>>>>>>>>> adding
> >>>>>>>>>>>> > sampling.
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> > > I did not do a thorough search -you
> can do
> >>>>>>> that
> >>>>>>>>> -
> >>>>>>>>>>>> I did find
> >>>>>>>>>>>> > > src/jdk.internal.vm.compiler/share/classes/
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> > > public final int threadTlabOffset =
> >>>>>>>>>>>> > > getFieldOffset("Thread::_tlab",
> >>>>>>> Integer.class,
> >>>>>>>>>>>> > > "ThreadLocalAllocBuffer");
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> > > private final int
> >>>>>>>>>>>> threadLocalAllocBufferStartOffset =
> >>>>>>>>>>>> > >
> >>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_start",
> >>>>>>>>>>>> > Integer.class,
> >>>>>>>>>>>> > > "HeapWord*");
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> > > private final int
> >>>>>>>>>>> threadLocalAllocBufferEndOffset =
> >>>>>>>>>>>> > >
> >>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_end",
> >>>>>>>>>>>> Integer.class,
> >>>>>>>>>>>> > > "HeapWord*");
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> > > private final int
> >>>>>>>>>>> threadLocalAllocBufferTopOffset =
> >>>>>>>>>>>> > >
> >>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_top",
> >>>>>>>>>>>> Integer.class,
> >>>>>>>>>>>> > > "HeapWord*");
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> > > private final int
> >>>>>>>>>>>> threadLocalAllocBufferPfTopOffset =
> >>>>>>>>>>>> > >
> >>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_pf_top",
> >>>>>>>>>>>> > Integer.class,
> >>>>>>>>>>>> > > "HeapWord*");
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> > > private final int
> >>>>>>>>>>>> > threadLocalAllocBufferSlowAllocationsOffset
> >>>>>>>>>>>> > > =
> >>>>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
> >>>>>>>>>>>> > > Integer.class, "unsigned");
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> > > private final int
> >>>>>>>>>>>> > threadLocalAllocBufferFastRefillWasteOffset
> >>>>>>>>>>>> > > =
> >>>>>>>>>>>> >
> >>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
> >>>>>>>>>>>> > > Integer.class, "unsigned");
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> > > private final int
> >>>>>>>>>>>> > threadLocalAllocBufferNumberOfRefillsOffset
> >>>>>>>>>>>> > > =
> >>>>>>>>>>>> >
> >>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
> >>>>>>>>>>>> > > Integer.class, "unsigned");
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> > > private final int
> >>>>>>>>>>>> > > threadLocalAllocBufferRefillWasteLimitOffset
> >>>>>>> =
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
> >>>>>>>>>>>> > > Integer.class, "size_t");
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> > > private final int
> >>>>>>>>>>>> > threadLocalAllocBufferDesiredSizeOffset =
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
> >>>>>>>>>>>> > > Integer.class, "size_t");
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> > > public final int tlabAlignmentReserve =
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
> >>>>>>>>>>>> > > Integer.class, "size_t?);
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> > > hope this helps,
> >>>>>>>>>>>> > > Karen
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> > >> On Apr 10, 2018, at 7:04 AM, Stefan
> >>>>>>> Johansson
> >>>>>>>>>>>> > >> <stefan.johansson at oracle.com
> >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com>
> >>>>>>>>>>>> > <mailto:stefan.johansson at oracle.com
> >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com>>
> >>>>>>>>>>>> > >> <mailto:stefan.johansson at oracle.com
> >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com>
> >>>>>>>>>>>> > <mailto:stefan.johansson at oracle.com
> >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com>>>> wrote:
> >>>>>>>>>>>> > >>
> >>>>>>>>>>>> > >> Hi JC,
> >>>>>>>>>>>> > >>
> >>>>>>>>>>>> > >> I realize that the names have been
> discussed
> >>>>>>>>>>>> before but I'm
> >>>>>>>>>>>> > >> leaning towards suggesting
> something new. We
> >>>>>>>>>>>> discussed this
> >>>>>>>>>>>> > >> briefly here in the office and
> others might
> >>>>>>>>> have
> >>>>>>>>>>>> different
> >>>>>>>>>>>> > >> opinions. One point that came up is
> that if
> >>>>>>> we
> >>>>>>>>> do
> >>>>>>>>>>>> this
> >>>>>>>>>>>> > change
> >>>>>>>>>>>> > >> and change all usages of
> >>>>>>>>>>>> JavaThread::tlab_end_offset() it
> >>>>>>>>>>>> > >> would be good to make sure the new
> name is
> >>>>>>>>> good.
> >>>>>>>>>>>> To us
> >>>>>>>>>>>> > >> _current_end is not very descriptive, but
> >>>>>>>>> naming
> >>>>>>>>>>>> is hard and
> >>>>>>>>>>>> > >> the best we could come up with is
> >>>>>>>>> _fast_path_end
> >>>>>>>>>>>> which would
> >>>>>>>>>>>> > >> give the code:
> >>>>>>>>>>>> > >> cmpptr(end, Address(thread,
> >>>>>>>>>>>> > >> JavaThread::tlab_fast_path_end_offset()));
> >>>>>>>>>>>> > >> jcc(Assembler::above, slow_case);
> >>>>>>>>>>>> > >>
> >>>>>>>>>>>> > >> I think this reads pretty good and
> is fairly
> >>>>>>>>>>>> clear. If we do
> >>>>>>>>>>>> > >> this rename I think you can re-use
> _end in
> >>>>>>>>> JEP-331
> >>>>>>>>>>>> > instead of
> >>>>>>>>>>>> > >> calling it _allocation_end. But
> that is a
> >>>>>>> later
> >>>>>>>>>>>> review :)
> >>>>>>>>>>>> > >>
> >>>>>>>>>>>> > >> Also, is there a good reason for
> renaming
> >>>>>>>>>>>> hard_end() to
> >>>>>>>>>>>> > >> reserved_end()?
> >>>>>>>>>>>> > >>
> >>>>>>>>>>>> > >> One additional thing, you need to
> update
> >>>>>>> the SA
> >>>>>>>>>>>> to reflect
> >>>>>>>>>>>> > >> this change. I think the only place
> you
> >>>>>>> need to
> >>>>>>>>>>>> fix is in:
> >>>>>>>>>>>> > >>
> >>>>>>>>>>>> >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
> >>>>>>>>>>>> > >>
> >>>>>>>>>>>> > >> Thanks,
> >>>>>>>>>>>> > >> Stefan
> >>>>>>>>>>>> > >>
> >>>>>>>>>>>> > >> On 2018-04-09 19:24, JC Beyler
> wrote:
> >>>>>>>>>>>> > >>> Hi all,
> >>>>>>>>>>>> > >>> Small pre-amble to this request:
> >>>>>>>>>>>> > >>> In my work to try to get a heap
> sampler in
> >>>>>>>>>>>> OpenJDK (via JEP
> >>>>>>>>>>>> > >>> 331
> >>>>>>>>>>>> > <https://bugs.openjdk.java.net/browse/JDK-8171119
> >),
> >>>>>>> I'm
> >>>>>>>>>>>> > >>> trying to reduce the footprint of my
> >>>>>>> change so
> >>>>>>>>>>>> that the
> >>>>>>>>>>>> > >>> integration can be easier. I was told that
> >>>>>>>>>>>> generally a JEP
> >>>>>>>>>>>> > >>> webrev should be feature complete
> and go in
> >>>>>>>>>>> at-once.
> >>>>>>>>>>>> > However,
> >>>>>>>>>>>> > >>> with the change touching quite a
> bit of
> >>>>>>>>> various
> >>>>>>>>>>> code
> >>>>>>>>>>>> > pieces,
> >>>>>>>>>>>> > >>> I was trying to figure out what
> could be
> >>>>>>>>>>>> separated as not
> >>>>>>>>>>>> > >>> "part of the feature".
> >>>>>>>>>>>> > >>> I asked around and said that
> perhaps a
> >>>>>>>>> solution
> >>>>>>>>>>>> would be to
> >>>>>>>>>>>> > >>> cut up the renaming of TLAB's end
> field
> >>>>>>> that I
> >>>>>>>>>>>> do in that
> >>>>>>>>>>>> > >>> webrev. Because I'm renaming a
> field in
> >>>>>>> TLAB
> >>>>>>>>>>> used by
> >>>>>>>>>>>> > various
> >>>>>>>>>>>> > >>> backends for that work, I have to update
> >>>>>>> every
> >>>>>>>>>>>> architecture
> >>>>>>>>>>>> > >>> dependent code to reflect it.
> >>>>>>>>>>>> > >>> I entirely understand that perhaps
> this is
> >>>>>>> not
> >>>>>>>>>>>> in the
> >>>>>>>>>>>> > habits
> >>>>>>>>>>>> > >>> and very potentially might not be
> the way
> >>>>>>>>> things
> >>>>>>>>>>> are
> >>>>>>>>>>>> > >>> generally done. If so, I apologize and
> let
> >>>>>>> me
> >>>>>>>>>>>> know if you
> >>>>>>>>>>>> > >>> would not want this to go in
> separately :)
> >>>>>>>>>>>> > >>> Final note: there is still a
> chance JEP-331
> >>>>>>>>> does
> >>>>>>>>>>>> not go in.
> >>>>>>>>>>>> > >>> If it does not, we can leave the
> new name
> >>>>>>> in
> >>>>>>>>>>>> place or I'll
> >>>>>>>>>>>> > >>> happily revert it. I can even
> create an
> >>>>>>> issue
> >>>>>>>>> to
> >>>>>>>>>>>> track this
> >>>>>>>>>>>> > >>> if that makes it easier for all.
> >>>>>>>>>>>> > >>> End of the pre-amble.
> >>>>>>>>>>>> > >>> The 33-line change webrev in
> question is
> >>>>>>> here:
> >>>>>>>>>>>> > >>>
> >>>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
> >>>>>>>>>>>> > >>> I fixed all the architectures and JVMCI
> and
> >>>>>>>>> ran
> >>>>>>>>>>>> a few
> >>>>>>>>>>>> > sanity
> >>>>>>>>>>>> > >>> tests to ensure I had not missed
> anything.
> >>>>>>>>>>>> > >>> Thanks for your help and I hope
> this is not
> >>>>>>>>> too
> >>>>>>>>>>> much
> >>>>>>>>>>>> > trouble,
> >>>>>>>>>>>> > >>> Jc
> >>>>>>>>>>>> > >>> Ps: there is a graal change that
> needs to
> >>>>>>>>> happen
> >>>>>>>>>>>> but I was
> >>>>>>>>>>>> > >>> not sure who/where
> <https://teams.googleplex.com/u/where>
> >>>>>>> <https://teams.googleplex.com/u/where>
> >>>>>>>>> <https://teams.googleplex.com/u/where>
> >>>>>>>>>>> <https://teams.googleplex.com/u/where>
> >>>>>>>>>>>> <https://teams.googleplex.com/u/where>
> >>>>>>>>>>>> > <https://teams.googleplex.com/u/where>
> >>>>>>>>>>>> > <https://teams.googleplex.com/u/where> to
> >>>>>>>>>>>> > >>> ask about it. I was told it could
> happen
> >>>>>>> in a
> >>>>>>>>>>>> separate
> >>>>>>>>>>>> > >>> webrev. Can anyone point me to the
> right
> >>>>>>>>>>> direction?
> >>>>>>>>>>>> > Should it
> >>>>>>>>>>>> > >>> just be hotspot-compiler-dev?
> >>>>>>>>>>>> > >
> >>>>>>>>>>>> >
> >>>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>
> >
>
From vladimir.kozlov at oracle.com Wed Apr 18 22:06:42 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 18 Apr 2018 15:06:42 -0700
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
fast_path_end
In-Reply-To: <CAF9BGBypU+AexV5vt-mJD5rLAqxfORwYa0f16s9iWwRhF2Z+3w@mail.gmail.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
<CAF9BGByXChhNFD18BEeQUA3PndBRWG=8XAJ_MAJWQv0XSLnR4g@mail.gmail.com>
<5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
<CAF9BGBxEPXLTiyD-xG_ECyveyW0PXQL0+-z7jkw3Rv4QrkkszQ@mail.gmail.com>
<ec1a3e0e-ca9b-8668-b260-1fd3e612b7f7@oracle.com>
<CAF9BGBy-LBKCwJHQPdAQ65VRcSFBwVkk9dm8MLC_nrefE_JdEw@mail.gmail.com>
<e6528c19-5691-1215-1ac5-0349801b79b5@oracle.com>
<CAF9BGBwBgyOoJTfJU_YmqYJgSZ+1985yx_sSMJC4wNJELw1XDQ@mail.gmail.com>
<e63675e1-d693-cd25-75b2-32b593e266a2@oracle.com>
<CAF9BGBz3g4yXMjf9TxrqLdMbfaswoa3U13qYTEUtv-mZCDMd8Q@mail.gmail.com>
<735b3949-d9cd-3d37-ebb4-f59ee61f18ad@oracle.com>
<ba26dc77-a5ba-b490-2a03-cf4abd79ac3c@oracle.com>
<ff9474cd-6f07-446c-12b5-2dafbca35ce3@oracle.com>
<19c34a75-e1f5-f1b2-2cd7-91300e7979c3@oracle.com>
<30260bf8-765b-3227-87c0-85f001ca4c55@oracle.com>
<129b0875-52e8-eabc-258a-5ad4f36aa226@oracle.com>
<CAF9BGBypU+AexV5vt-mJD5rLAqxfORwYa0f16s9iWwRhF2Z+3w@mail.gmail.com>
Message-ID: <b0699a0d-80c8-4bd1-3fd5-c8ac60b75e90@oracle.com>
On 4/18/18 2:54 PM, JC Beyler wrote:
> Seems like there is no consensus really except that changing it has a few headaches involved. Should
> we then do the implementation of "8171119: Low-Overhead HeapProfiling" without changing the _end
> field and postpone this conversation to afterwards when Graal handles multi-release in a more
> mature?manner (read has been doing it for a while).
I would prefer this way.
Thanks,
Vladimir
>
> Or is there still a path forward? (Re)Naming is hard, this is proof of that.
>
> That puts us back to what I had originally:
> _end: the fast path end, can be the allocation end or the to-be-sampled end
> _allocation_end: the actual allocation end of the current TLAB
> hard_end: _allocation_end?+ reserved space
>
> Thanks for all of your input and help on this,
> Jc
>
> On Wed, Apr 18, 2018 at 12:46 PM Vladimir Kozlov <vladimir.kozlov at oracle.com
> <mailto:vladimir.kozlov at oracle.com>> wrote:
>
> On 4/18/18 12:15 PM, dean.long at oracle.com <mailto:dean.long at oracle.com> wrote:
> > I will defer to Vladimir, but I would have been happy with something like:
> >
> > // preserve simple start/end abstraction for compiler
> > HeapWord* end() const ? ? ?? { return fast_path_end(); }
> > static ByteSize end_offset() { return fast_path_end_offset(); }
>
> This is ugly.
>
> >
> > even though end_offset() would then refer to a virtual "end" field.
> >
> > Vladimir, are you also approving the Graal changes? :-)
>
> You really made my day :(
>
> S..t! We can't make this change in Graal as suggested because we will break Graal's JDK 8 support.
> Graal has direct access to VM's fields through JVMCI. You have to guard change with JDK version
> check.
>
> Labs start addressing multi-releases so it may be not big issue anymore. See Doug's comment for
> 8201318 RFR.
>
> Anyway you have to file new PR (pull request) for Graal changes on
> https://github.com/graalvm/mx/pulls.
> And I am not sponsoring this. I don't think such renaming worse all our efforts.
>
> Good luck,
> Vladimir
>
> >
> > dl
> >
> > On 4/18/18 11:02 AM, Vladimir Kozlov wrote:
> >> Ganging up on us ;)
> >>
> >> Yes, I missed original discussion about renaming on GC list.
> >>
> >> From my point of view next code looks better because it seems compare related values:
> >>
> >> cmpptr(end, Address(thread, JavaThread::tlab_end_offset()));
> >>
> >> But I would not strongly object renaming to move this JEP forward. Consider changes reviewed
> and approved by me.
> >>
> >> Regards,
> >> Vladimir
> >>
> >> On 4/18/18 6:29 AM, Daniel D. Daugherty wrote:
> >>> Greetings,
> >>>
> >>> The idea of splitting this change off from "8171119: Low-Overhead Heap Profiling"
> >>> came up during the design review. It might have been me that suggested the split
> >>> off or it was someone else. Sorry I don't remember.
> >>>
> >>> In any case, the rename of "end" to "fast_path_end" is just a clarity change to
> >>> the existing code and I think that change can easily stand on its own. That is
> >>> particularly true if the accessors are renamed at the same time. I think having
> >>> the accessor names match the field names is a pretty well known HotSpot rule
> >>> so I'm not sure why we're talking about not renaming the accessors...
> >>>
> >>> Personally, I prefer "_fast_path_end" over "_current_end".
> >>>
> >>> Dan
> >>>
> >>>
> >>> On 4/18/18 4:04 AM, Stefan Johansson wrote:
> >>>> Hi,
> >>>>
> >>>> On 2018-04-18 02:02, Vladimir Kozlov wrote:
> >>>>> ?> I think I like better not to add it. If no one is using it, there should be
> >>>>> ?> no reason to add it? By not adding it, it also makes any future wish to
> >>>>> ?> have it a nice indicator of: hey why do you want to see this? Same as
> >>>>> ?> hard_end btw which is not visible. Am I missing something?
> >>>>>
> >>>>> I say "may" ;)
> >>>>> You don't need new function if there is no use.
> >>>>>
> >>>>> ?>
> >>>>> ?> So to summarize, the current consensus:
> >>>>> ?>??? - _end can be renamed either to _current_end or _fast_path_end; that is
> >>>>> ?> still up to a vote and choice :)
> >>>>>
> >>>>> Please, use _current_end. I was thinking about _sample_end but it does not reflect double
> usage.
> >>>>
> >>>> I'm not sure if you have seen the discussion about naming on hotspot-gc-dev, but I and
> others think that
> >>>> _current_end doesn't describe the usage at all. Naming it _fast_path_end would clearly
> state what it is, _sample_end
> >>>> or something similar also crossed my mind but I think the code reads a lot better in the
> compiler with the name
> >>>> fast_path_end.
> >>>>
> >>>>>
> >>>>> ?>??? - the access method end() and tlab_end_offset() remain the same to not
> >>>>> ?> modify JIT/interpreter codes
> >>>> I would find this very unfortunate, having accessors that don't match the members can
> easily lead to
> >>>> misunderstanding, especially if we have three different *_end members. Why do you think
> this is the best way forward?
> >>>>
> >>>> My first thought was also that it would be nice to avoid all the compiler changes, but
> then we would have to stick
> >>>> with _end being the sample/current/fast-path end and I'm not sure that is a better
> solution. I don't see the big
> >>>> problem with changing those accessors to what they really access and I think the compiler
> code reads good even after
> >>>> the change. For example:
> >>>> cmpptr(end, Address(thread, JavaThread::tlab_fast_path_end_offset()));
> >>>> jcc(Assembler::above, slow_case);
> >>>>
> >>>>> ?>
> >>>>> ?> If all agree to this, then the consequences are:
> >>>>> ?>??? - JDK-8201326 becomes useless
> >>>>> ?>??? - The work for JEP-331 becomes smaller in terms of file changes
> >>>>> ?>??? - I'll still be needing a decision on the renaming of the TLAB _end field
> >>>>> ?> (current suggestions are _current_end and _fast_path_end).
> >>>>
> >>>> We'll see where we end up. If JDK-8201326 ends up being a separate change I think it
> should be pushed at the same
> >>>> time as the rest of the JEP changes. To me it only makes sense to have it in the code base
> if we also have the rest
> >>>> of the changes.
> >>>>
> >>>> Thanks,
> >>>> Stefan
> >>>>
> >>>>>
> >>>>> Sounds good to me.
> >>>>>
> >>>>> Thanks,
> >>>>> Vladimir
> >>>>>
> >>>>> On 4/17/18 4:51 PM, JC Beyler wrote:
> >>>>>> Hi Vladimir and Dean,
> >>>>>>
> >>>>>> @Dean: seems that Vladimir is in agreement with you for renaming just the
> >>>>>> field and not the method names so ack to your answer that came at the same
> >>>>>> time :)
> >>>>>>
> >>>>>>
> >>>>>>> Yes, from the beginning such changes should be discussed on common
> >>>>>>> hotspot-dev list since all
> >>>>>>> Hotspot's parts are affected.
> >>>>>>>
> >>>>>>
> >>>>>> Sorry, being new to the scene, most of the conversation had been going on
> >>>>>> in serviceability-dev.
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Graal specific question could be send to hotspot-compiler-dev list with
> >>>>>>> [Graal] in subject.
> >>>>>>>
> >>>>>>> I looked on JEP's changes
> >>>>>>> http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.02/ to understand how
> >>>>>>> it works.
> >>>>>>>
> >>>>>>> Few questions about proposed JEP changes so I can understand it.
> >>>>>>>
> >>>>>>> You introducing new TLAB end for sampling and adjust it so that
> >>>>>>> allocations in JITed code and
> >>>>>>> Interpreter it will trigger slow path allocation where you do sampling.
> >>>>>>> Right?
> >>>>>>>
> >>>>>>
> >>>>>> Yes that is correct; if sampling is enabled of course. Btw, this is the current
> >>>>>> webrev <http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.15/>.
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Do all changes to _end, _actual_end and other TLAB fields happen during
> >>>>>>> slow allocation?
> >>>>>>>
> >>>>>>
> >>>>>> Yes, to that effect, with Robbin's help, we finalized deprecating the
> >>>>>> FastTLabRefill via JDK-8194084
> >>>>>> <https://bugs.openjdk.java.net/browse/JDK-8194084>. Seems like I/we missed
> >>>>>> that Graal does this as well. I filed GRAAL-64
> >>>>>> <https://bugs.openjdk.java.net/browse/GRAAL-64> to not forget that Graal
> >>>>>> would need to get that fixed.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> I am concern about concurrent accesses to these fields from other threads
> >>>>>>> if you have them (I don't
> >>>>>>> see).
> >>>>>>>
> >>>>>>
> >>>>>> Yes that is why we deprecated the FastTlabRefill. Other threads should not
> >>>>>> be changing the thread local data structure so I don't see an issue there.
> >>>>>> The major issue was that the fast paths could change the tlab without going
> >>>>>> via the slowpath.
> >>>>>>
> >>>>>> I had a fix to detect this issue but removed it once JDK-8194084 was done;
> >>>>>> Graal was missed in that work so that is why if sampling were enabled with
> >>>>>> Graal, there is a chance things would break currently. That will get fixed
> >>>>>> via GRAAL-64 <https://bugs.openjdk.java.net/browse/GRAAL-64> whether it is
> >>>>>> rendering the code also obsolete and going to the slowpath or whether it is
> >>>>>> adding my fix again to detect a fastpath TLAB reallocation happened.
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Renaming. I am fine with renaming if it helps to understand code better. I
> >>>>>>> agree with proposed
> >>>>>>> changes to fields name:
> >>>>>>>
> >>>>>>> _current_end
> >>>>>>> _allocation_end
> >>>>>>>
> >>>>>>> But, as Dean, I would suggest to keep names of access functions. This way
> >>>>>>> we can say that allocation
> >>>>>>> code in Interpreter and JITed code stay the same.
> >>>>>>>
> >>>>>>
> >>>>>> Sounds good to me, then in that case, this webrev will disappear, which
> >>>>>> also makes me happy, since it simplifies a lot of things (and reduces code
> >>>>>> change).
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> You may need only new method to access _allocation_end in places which
> >>>>>>> look for real end of TLAB.
> >>>>>>>
> >>>>>>
> >>>>>> I think I like better not to add it. If no one is using it, there should be
> >>>>>> no reason to add it? By not adding it, it also makes any future wish to
> >>>>>> have it a nice indicator of: hey why do you want to see this? Same as
> >>>>>> hard_end btw which is not visible. Am I missing something?
> >>>>>>
> >>>>>> So to summarize, the current consensus:
> >>>>>> ?? - _end can be renamed either to _current_end or _fast_path_end; that is
> >>>>>> still up to a vote and choice :)
> >>>>>> ?? - the access method end() and tlab_end_offset() remain the same to not
> >>>>>> modify JIT/interpreter codes
> >>>>>>
> >>>>>> If all agree to this, then the consequences are:
> >>>>>> ?? - JDK-8201326 becomes useless
> >>>>>> ?? - The work for JEP-331 becomes smaller in terms of file changes
> >>>>>> ?? - I'll still be needing a decision on the renaming of the TLAB _end field
> >>>>>> (current suggestions are _current_end and _fast_path_end).
> >>>>>>
> >>>>>> Thanks for your help!
> >>>>>> Jc
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Vladimir
> >>>>>>>
> >>>>>>> On 4/16/18 4:42 PM, JC Beyler wrote:
> >>>>>>>> Hi Dean,
> >>>>>>>>
> >>>>>>>> I think perhaps this is also an attempt to figure out the naming of all
> >>>>>>>> this because naming (or renaming like here) is often the start of big
> >>>>>>>> conversations :).
> >>>>>>>>
> >>>>>>>> Originally, in the JEP-331 work, I had left the _end field as is and, by
> >>>>>>>> doing so, this whole renaming webrev goes away. However, if we do that,
> >>>>>>>> then the TLAB code contains:
> >>>>>>>>
> >>>>>>>> _end: the fast path end, can be the allocation end or the to-be-sampled
> >>>>>>> end
> >>>>>>>> _allocation_end: the actual allocation end of the current TLAB
> >>>>>>>> hard_end: _allocation_end + reserved space
> >>>>>>>>
> >>>>>>>> With an early iteration of a webrev for JEP-331, a conversation occurred
> >>>>>>>> about whether or not that was clear or not and it was determined that
> >>>>>>> this
> >>>>>>>> renaming was more clear:
> >>>>>>>>
> >>>>>>>> _current_end: the fast path end
> >>>>>>>> _allocation_end: the actual allocation end of the current TLAB
> >>>>>>>> reserved_end: _allocation_end + reserved space
> >>>>>>>>
> >>>>>>>> Because I'm trying to reduce the footprint of files changed, I pulled out
> >>>>>>>> the renaming changes into this webrev. While talking about it with the GC
> >>>>>>>> team, the renaming suggested became:
> >>>>>>>>
> >>>>>>>> _fast_path_end: the fast path end
> >>>>>>>> _allocation_end: the actual allocation end of the current TLAB
> >>>>>>>> hard_end: _allocation_end + reserved space
> >>>>>>>>
> >>>>>>>> Now, to be honest, any renaming or no renaming is fine by me. I like not
> >>>>>>>> renaming the fields to not change the code of every backend and Graal; I
> >>>>>>>> also like the fast_path_end rename due to it making the backend code easy
> >>>>>>>> to read as mentioned in the GC mailing lis thread.
> >>>>>>>>
> >>>>>>>> So there are two questions really:
> >>>>>>>> ???? - Should we rename the _end field and thus provoke the changes in
> >>>>>>> this
> >>>>>>>> webrev?
> >>>>>>>> ???? - If we do want to change the field, should/could it go in an initial
> >>>>>>>> webrev or should it go in the JEP-331 webrev whenever/ifever it goes in?
> >>>>>>>> And if we do wait, could we at least converge on a renaming now so that
> >>>>>>>> this does not become a point of contention for that webrev's review?
> >>>>>>>>
> >>>>>>>> If I read your answer correctly:
> >>>>>>>> ?????? - You are saying that we should keep the _end field altogether; or
> >>>>>>> at
> >>>>>>>> least only rename the field not the methods to access it, thus reducing
> >>>>>>> the
> >>>>>>>> change scope.
> >>>>>>>> ?????? - You are also saying to wait for the JEP-331 webrev's final
> >>>>>>> iteration
> >>>>>>>> and integrate it in one step
> >>>>>>>>
> >>>>>>>> Have I understood your answer correctly?
> >>>>>>>>
> >>>>>>>> Again, I am fine with renaming to whatever or not renaming at all. I just
> >>>>>>>> am trying to get forward progress here :)
> >>>>>>>>
> >>>>>>>> Thanks for your help!
> >>>>>>>> Jc
> >>>>>>>>
> >>>>>>>> On Mon, Apr 16, 2018 at 3:29 PM <dean.long at oracle.com <mailto:dean.long at oracle.com>>
> wrote:
> >>>>>>>>
> >>>>>>>>> Hi JC.? Others might disagree, but I would vote "no" on doing this
> >>>>>>>>> renaming now, before the JEP, and even in the context of the JEP, I
> >>>>>>>>> don't think renaming the field requires renaming all the uses.? The
> >>>>>>>>> compiler code is only interested in the fast path, so it's implicitly
> >>>>>>>>> understood.? Also, if there is a fast_path_end(), then isn't it logical
> >>>>>>>>> to have fast_path_start() paired with it?? ("start" is already
> >>>>>>>>> overloaded, but nobody is suggesting adding
> >>>>>>>>> allocation_start()/current_start()/hard_start() are they?).? My opinion
> >>>>>>>>> is that it's fine the way it is.
> >>>>>>>>>
> >>>>>>>>> dl
> >>>>>>>>>
> >>>>>>>>> On 4/16/18 1:43 PM, JC Beyler wrote:
> >>>>>>>>>> Hi all,
> >>>>>>>>>>
> >>>>>>>>>> I've left the mail thread from the hotspot-gc-dev below for tracking
> >>>>>>>>>> purposes but will start a new request here.
> >>>>>>>>>>
> >>>>>>>>>> - I'm trying to push a renaming of a TLAB field to make my work for
> >>>>>>>>> JEP-331
> >>>>>>>>>> <http://openjdk.java.net/jeps/331> easier
> >>>>>>>>>> ????? - There is an understanding that if JEP-331 does not make it, this
> >>>>>>>>> might
> >>>>>>>>>> be useless and I'll revert if that is what the community wants; however
> >>>>>>>>> the
> >>>>>>>>>> new name seems better anyway so perhaps not?
> >>>>>>>>>>
> >>>>>>>>>> - The webrev renames a field used across the various back-ends and
> >>>>>>> Graal
> >>>>>>>>>> ????? - The webrev is here:
> >>>>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.04/
> >>>>>>>>>>
> >>>>>>>>>> Could I please get some feedback on this?
> >>>>>>>>>>
> >>>>>>>>>> Thanks all for your help,
> >>>>>>>>>> Jc
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Apr 13, 2018 at 2:37 AM Stefan Johansson <
> >>>>>>>>>> stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hi JC,
> >>>>>>>>>>>
> >>>>>>>>>>> I don't have a name, but I've looked at bit more at the failures and I
> >>>>>>>>>>> think they are unrelated and one of the local compiler engineers
> >>>>>>> agree.
> >>>>>>>>>>>
> >>>>>>>>>>> I also ran some local testing and was not able to get any error with
> >>>>>>> you
> >>>>>>>>>>> latest changes, but verified that it doens't work without the graal
> >>>>>>>>>>> parts. So they seem good. It might still be good to switch this over
> >>>>>>> to
> >>>>>>>>>>> the general hotspot-dev list to let someone with Graal knowledge to
> >>>>>>> look
> >>>>>>>>>>> at the change and make sure everything is correct.
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>> Stefan
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On 2018-04-12 17:26, JC Beyler wrote:
> >>>>>>>>>>>> Hi Stefan,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks for testing :). I've renamed the bug title in the JBS and will
> >>>>>>>>>>>> emit a new webrev shortly. Do you have the name of a compiler
> >>>>>>> engineer
> >>>>>>>>>>>> in mind or should I perhaps now move this conversation to the general
> >>>>>>>>>>>> hotspot-dev mailing list and ask there?
> >>>>>>>>>>>>
> >>>>>>>>>>>> The alternative is to add the compiler-mailing list to this email
> >>>>>>>>> thread
> >>>>>>>>>>>> and ask there before sending to the general list. What do you think
> >>>>>>> is
> >>>>>>>>>>> best?
> >>>>>>>>>>>> Thanks for all your help,
> >>>>>>>>>>>> Jc
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Thu, Apr 12, 2018 at 2:09 AM Stefan Johansson
> >>>>>>>>>>>> <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>
> <mailto:stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> ?????? On 2018-04-11 17:48, JC Beyler wrote:
> >>>>>>>>>>>> ??????? > Hi Stefan,
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>> ??????? > Sorry about that, I must have missed adding the files or
> >>>>>>>>>>>> ?????? something. Here
> >>>>>>>>>>>> ??????? > is a webrev that added the changes for the SA file:
> >>>>>>>>>>>> ??????? > http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>> ?????? No problem, this looks good. I kicked of a run in our test
> >>>>>>> system
> >>>>>>>>> to
> >>>>>>>>>>>> ?????? get
> >>>>>>>>>>>> ?????? some more coverage and have tried to include some Graal
> >>>>>>> testing.
> >>>>>>>>> I'll
> >>>>>>>>>>>> ?????? let you know the results once they are done.
> >>>>>>>>>>>>
> >>>>>>>>>>>> ?????? Please also update the bug title both in JBS and the changeset.
> >>>>>>>>>>>>
> >>>>>>>>>>>> ?????? Cheers,
> >>>>>>>>>>>> ?????? Stefan
> >>>>>>>>>>>>
> >>>>>>>>>>>> ??????? > I changed the method name, which propagated a change to:
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>> ??????? > I tried testing your test file. It exists in my branch (if
> >>>>>>> the
> >>>>>>>>>>>> ?????? same) under:
> >>>>>>>>>>>> ??????? > hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>> ??????? > and interestingly (which generally means I did something
> >>>>>>>>> wrong),
> >>>>>>>>>>> it
> >>>>>>>>>>>> ??????? > passed before/after the change so I could not verify that
> >>>>>>> this
> >>>>>>>>> is
> >>>>>>>>>>>> ?????? a test
> >>>>>>>>>>>> ??????? > showing that all is well in the world on my side. Any ideas
> >>>>>>> of
> >>>>>>>>>>>> ?????? what I
> >>>>>>>>>>>> ??????? > did wrong?
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>> ??????? > I did again test it for hotspot/jtreg/compiler/aot/ and
> >>>>>>>>>>>> ??????? > hotspot/jtreg/serviceability/jvmti and it passes those.
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>> ??????? > Thanks for all your help,
> >>>>>>>>>>>> ??????? > Jc
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>> ??????? > On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson
> >>>>>>>>>>>> ??????? > <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com> <mailto:
> >>>>>>>>> stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>>
> >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>
> >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>>>> wrote:
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>> ??????? >???? Hi JC,
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>> ??????? >???? On 2018-04-11 00:56, JC Beyler wrote:
> >>>>>>>>>>>> ??????? >????? > Small update:
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >????? > Here is the fixed webrev for the '{' that were out of
> >>>>>>>>>>>> ?????? alignment.
> >>>>>>>>>>>> ??????? >???? This
> >>>>>>>>>>>> ??????? >????? > passed release build JTREG
> >>>>>>>>>>>> ?????? for hotspot/jtreg/compiler/jvmti (just
> >>>>>>>>>>>> ??????? >???? to run
> >>>>>>>>>>>> ??????? >????? > something as a smoke screen)
> >>>>>>>>>>>> ?????? and hotspot/jtreg/compiler/aot/ (to
> >>>>>>>>>>>> ??????? >???? test
> >>>>>>>>>>>> ??????? >????? > Graal).
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >???? I think this looks better, I agree that leaving _end is
> >>>>>>>>>>>> ?????? tempting to
> >>>>>>>>>>>> ??????? >???? avoid a lot of change, but I think this will be better
> >>>>>>> in
> >>>>>>>>> the
> >>>>>>>>>>>> ?????? long run.
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>> ??????? >???? I still miss the changes to make the SA work. To see a
> >>>>>>>>>>>> ?????? problem you
> >>>>>>>>>>>> ??????? >???? can run:
> >>>>>>>>>>>> ??????? >???? make CONF=fast run-test
> >>>>>>>>>>>> ??????? >
> >>>>>>>>> TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>> ??????? >???? Cheers,
> >>>>>>>>>>>> ??????? >???? Stefan
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>> ??????? >????? > Let me know what you think,
> >>>>>>>>>>>> ??????? >????? > Jc
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >????? > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler
> >>>>>>>>>>>> ?????? <jcbeyler at google.com <mailto:jcbeyler at google.com>
> <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>
> >>>>>>>>>>>> ??????? > <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>
> <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>
> >>>>>>>>>
> >>>>>>>>>>>> ??????? >????? > <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com> <mailto:
> >>>>>>> jcbeyler at google.com <mailto:jcbeyler at google.com>
> >>>>>>>>>>
> >>>>>>>>>>>> <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>
> <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >????? >???? Hi Karen and Stefan,
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >????? >???? @Stefan: Naming is hard :)
> >>>>>>>>>>>> ??????? >????? >???? @Karen: thanks for the Graal comment, I fixed it
> >>>>>>> in
> >>>>>>>>>>>> ?????? the new
> >>>>>>>>>>>> ??????? >???? webrev,
> >>>>>>>>>>>> ??????? >????? >???? let me know what you think :)
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >????? >???? I think the naming convention suggested in this
> >>>>>>>>> webrev
> >>>>>>>>>>>> ?????? came from
> >>>>>>>>>>>> ??????? >????? >???? conversations in for JEP-331 and I am actually
> >>>>>>>>>>> relatively
> >>>>>>>>>>>> ??????? >????? > indifferent to the final result (as long as we
> >>>>>>> have
> >>>>>>>>>>>> ?????? some form of
> >>>>>>>>>>>> ??????? >????? >???? forward progress :)). To be honest, I'd also be
> >>>>>>>>> happy
> >>>>>>>>>>>> ?????? to just
> >>>>>>>>>>>> ??????? >???? leave
> >>>>>>>>>>>> ??????? >????? >???? _end as is for all architectures and Graal and
> >>>>>>> have
> >>>>>>>>> a
> >>>>>>>>>>> new
> >>>>>>>>>>>> ??????? >????? > _allocation_end. However, during initial reviews
> >>>>>>> of
> >>>>>>>>>>>> ?????? JEP-331
> >>>>>>>>>>>> ??????? >???? it was
> >>>>>>>>>>>> ??????? >????? >???? deemed complicated to understand:
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >????? >???? _end -> the _end or sampling end
> >>>>>>>>>>>> ??????? >????? >???? _allocation_end -> end pointer for the last
> >>>>>>> possible
> >>>>>>>>>>>> ?????? allocation
> >>>>>>>>>>>> ??????? >????? >???? hard_end -> allocation end + reserved space
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >????? >???? That is how this naming came up and why hard_end
> >>>>>>>>> went
> >>>>>>>>>>> to
> >>>>>>>>>>>> ??????? > "reserved_end".
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >????? >???? I'm really indifferent, so I offer as a perusal:
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >????? >???? I noticed a few problems of alignement of '{' so
> >>>>>>>>> I'll
> >>>>>>>>>>>> ?????? go fix
> >>>>>>>>>>>> ??????? >???? that.
> >>>>>>>>>>>> ??????? >????? >???? Basically this webrev does the following:
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >????? >???? - Uses fast_path_end instead of end
> >>>>>>>>>>>> ??????? >????? >???? - Reverts hard_end back to where it was
> >>>>>>>>>>>> ??????? >????? >???? - Adds the changes to Graal; there is a bunch of
> >>>>>>>>>>>> ?????? changes in Graal
> >>>>>>>>>>>> ??????? >????? >???? because Graal still contains a bit of code doing
> >>>>>>>>>>>> ?????? fasttlabrefills.
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >????? >???? Let me know what you think!
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >????? >???? Thanks,
> >>>>>>>>>>>> ??????? >????? >???? Jc
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >????? >???? On Tue, Apr 10, 2018 at 6:56 AM Karen Kinnear
> >>>>>>>>>>>> ??????? >????? > <karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>
> >>>>>>>>>>>> <mailto:karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>> <mailto:
> >>>>>>>>> karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>
> >>>>>>>>>>>> <mailto:karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>>>
> >>>>>>>>>>>> ??????? > <mailto:karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>
> >>>>>>>>>>>> <mailto:karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>> <mailto:
> >>>>>>>>> karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>
> >>>>>>>>>>>> <mailto:karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>>>>>
> >>>>>>>>>>>> ??????? >???? wrote:
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >????? >???????? Hi JC,
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >????? >???????? A comment about Graal. The impact on Graal
> >>>>>>> for
> >>>>>>>>> this
> >>>>>>>>>>>> ??????? > particular
> >>>>>>>>>>>> ??????? >????? >???????? change would be to break it - so you?ll need
> >>>>>>>>>>>> ??????? >????? >???????? to complete the Graal changes for this
> >>>>>>> renaming.
> >>>>>>>>>>>> ?????? That isn?t
> >>>>>>>>>>>> ??????? >????? >???????? optional or something that could be a
> >>>>>>>>> follow-on. It
> >>>>>>>>>>>> ??????? > >???????? is not ok to break a feature, even an
> >>>>>>>>> experimental
> >>>>>>>>>>>> ?????? one.
> >>>>>>>>>>>> ??????? >???? We will
> >>>>>>>>>>>> ??????? >????? >???????? discuss in the other thread potential
> >>>>>>> phasing of
> >>>>>>>>>>>> ?????? adding
> >>>>>>>>>>>> ??????? >???? sampling.
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >????? >???????? I did not do a thorough search -you can do
> >>>>>>> that
> >>>>>>>>> -
> >>>>>>>>>>>> ?????? I did find
> >>>>>>>>>>>> ??????? >????? > src/jdk.internal.vm.compiler/share/classes/
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> ??????? > >??????????? public final int threadTlabOffset =
> >>>>>>>>>>>> ??????? >????? > getFieldOffset("Thread::_tlab",
> >>>>>>> Integer.class,
> >>>>>>>>>>>> ??????? > >???????? "ThreadLocalAllocBuffer");
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> ??????? > >??????????? private final int
> >>>>>>>>>>>> ?????? threadLocalAllocBufferStartOffset =
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>> ? getFieldOffset("ThreadLocalAllocBuffer::_start",
> >>>>>>>>>>>> ??????? > Integer.class,
> >>>>>>>>>>>> ??????? >????? >???????? "HeapWord*");
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> ??????? > >??????????? private final int
> >>>>>>>>>>> threadLocalAllocBufferEndOffset =
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>> ? getFieldOffset("ThreadLocalAllocBuffer::_end",
> >>>>>>>>>>>> ?????? Integer.class,
> >>>>>>>>>>>> ??????? >????? >???????? "HeapWord*");
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> ??????? > >??????????? private final int
> >>>>>>>>>>> threadLocalAllocBufferTopOffset =
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>> ? getFieldOffset("ThreadLocalAllocBuffer::_top",
> >>>>>>>>>>>> ?????? Integer.class,
> >>>>>>>>>>>> ??????? >????? >???????? "HeapWord*");
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> ??????? > >??????????? private final int
> >>>>>>>>>>>> ?????? threadLocalAllocBufferPfTopOffset =
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>> ?? getFieldOffset("ThreadLocalAllocBuffer::_pf_top",
> >>>>>>>>>>>> ??????? > Integer.class,
> >>>>>>>>>>>> ??????? >????? >???????? "HeapWord*");
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> ??????? > >??????????? private final int
> >>>>>>>>>>>> ??????? > threadLocalAllocBufferSlowAllocationsOffset
> >>>>>>>>>>>> ??????? >????? >???????? =
> >>>>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
> >>>>>>>>>>>> ??????? >????? >???????? Integer.class, "unsigned");
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> ??????? > >??????????? private final int
> >>>>>>>>>>>> ??????? > threadLocalAllocBufferFastRefillWasteOffset
> >>>>>>>>>>>> ??????? >????? >???????? =
> >>>>>>>>>>>> ??????? >
> >>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
> >>>>>>>>>>>> ??????? > >???????? Integer.class, "unsigned");
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> ??????? > >??????????? private final int
> >>>>>>>>>>>> ??????? > threadLocalAllocBufferNumberOfRefillsOffset
> >>>>>>>>>>>> ??????? >????? >???????? =
> >>>>>>>>>>>> ??????? >
> >>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
> >>>>>>>>>>>> ??????? > >???????? Integer.class, "unsigned");
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> ??????? > >??????????? private final int
> >>>>>>>>>>>> ??????? >????? > threadLocalAllocBufferRefillWasteLimitOffset
> >>>>>>> =
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
> >>>>>>>>>>>> ??????? >????? >???????? Integer.class, "size_t");
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> ??????? > >??????????? private final int
> >>>>>>>>>>>> ??????? > threadLocalAllocBufferDesiredSizeOffset =
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
> >>>>>>>>>>>> ??????? >????? >???????? Integer.class, "size_t");
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
> >>>>>>>>>>>> ??????? > >??????????? public final int tlabAlignmentReserve =
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>> getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
> >>>>>>>>>>>> ??????? > >???????? Integer.class, "size_t?);
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >????? >???????? hope this helps,
> >>>>>>>>>>>> ??????? >????? >???????? Karen
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >????? >>???????? On Apr 10, 2018, at 7:04 AM, Stefan
> >>>>>>> Johansson
> >>>>>>>>>>>> ??????? > >> <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>
> >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>>
> >>>>>>>>>>>> ??????? > <mailto:stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>
> >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>>>
> >>>>>>>>>>>> ??????? >????? >> <mailto:stefan.johansson at oracle.com
> <mailto:stefan.johansson at oracle.com>
> >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>>
> >>>>>>>>>>>> ??????? > <mailto:stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>
> >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>>>>> wrote:
> >>>>>>>>>>>> ??????? >????? >>
> >>>>>>>>>>>> ??????? >????? >>???????? Hi JC,
> >>>>>>>>>>>> ??????? >????? >>
> >>>>>>>>>>>> ??????? >????? >>???????? I realize that the names have been discussed
> >>>>>>>>>>>> ?????? before but I'm
> >>>>>>>>>>>> ??????? >????? >>???????? leaning towards suggesting something new. We
> >>>>>>>>>>>> ?????? discussed this
> >>>>>>>>>>>> ??????? >????? >>???????? briefly here in the office and others might
> >>>>>>>>> have
> >>>>>>>>>>>> ?????? different
> >>>>>>>>>>>> ??????? >????? >>???????? opinions. One point that came up is that if
> >>>>>>> we
> >>>>>>>>> do
> >>>>>>>>>>>> ?????? this
> >>>>>>>>>>>> ??????? >???? change
> >>>>>>>>>>>> ??????? >????? >>???????? and change all usages of
> >>>>>>>>>>>> ?????? JavaThread::tlab_end_offset() it
> >>>>>>>>>>>> ??????? >????? >>???????? would be good to make sure the new name is
> >>>>>>>>> good.
> >>>>>>>>>>>> ?????? To us
> >>>>>>>>>>>> ??????? >????? >> _current_end is not very descriptive, but
> >>>>>>>>> naming
> >>>>>>>>>>>> ?????? is hard and
> >>>>>>>>>>>> ??????? >????? >>???????? the best we could come up with is
> >>>>>>>>> _fast_path_end
> >>>>>>>>>>>> ?????? which would
> >>>>>>>>>>>> ??????? >????? >>???????? give the code:
> >>>>>>>>>>>> ??????? >????? >> cmpptr(end, Address(thread,
> >>>>>>>>>>>> ??????? >????? >> JavaThread::tlab_fast_path_end_offset()));
> >>>>>>>>>>>> ??????? >????? >> jcc(Assembler::above, slow_case);
> >>>>>>>>>>>> ??????? >????? >>
> >>>>>>>>>>>> ??????? >????? >>???????? I think this reads pretty good and is fairly
> >>>>>>>>>>>> ?? clear. If we do
> >>>>>>>>>>>> ??????? >????? >>???????? this rename I think you can re-use _end in
> >>>>>>>>> JEP-331
> >>>>>>>>>>>> ??????? >???? instead of
> >>>>>>>>>>>> ??????? >????? >>???????? calling it _allocation_end. But that is a
> >>>>>>> later
> >>>>>>>>>>>> ?????? review :)
> >>>>>>>>>>>> ??????? >????? >>
> >>>>>>>>>>>> ??????? >????? >>???????? Also, is there a good reason for renaming
> >>>>>>>>>>>> ?????? hard_end() to
> >>>>>>>>>>>> ??????? >????? >> reserved_end()?
> >>>>>>>>>>>> ??????? >????? >>
> >>>>>>>>>>>> ??????? >????? >>???????? One additional thing, you need to update
> >>>>>>> the SA
> >>>>>>>>>>>> ?????? to reflect
> >>>>>>>>>>>> ??????? >????? >>???????? this change. I think the only place you
> >>>>>>> need to
> >>>>>>>>>>>> ?????? fix is in:
> >>>>>>>>>>>> ??????? >????? >>
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
> >>>>>>>>>>>> ??????? > >>
> >>>>>>>>>>>> ??????? >????? >>???????? Thanks,
> >>>>>>>>>>>> ??????? >????? >>???????? Stefan
> >>>>>>>>>>>> ??????? >????? >>
> >>>>>>>>>>>> ??????? >????? >>???????? On 2018-04-09 19:24, JC Beyler wrote:
> >>>>>>>>>>>> ??????? >????? >>>???????? Hi all,
> >>>>>>>>>>>> ??????? >????? >>>???????? Small pre-amble to this request:
> >>>>>>>>>>>> ??????? >????? >>>???????? In my work to try to get a heap sampler in
> >>>>>>>>>>>> ?????? OpenJDK (via JEP
> >>>>>>>>>>>> ??????? >????? >>>???????? 331
> >>>>>>>>>>>> ??????? > <https://bugs.openjdk.java.net/browse/JDK-8171119>),
> >>>>>>> I'm
> >>>>>>>>>>>> ??????? > >>>???????? trying to reduce the footprint of my
> >>>>>>> change so
> >>>>>>>>>>>> ?????? that the
> >>>>>>>>>>>> ??????? >????? >>> integration can be easier. I was told that
> >>>>>>>>>>>> ?????? generally a JEP
> >>>>>>>>>>>> ??????? >????? >>>???????? webrev should be feature complete and go in
> >>>>>>>>>>> at-once.
> >>>>>>>>>>>> ??????? > However,
> >>>>>>>>>>>> ??????? >????? >>>???????? with the change touching quite a bit of
> >>>>>>>>> various
> >>>>>>>>>>> code
> >>>>>>>>>>>> ??????? >???? pieces,
> >>>>>>>>>>>> ??????? >????? >>>???????? I was trying to figure out what could be
> >>>>>>>>>>>> ?????? separated as not
> >>>>>>>>>>>> ??????? >????? >>>???????? "part of the feature".
> >>>>>>>>>>>> ??????? >????? >>>???????? I asked around and said that perhaps a
> >>>>>>>>> solution
> >>>>>>>>>>>> ?????? would be to
> >>>>>>>>>>>> ??????? >????? >>>???????? cut up the renaming of TLAB's end field
> >>>>>>> that I
> >>>>>>>>>>>> ?????? do in that
> >>>>>>>>>>>> ??????? >????? >>>???????? webrev. Because I'm renaming a field in
> >>>>>>> TLAB
> >>>>>>>>>>> used by
> >>>>>>>>>>>> ??????? >???? various
> >>>>>>>>>>>> ??????? >????? >>> backends for that work, I have to update
> >>>>>>> every
> >>>>>>>>>>>> ?????? architecture
> >>>>>>>>>>>> ??????? >????? >>> dependent code to reflect it.
> >>>>>>>>>>>> ??????? >????? >>>???????? I entirely understand that perhaps this is
> >>>>>>> not
> >>>>>>>>>>>> ?????? in the
> >>>>>>>>>>>> ??????? >???? habits
> >>>>>>>>>>>> ??????? >????? >>>???????? and very potentially might not be the way
> >>>>>>>>> things
> >>>>>>>>>>> are
> >>>>>>>>>>>> ??????? > >>>???????? generally done. If so, I apologize and let
> >>>>>>> me
> >>>>>>>>>>>> ?????? know if you
> >>>>>>>>>>>> ??????? >????? >>>???????? would not want this to go in separately :)
> >>>>>>>>>>>> ??????? >????? >>>???????? Final note: there is still a chance JEP-331
> >>>>>>>>> does
> >>>>>>>>>>>> ?????? not go in.
> >>>>>>>>>>>> ??????? >????? >>>???????? If it does not, we can leave the new name
> >>>>>>> in
> >>>>>>>>>>>> ?????? place or I'll
> >>>>>>>>>>>> ??????? >????? >>>???????? happily revert it. I can even create an
> >>>>>>> issue
> >>>>>>>>> to
> >>>>>>>>>>>> ?????? track this
> >>>>>>>>>>>> ??????? >????? >>>???????? if that makes it easier for all.
> >>>>>>>>>>>> ??????? >????? >>>???????? End of the pre-amble.
> >>>>>>>>>>>> ??????? >????? >>>???????? The 33-line change webrev in question is
> >>>>>>> here:
> >>>>>>>>>>>> ??????? > >>>
> >>>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
> >>>>>>>>>>>> ??????? > >>>???????? I fixed all the architectures and JVMCI and
> >>>>>>>>> ran
> >>>>>>>>>>>> ?????? a few
> >>>>>>>>>>>> ??????? >???? sanity
> >>>>>>>>>>>> ??????? >????? >>>???????? tests to ensure I had not missed anything.
> >>>>>>>>>>>> ??????? >????? >>>???????? Thanks for your help and I hope this is not
> >>>>>>>>> too
> >>>>>>>>>>> much
> >>>>>>>>>>>> ??????? > trouble,
> >>>>>>>>>>>> ??????? >????? >>>???????? Jc
> >>>>>>>>>>>> ??????? >????? >>>???????? Ps: there is a graal change that needs to
> >>>>>>>>> happen
> >>>>>>>>>>>> ?????? but I was
> >>>>>>>>>>>> ??????? >????? >>>???????? not sure who/where <https://teams.googleplex.com/u/where>
> >>>>>>> <https://teams.googleplex.com/u/where>
> >>>>>>>>> <https://teams.googleplex.com/u/where>
> >>>>>>>>>>> <https://teams.googleplex.com/u/where>
> >>>>>>>>>>>> <https://teams.googleplex.com/u/where>
> >>>>>>>>>>>> ??????? > <https://teams.googleplex.com/u/where>
> >>>>>>>>>>>> ??????? > <https://teams.googleplex.com/u/where> to
> >>>>>>>>>>>> ??????? >????? >>>???????? ask about it. I was told it could happen
> >>>>>>> in a
> >>>>>>>>>>>> ?????? separate
> >>>>>>>>>>>> ??????? >????? >>>???????? webrev. Can anyone point me to the right
> >>>>>>>>>>> direction?
> >>>>>>>>>>>> ??????? >???? Should it
> >>>>>>>>>>>> ??????? >????? >>>???????? just be hotspot-compiler-dev?
> >>>>>>>>>>>> ??????? >????? >
> >>>>>>>>>>>> ??????? >
> >>>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>
> >
>
From david.holmes at oracle.com Wed Apr 18 22:10:49 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 19 Apr 2018 08:10:49 +1000
Subject: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
In-Reply-To: <CAA-vtUyKJ4dXw7RS+CvTkKj5j0R+UB-4_pwpHqDExKCYGR8vhQ@mail.gmail.com>
References: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
<CAA-vtUz48xUdXQzDEAuS2JDdnis7n2pAjfJ52dgFkhKskNoX9Q@mail.gmail.com>
<b65af851-d138-42b2-847a-fd6650a1767b@oracle.com>
<CAA-vtUz+cyza6GOnVN7p-9XJ-JYo_vBozMNh0K=7woUbV4mKzA@mail.gmail.com>
<b0fcb60f-ff76-9b98-871c-8692f4504442@oracle.com>
<43ae45216d3545518b274dd7246d7862@sap.com>
<4dcc535e-4906-05a8-0636-65191f8a8695@oracle.com>
<5fc75353a1a74c22a0c24e2bdfc2d05b@sap.com>
<CAA-vtUyKJ4dXw7RS+CvTkKj5j0R+UB-4_pwpHqDExKCYGR8vhQ@mail.gmail.com>
Message-ID: <d8b60482-35a8-304a-9a4d-3c0e37b0e0cc@oracle.com>
I'm losing track of the original goal here and the scope of this seems
to be blowing out into unknown territory. We don't know why we need the
raw write; and we don't know what we can assume about the vprintf-hook.
I suggest to dial this back to whatever real issue was initially being
addressed.
Cheers,
David
On 19/04/2018 1:55 AM, Thomas St?fe wrote:
> Hi Chrisoph,
>
> thanks for the new webrev, this looks all very reasonable.
>
> Unfortunately a small issue occurred to me while thinking this over...
> Sigh, this turns out to be more complicated than I thought.
>
> The original intent of this change was to get rid of that extra copy
> step we do in "call_jio_print" which aims to ensure that the string we
> hand down to jio_print is zero terminated.
>
> But ultimately, the problem was never jio_print, but the vfprintf
> hook: The vfprintf hook has the form "foo(FILE*, char* fmt, ....) and
> this is a contract with an embedding program - it has to provide a
> "fprinf-like function" but ultimately can do whatever it wants with
> the arguments we give it.
>
> (IMHO this whole vfprintf hook thing was very badly designed. We had a
> number of issues with this already. For a discussion about some
> details, see e.g.
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-May/026794.html
> .)
>
> The problem I see is that now we may call the vfprintf hook with
> something like ("%.*s", precision, s) with the explicit intention of
> passing in not-zero-terminated strings for s and a precision which
> prevents us reading beyond the end of s. This was the whole point - we
> avoid the copy step.
>
> As we discussed offlist, this would be a perfectly valid fix were we
> to feed those arguments to a standard fprintf() function which is
> POSIX compatible, because POSIX states for the format specifier 's':
>
> <quote>
> The argument shall be a pointer to an array of char. Bytes from the
> array shall be written up to (but not including) any terminating null
> byte. If the precision is specified, no more than that many bytes
> shall be written. If the precision is not specified or is greater than
> the size of the array, the application shall ensure that the array
> contains a null byte.
> </quote>
>
> This explicitly allows us to pass a pointer to a non-zero-terminated
> string as long as the precision is smaller than its length.
>
> However, the argument vfprintf hook can be anything. It is a
> user-provided function. Usually they will probably just call vxxprintf
> functions from the libc, but for all we know they may roll their own
> printf routine. So, we may uncover bugs in their implementation.
>
> Seeing that the vfprintf hook is very badly documented, we move in
> gray area here. We may break user code which has a bad, non-Posix
> implementation of the vfprintf hook.
>
> I would like to know if others think this concern is valid.
>
> Otherwise, the patch looks good.
>
>
> ..Thomas
>
>
>
> On Wed, Apr 18, 2018 at 5:01 PM, Langer, Christoph
> <christoph.langer at sap.com> wrote:
>> Hi,
>>
>>>> I think it could be cleaned up nicely by removing jio_print and jio_printf
>>> from jvm.cpp and doing all in ostream.cpp. At the one place where we would
>>> call jio_print after my patch, we can do the vfprintf hook check and then
>>> either write to the hook or do the raw write. And the other 2 places where
>>> jio_printf is employed, we can just call
>>> jio_vfprintf(defaultStream::output_stream()). I don't see any other users of
>>> jio_print and jio_printf in the jdk repo.
>>>>
>>>> Any objections to that (e.g. some Oracle closed coding that'd break)?
>>> Otherwise I'll prepare something...
>>>
>>> $ grep -r jio_print closed
>>>
>>> Showed nothing found.
>>
>> I've prepared a new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201649.1/
>>
>> I remove jio_printf and jio_print completely.
>>
>> If we agree that in defaultStream::write(), the raw write is not needed and we can use fprintf, we could further simplify the code to just call jio_fprintf.
>>
>> Furhtermore, I have updated the jio_*print* function declarations in jvm.cpp to match those of jvm.h. Is that desired (I thought yes, in times where we try to get rid of the mapfiles anyway). I wonder if those symbols can be taken out of make/hotspot/symbols/symbols-shared then...
>>
>> Best regards
>> Christoph
From serguei.spitsyn at oracle.com Wed Apr 18 22:55:50 2018
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 18 Apr 2018 15:55:50 -0700
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
fast_path_end
In-Reply-To: <b0699a0d-80c8-4bd1-3fd5-c8ac60b75e90@oracle.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
<5c659df9-4523-0f75-4a61-f243ffdadd16@oracle.com>
<CAF9BGBxEPXLTiyD-xG_ECyveyW0PXQL0+-z7jkw3Rv4QrkkszQ@mail.gmail.com>
<ec1a3e0e-ca9b-8668-b260-1fd3e612b7f7@oracle.com>
<CAF9BGBy-LBKCwJHQPdAQ65VRcSFBwVkk9dm8MLC_nrefE_JdEw@mail.gmail.com>
<e6528c19-5691-1215-1ac5-0349801b79b5@oracle.com>
<CAF9BGBwBgyOoJTfJU_YmqYJgSZ+1985yx_sSMJC4wNJELw1XDQ@mail.gmail.com>
<e63675e1-d693-cd25-75b2-32b593e266a2@oracle.com>
<CAF9BGBz3g4yXMjf9TxrqLdMbfaswoa3U13qYTEUtv-mZCDMd8Q@mail.gmail.com>
<735b3949-d9cd-3d37-ebb4-f59ee61f18ad@oracle.com>
<ba26dc77-a5ba-b490-2a03-cf4abd79ac3c@oracle.com>
<ff9474cd-6f07-446c-12b5-2dafbca35ce3@oracle.com>
<19c34a75-e1f5-f1b2-2cd7-91300e7979c3@oracle.com>
<30260bf8-765b-3227-87c0-85f001ca4c55@oracle.com>
<129b0875-52e8-eabc-258a-5ad4f36aa226@oracle.com>
<CAF9BGBypU+AexV5vt-mJD5rLAqxfORwYa0f16s9iWwRhF2Z+3w@mail.gmail.com>
<b0699a0d-80c8-4bd1-3fd5-c8ac60b75e90@oracle.com>
Message-ID: <9f9a95b5-deb0-ba74-9ef1-3d5de1d9a9ef@oracle.com>
Vladimir,
Thanks a lot for making this resolved!
It safes our time as we will stop all these renaming discussions now.
On 4/18/18 15:06, Vladimir Kozlov wrote:
> On 4/18/18 2:54 PM, JC Beyler wrote:
>> Seems like there is no consensus really except that changing it has a
>> few headaches involved. Should we then do the implementation of
>> "8171119: Low-Overhead HeapProfiling" without changing the _end field
>> and postpone this conversation to afterwards when Graal handles
>> multi-release in a more mature?manner (read has been doing it for a
>> while).
>
> I would prefer this way.
+1
One more question is if we have to close this enhancement as NAI or to
keep it for post JEP renaming.
I'd prefer to close it.
>
> Thanks,
> Vladimir
>
>>
>> Or is there still a path forward? (Re)Naming is hard, this is proof
>> of that.
>>
>> That puts us back to what I had originally:
>> _end: the fast path end, can be the allocation end or the
>> to-be-sampled end
>> _allocation_end: the actual allocation end of the current TLAB
>> hard_end: _allocation_end?+ reserved space
Right.
It looks like the only way to move forward.
It will make it simpler.
Thanks,
Serguei
>>
>> Thanks for all of your input and help on this,
>> Jc
>>
>> On Wed, Apr 18, 2018 at 12:46 PM Vladimir Kozlov
>> <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>
>> ??? On 4/18/18 12:15 PM, dean.long at oracle.com
>> <mailto:dean.long at oracle.com> wrote:
>> ???? > I will defer to Vladimir, but I would have been happy with
>> something like:
>> ???? >
>> ???? > // preserve simple start/end abstraction for compiler
>> ???? > HeapWord* end() const ? ? ?? { return fast_path_end(); }
>> ???? > static ByteSize end_offset() { return fast_path_end_offset(); }
>>
>> ??? This is ugly.
>>
>> ???? >
>> ???? > even though end_offset() would then refer to a virtual "end"
>> field.
>> ???? >
>> ???? > Vladimir, are you also approving the Graal changes? :-)
>>
>> ??? You really made my day :(
>>
>> ??? S..t! We can't make this change in Graal as suggested because we
>> will break Graal's JDK 8 support.
>> ??? Graal has direct access to VM's fields through JVMCI. You have to
>> guard change with JDK version
>> ??? check.
>>
>> ??? Labs start addressing multi-releases so it may be not big issue
>> anymore. See Doug's comment for
>> ??? 8201318 RFR.
>>
>> ??? Anyway you have to file new PR (pull request) for Graal changes on
>> ??? https://github.com/graalvm/mx/pulls.
>> ??? And I am not sponsoring this. I don't think such renaming worse
>> all our efforts.
>>
>> ??? Good luck,
>> ??? Vladimir
>>
>> ???? >
>> ???? > dl
>> ???? >
>> ???? > On 4/18/18 11:02 AM, Vladimir Kozlov wrote:
>> ???? >> Ganging up on us ;)
>> ???? >>
>> ???? >> Yes, I missed original discussion about renaming on GC list.
>> ???? >>
>> ???? >> From my point of view next code looks better because it seems
>> compare related values:
>> ???? >>
>> ???? >> cmpptr(end, Address(thread, JavaThread::tlab_end_offset()));
>> ???? >>
>> ???? >> But I would not strongly object renaming to move this JEP
>> forward. Consider changes reviewed
>> ??? and approved by me.
>> ???? >>
>> ???? >> Regards,
>> ???? >> Vladimir
>> ???? >>
>> ???? >> On 4/18/18 6:29 AM, Daniel D. Daugherty wrote:
>> ???? >>> Greetings,
>> ???? >>>
>> ???? >>> The idea of splitting this change off from "8171119:
>> Low-Overhead Heap Profiling"
>> ???? >>> came up during the design review. It might have been me that
>> suggested the split
>> ???? >>> off or it was someone else. Sorry I don't remember.
>> ???? >>>
>> ???? >>> In any case, the rename of "end" to "fast_path_end" is just
>> a clarity change to
>> ???? >>> the existing code and I think that change can easily stand
>> on its own. That is
>> ???? >>> particularly true if the accessors are renamed at the same
>> time. I think having
>> ???? >>> the accessor names match the field names is a pretty well
>> known HotSpot rule
>> ???? >>> so I'm not sure why we're talking about not renaming the
>> accessors...
>> ???? >>>
>> ???? >>> Personally, I prefer "_fast_path_end" over "_current_end".
>> ???? >>>
>> ???? >>> Dan
>> ???? >>>
>> ???? >>>
>> ???? >>> On 4/18/18 4:04 AM, Stefan Johansson wrote:
>> ???? >>>> Hi,
>> ???? >>>>
>> ???? >>>> On 2018-04-18 02:02, Vladimir Kozlov wrote:
>> ???? >>>>> ?> I think I like better not to add it. If no one is using
>> it, there should be
>> ???? >>>>> ?> no reason to add it? By not adding it, it also makes
>> any future wish to
>> ???? >>>>> ?> have it a nice indicator of: hey why do you want to see
>> this? Same as
>> ???? >>>>> ?> hard_end btw which is not visible. Am I missing something?
>> ???? >>>>>
>> ???? >>>>> I say "may" ;)
>> ???? >>>>> You don't need new function if there is no use.
>> ???? >>>>>
>> ???? >>>>> ?>
>> ???? >>>>> ?> So to summarize, the current consensus:
>> ???? >>>>> ?>??? - _end can be renamed either to _current_end or
>> _fast_path_end; that is
>> ???? >>>>> ?> still up to a vote and choice :)
>> ???? >>>>>
>> ???? >>>>> Please, use _current_end. I was thinking about _sample_end
>> but it does not reflect double
>> ??? usage.
>> ???? >>>>
>> ???? >>>> I'm not sure if you have seen the discussion about naming
>> on hotspot-gc-dev, but I and
>> ??? others think that
>> ???? >>>> _current_end doesn't describe the usage at all. Naming it
>> _fast_path_end would clearly
>> ??? state what it is, _sample_end
>> ???? >>>> or something similar also crossed my mind but I think the
>> code reads a lot better in the
>> ??? compiler with the name
>> ???? >>>> fast_path_end.
>> ???? >>>>
>> ???? >>>>>
>> ???? >>>>> ?>??? - the access method end() and tlab_end_offset()
>> remain the same to not
>> ???? >>>>> ?> modify JIT/interpreter codes
>> ???? >>>> I would find this very unfortunate, having accessors that
>> don't match the members can
>> ??? easily lead to
>> ???? >>>> misunderstanding, especially if we have three different
>> *_end members. Why do you think
>> ??? this is the best way forward?
>> ???? >>>>
>> ???? >>>> My first thought was also that it would be nice to avoid
>> all the compiler changes, but
>> ??? then we would have to stick
>> ???? >>>> with _end being the sample/current/fast-path end and I'm
>> not sure that is a better
>> ??? solution. I don't see the big
>> ???? >>>> problem with changing those accessors to what they really
>> access and I think the compiler
>> ??? code reads good even after
>> ???? >>>> the change. For example:
>> ???? >>>> cmpptr(end, Address(thread,
>> JavaThread::tlab_fast_path_end_offset()));
>> ???? >>>> jcc(Assembler::above, slow_case);
>> ???? >>>>
>> ???? >>>>> ?>
>> ???? >>>>> ?> If all agree to this, then the consequences are:
>> ???? >>>>> ?>??? - JDK-8201326 becomes useless
>> ???? >>>>> ?>??? - The work for JEP-331 becomes smaller in terms of
>> file changes
>> ???? >>>>> ?>??? - I'll still be needing a decision on the renaming
>> of the TLAB _end field
>> ???? >>>>> ?> (current suggestions are _current_end and _fast_path_end).
>> ???? >>>>
>> ???? >>>> We'll see where we end up. If JDK-8201326 ends up being a
>> separate change I think it
>> ??? should be pushed at the same
>> ???? >>>> time as the rest of the JEP changes. To me it only makes
>> sense to have it in the code base
>> ??? if we also have the rest
>> ???? >>>> of the changes.
>> ???? >>>>
>> ???? >>>> Thanks,
>> ???? >>>> Stefan
>> ???? >>>>
>> ???? >>>>>
>> ???? >>>>> Sounds good to me.
>> ???? >>>>>
>> ???? >>>>> Thanks,
>> ???? >>>>> Vladimir
>> ???? >>>>>
>> ???? >>>>> On 4/17/18 4:51 PM, JC Beyler wrote:
>> ???? >>>>>> Hi Vladimir and Dean,
>> ???? >>>>>>
>> ???? >>>>>> @Dean: seems that Vladimir is in agreement with you for
>> renaming just the
>> ???? >>>>>> field and not the method names so ack to your answer that
>> came at the same
>> ???? >>>>>> time :)
>> ???? >>>>>>
>> ???? >>>>>>
>> ???? >>>>>>> Yes, from the beginning such changes should be discussed
>> on common
>> ???? >>>>>>> hotspot-dev list since all
>> ???? >>>>>>> Hotspot's parts are affected.
>> ???? >>>>>>>
>> ???? >>>>>>
>> ???? >>>>>> Sorry, being new to the scene, most of the conversation
>> had been going on
>> ???? >>>>>> in serviceability-dev.
>> ???? >>>>>>
>> ???? >>>>>>
>> ???? >>>>>>>
>> ???? >>>>>>> Graal specific question could be send to
>> hotspot-compiler-dev list with
>> ???? >>>>>>> [Graal] in subject.
>> ???? >>>>>>>
>> ???? >>>>>>> I looked on JEP's changes
>> ???? >>>>>>> http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.02/
>> to understand how
>> ???? >>>>>>> it works.
>> ???? >>>>>>>
>> ???? >>>>>>> Few questions about proposed JEP changes so I can
>> understand it.
>> ???? >>>>>>>
>> ???? >>>>>>> You introducing new TLAB end for sampling and adjust it
>> so that
>> ???? >>>>>>> allocations in JITed code and
>> ???? >>>>>>> Interpreter it will trigger slow path allocation where
>> you do sampling.
>> ???? >>>>>>> Right?
>> ???? >>>>>>>
>> ???? >>>>>>
>> ???? >>>>>> Yes that is correct; if sampling is enabled of course.
>> Btw, this is the current
>> ???? >>>>>> webrev
>> <http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.15/>.
>> ???? >>>>>>
>> ???? >>>>>>
>> ???? >>>>>>>
>> ???? >>>>>>> Do all changes to _end, _actual_end and other TLAB
>> fields happen during
>> ???? >>>>>>> slow allocation?
>> ???? >>>>>>>
>> ???? >>>>>>
>> ???? >>>>>> Yes, to that effect, with Robbin's help, we finalized
>> deprecating the
>> ???? >>>>>> FastTLabRefill via JDK-8194084
>> ???? >>>>>> <https://bugs.openjdk.java.net/browse/JDK-8194084>. Seems
>> like I/we missed
>> ???? >>>>>> that Graal does this as well. I filed GRAAL-64
>> ???? >>>>>> <https://bugs.openjdk.java.net/browse/GRAAL-64> to not
>> forget that Graal
>> ???? >>>>>> would need to get that fixed.
>> ???? >>>>>>
>> ???? >>>>>>
>> ???? >>>>>>
>> ???? >>>>>>>
>> ???? >>>>>>> I am concern about concurrent accesses to these fields
>> from other threads
>> ???? >>>>>>> if you have them (I don't
>> ???? >>>>>>> see).
>> ???? >>>>>>>
>> ???? >>>>>>
>> ???? >>>>>> Yes that is why we deprecated the FastTlabRefill. Other
>> threads should not
>> ???? >>>>>> be changing the thread local data structure so I don't
>> see an issue there.
>> ???? >>>>>> The major issue was that the fast paths could change the
>> tlab without going
>> ???? >>>>>> via the slowpath.
>> ???? >>>>>>
>> ???? >>>>>> I had a fix to detect this issue but removed it once
>> JDK-8194084 was done;
>> ???? >>>>>> Graal was missed in that work so that is why if sampling
>> were enabled with
>> ???? >>>>>> Graal, there is a chance things would break currently.
>> That will get fixed
>> ???? >>>>>> via GRAAL-64
>> <https://bugs.openjdk.java.net/browse/GRAAL-64> whether it is
>> ???? >>>>>> rendering the code also obsolete and going to the
>> slowpath or whether it is
>> ???? >>>>>> adding my fix again to detect a fastpath TLAB
>> reallocation happened.
>> ???? >>>>>>
>> ???? >>>>>>
>> ???? >>>>>>>
>> ???? >>>>>>> Renaming. I am fine with renaming if it helps to
>> understand code better. I
>> ???? >>>>>>> agree with proposed
>> ???? >>>>>>> changes to fields name:
>> ???? >>>>>>>
>> ???? >>>>>>> _current_end
>> ???? >>>>>>> _allocation_end
>> ???? >>>>>>>
>> ???? >>>>>>> But, as Dean, I would suggest to keep names of access
>> functions. This way
>> ???? >>>>>>> we can say that allocation
>> ???? >>>>>>> code in Interpreter and JITed code stay the same.
>> ???? >>>>>>>
>> ???? >>>>>>
>> ???? >>>>>> Sounds good to me, then in that case, this webrev will
>> disappear, which
>> ???? >>>>>> also makes me happy, since it simplifies a lot of things
>> (and reduces code
>> ???? >>>>>> change).
>> ???? >>>>>>
>> ???? >>>>>>
>> ???? >>>>>>>
>> ???? >>>>>>> You may need only new method to access _allocation_end
>> in places which
>> ???? >>>>>>> look for real end of TLAB.
>> ???? >>>>>>>
>> ???? >>>>>>
>> ???? >>>>>> I think I like better not to add it. If no one is using
>> it, there should be
>> ???? >>>>>> no reason to add it? By not adding it, it also makes any
>> future wish to
>> ???? >>>>>> have it a nice indicator of: hey why do you want to see
>> this? Same as
>> ???? >>>>>> hard_end btw which is not visible. Am I missing something?
>> ???? >>>>>>
>> ???? >>>>>> So to summarize, the current consensus:
>> ???? >>>>>> ?? - _end can be renamed either to _current_end or
>> _fast_path_end; that is
>> ???? >>>>>> still up to a vote and choice :)
>> ???? >>>>>> ?? - the access method end() and tlab_end_offset() remain
>> the same to not
>> ???? >>>>>> modify JIT/interpreter codes
>> ???? >>>>>>
>> ???? >>>>>> If all agree to this, then the consequences are:
>> ???? >>>>>> ?? - JDK-8201326 becomes useless
>> ???? >>>>>> ?? - The work for JEP-331 becomes smaller in terms of
>> file changes
>> ???? >>>>>> ?? - I'll still be needing a decision on the renaming of
>> the TLAB _end field
>> ???? >>>>>> (current suggestions are _current_end and _fast_path_end).
>> ???? >>>>>>
>> ???? >>>>>> Thanks for your help!
>> ???? >>>>>> Jc
>> ???? >>>>>>
>> ???? >>>>>>
>> ???? >>>>>>>
>> ???? >>>>>>> Regards,
>> ???? >>>>>>> Vladimir
>> ???? >>>>>>>
>> ???? >>>>>>> On 4/16/18 4:42 PM, JC Beyler wrote:
>> ???? >>>>>>>> Hi Dean,
>> ???? >>>>>>>>
>> ???? >>>>>>>> I think perhaps this is also an attempt to figure out
>> the naming of all
>> ???? >>>>>>>> this because naming (or renaming like here) is often
>> the start of big
>> ???? >>>>>>>> conversations :).
>> ???? >>>>>>>>
>> ???? >>>>>>>> Originally, in the JEP-331 work, I had left the _end
>> field as is and, by
>> ???? >>>>>>>> doing so, this whole renaming webrev goes away.
>> However, if we do that,
>> ???? >>>>>>>> then the TLAB code contains:
>> ???? >>>>>>>>
>> ???? >>>>>>>> _end: the fast path end, can be the allocation end or
>> the to-be-sampled
>> ???? >>>>>>> end
>> ???? >>>>>>>> _allocation_end: the actual allocation end of the
>> current TLAB
>> ???? >>>>>>>> hard_end: _allocation_end + reserved space
>> ???? >>>>>>>>
>> ???? >>>>>>>> With an early iteration of a webrev for JEP-331, a
>> conversation occurred
>> ???? >>>>>>>> about whether or not that was clear or not and it was
>> determined that
>> ???? >>>>>>> this
>> ???? >>>>>>>> renaming was more clear:
>> ???? >>>>>>>>
>> ???? >>>>>>>> _current_end: the fast path end
>> ???? >>>>>>>> _allocation_end: the actual allocation end of the
>> current TLAB
>> ???? >>>>>>>> reserved_end: _allocation_end + reserved space
>> ???? >>>>>>>>
>> ???? >>>>>>>> Because I'm trying to reduce the footprint of files
>> changed, I pulled out
>> ???? >>>>>>>> the renaming changes into this webrev. While talking
>> about it with the GC
>> ???? >>>>>>>> team, the renaming suggested became:
>> ???? >>>>>>>>
>> ???? >>>>>>>> _fast_path_end: the fast path end
>> ???? >>>>>>>> _allocation_end: the actual allocation end of the
>> current TLAB
>> ???? >>>>>>>> hard_end: _allocation_end + reserved space
>> ???? >>>>>>>>
>> ???? >>>>>>>> Now, to be honest, any renaming or no renaming is fine
>> by me. I like not
>> ???? >>>>>>>> renaming the fields to not change the code of every
>> backend and Graal; I
>> ???? >>>>>>>> also like the fast_path_end rename due to it making the
>> backend code easy
>> ???? >>>>>>>> to read as mentioned in the GC mailing lis thread.
>> ???? >>>>>>>>
>> ???? >>>>>>>> So there are two questions really:
>> ???? >>>>>>>> ???? - Should we rename the _end field and thus provoke
>> the changes in
>> ???? >>>>>>> this
>> ???? >>>>>>>> webrev?
>> ???? >>>>>>>> ???? - If we do want to change the field, should/could
>> it go in an initial
>> ???? >>>>>>>> webrev or should it go in the JEP-331 webrev
>> whenever/ifever it goes in?
>> ???? >>>>>>>> And if we do wait, could we at least converge on a
>> renaming now so that
>> ???? >>>>>>>> this does not become a point of contention for that
>> webrev's review?
>> ???? >>>>>>>>
>> ???? >>>>>>>> If I read your answer correctly:
>> ???? >>>>>>>> ?????? - You are saying that we should keep the _end
>> field altogether; or
>> ???? >>>>>>> at
>> ???? >>>>>>>> least only rename the field not the methods to access
>> it, thus reducing
>> ???? >>>>>>> the
>> ???? >>>>>>>> change scope.
>> ???? >>>>>>>> ?????? - You are also saying to wait for the JEP-331
>> webrev's final
>> ???? >>>>>>> iteration
>> ???? >>>>>>>> and integrate it in one step
>> ???? >>>>>>>>
>> ???? >>>>>>>> Have I understood your answer correctly?
>> ???? >>>>>>>>
>> ???? >>>>>>>> Again, I am fine with renaming to whatever or not
>> renaming at all. I just
>> ???? >>>>>>>> am trying to get forward progress here :)
>> ???? >>>>>>>>
>> ???? >>>>>>>> Thanks for your help!
>> ???? >>>>>>>> Jc
>> ???? >>>>>>>>
>> ???? >>>>>>>> On Mon, Apr 16, 2018 at 3:29 PM <dean.long at oracle.com
>> <mailto:dean.long at oracle.com>>
>> ??? wrote:
>> ???? >>>>>>>>
>> ???? >>>>>>>>> Hi JC.? Others might disagree, but I would vote "no"
>> on doing this
>> ???? >>>>>>>>> renaming now, before the JEP, and even in the context
>> of the JEP, I
>> ???? >>>>>>>>> don't think renaming the field requires renaming all
>> the uses.? The
>> ???? >>>>>>>>> compiler code is only interested in the fast path, so
>> it's implicitly
>> ???? >>>>>>>>> understood.? Also, if there is a fast_path_end(), then
>> isn't it logical
>> ???? >>>>>>>>> to have fast_path_start() paired with it?? ("start" is
>> already
>> ???? >>>>>>>>> overloaded, but nobody is suggesting adding
>> ???? >>>>>>>>> allocation_start()/current_start()/hard_start() are
>> they?).? My opinion
>> ???? >>>>>>>>> is that it's fine the way it is.
>> ???? >>>>>>>>>
>> ???? >>>>>>>>> dl
>> ???? >>>>>>>>>
>> ???? >>>>>>>>> On 4/16/18 1:43 PM, JC Beyler wrote:
>> ???? >>>>>>>>>> Hi all,
>> ???? >>>>>>>>>>
>> ???? >>>>>>>>>> I've left the mail thread from the hotspot-gc-dev
>> below for tracking
>> ???? >>>>>>>>>> purposes but will start a new request here.
>> ???? >>>>>>>>>>
>> ???? >>>>>>>>>> - I'm trying to push a renaming of a TLAB field to
>> make my work for
>> ???? >>>>>>>>> JEP-331
>> ???? >>>>>>>>>> <http://openjdk.java.net/jeps/331> easier
>> ???? >>>>>>>>>> ????? - There is an understanding that if JEP-331
>> does not make it, this
>> ???? >>>>>>>>> might
>> ???? >>>>>>>>>> be useless and I'll revert if that is what the
>> community wants; however
>> ???? >>>>>>>>> the
>> ???? >>>>>>>>>> new name seems better anyway so perhaps not?
>> ???? >>>>>>>>>>
>> ???? >>>>>>>>>> - The webrev renames a field used across the various
>> back-ends and
>> ???? >>>>>>> Graal
>> ???? >>>>>>>>>> ????? - The webrev is here:
>> ???? >>>>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.04/
>> ???? >>>>>>>>>>
>> ???? >>>>>>>>>> Could I please get some feedback on this?
>> ???? >>>>>>>>>>
>> ???? >>>>>>>>>> Thanks all for your help,
>> ???? >>>>>>>>>> Jc
>> ???? >>>>>>>>>>
>> ???? >>>>>>>>>>
>> ???? >>>>>>>>>>
>> ???? >>>>>>>>>> On Fri, Apr 13, 2018 at 2:37 AM Stefan Johansson <
>> ???? >>>>>>>>>> stefan.johansson at oracle.com
>> <mailto:stefan.johansson at oracle.com>> wrote:
>> ???? >>>>>>>>>>
>> ???? >>>>>>>>>>> Hi JC,
>> ???? >>>>>>>>>>>
>> ???? >>>>>>>>>>> I don't have a name, but I've looked at bit more at
>> the failures and I
>> ???? >>>>>>>>>>> think they are unrelated and one of the local
>> compiler engineers
>> ???? >>>>>>> agree.
>> ???? >>>>>>>>>>>
>> ???? >>>>>>>>>>> I also ran some local testing and was not able to
>> get any error with
>> ???? >>>>>>> you
>> ???? >>>>>>>>>>> latest changes, but verified that it doens't work
>> without the graal
>> ???? >>>>>>>>>>> parts. So they seem good. It might still be good to
>> switch this over
>> ???? >>>>>>> to
>> ???? >>>>>>>>>>> the general hotspot-dev list to let someone with
>> Graal knowledge to
>> ???? >>>>>>> look
>> ???? >>>>>>>>>>> at the change and make sure everything is correct.
>> ???? >>>>>>>>>>>
>> ???? >>>>>>>>>>> Thanks,
>> ???? >>>>>>>>>>> Stefan
>> ???? >>>>>>>>>>>
>> ???? >>>>>>>>>>>
>> ???? >>>>>>>>>>> On 2018-04-12 17:26, JC Beyler wrote:
>> ???? >>>>>>>>>>>> Hi Stefan,
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>> Thanks for testing :). I've renamed the bug title
>> in the JBS and will
>> ???? >>>>>>>>>>>> emit a new webrev shortly. Do you have the name of
>> a compiler
>> ???? >>>>>>> engineer
>> ???? >>>>>>>>>>>> in mind or should I perhaps now move this
>> conversation to the general
>> ???? >>>>>>>>>>>> hotspot-dev mailing list and ask there?
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>> The alternative is to add the compiler-mailing list
>> to this email
>> ???? >>>>>>>>> thread
>> ???? >>>>>>>>>>>> and ask there before sending to the general list.
>> What do you think
>> ???? >>>>>>> is
>> ???? >>>>>>>>>>> best?
>> ???? >>>>>>>>>>>> Thanks for all your help,
>> ???? >>>>>>>>>>>> Jc
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>> On Thu, Apr 12, 2018 at 2:09 AM Stefan Johansson
>> ???? >>>>>>>>>>>> <stefan.johansson at oracle.com
>> <mailto:stefan.johansson at oracle.com>
>> ??? <mailto:stefan.johansson at oracle.com
>> <mailto:stefan.johansson at oracle.com>>>
>> ???? >>>>>>>>>>> wrote:
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>> ?????? On 2018-04-11 17:48, JC Beyler wrote:
>> ???? >>>>>>>>>>>> > Hi Stefan,
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>> > Sorry about that, I must have missed adding the
>> files or
>> ???? >>>>>>>>>>>> something. Here
>> ???? >>>>>>>>>>>> > is a webrev that added the changes for the SA file:
>> ???? >>>>>>>>>>>> >
>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>> ?????? No problem, this looks good. I kicked of a
>> run in our test
>> ???? >>>>>>> system
>> ???? >>>>>>>>> to
>> ???? >>>>>>>>>>>> ?????? get
>> ???? >>>>>>>>>>>> some more coverage and have tried to include some
>> Graal
>> ???? >>>>>>> testing.
>> ???? >>>>>>>>> I'll
>> ???? >>>>>>>>>>>> ?????? let you know the results once they are done.
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>> Please also update the bug title both in JBS and
>> the changeset.
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>> Cheers,
>> ???? >>>>>>>>>>>> Stefan
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>> > I changed the method name, which propagated a
>> change to:
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>
>> ???? >>>>>>>>>
>> ???? >>>>>>>
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>> > I tried testing your test file. It exists in my
>> branch (if
>> ???? >>>>>>> the
>> ???? >>>>>>>>>>>> same) under:
>> ???? >>>>>>>>>>>> > hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>> > and interestingly (which generally means I did
>> something
>> ???? >>>>>>>>> wrong),
>> ???? >>>>>>>>>>> it
>> ???? >>>>>>>>>>>> > passed before/after the change so I could not
>> verify that
>> ???? >>>>>>> this
>> ???? >>>>>>>>> is
>> ???? >>>>>>>>>>>> ?????? a test
>> ???? >>>>>>>>>>>> > showing that all is well in the world on my side.
>> Any ideas
>> ???? >>>>>>> of
>> ???? >>>>>>>>>>>> what I
>> ???? >>>>>>>>>>>> > did wrong?
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>> > I did again test it for
>> hotspot/jtreg/compiler/aot/ and
>> ???? >>>>>>>>>>>> > hotspot/jtreg/serviceability/jvmti and it passes
>> those.
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>> > Thanks for all your help,
>> ???? >>>>>>>>>>>> > Jc
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>> > On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson
>> ???? >>>>>>>>>>>> > <stefan.johansson at oracle.com
>> <mailto:stefan.johansson at oracle.com> <mailto:
>> ???? >>>>>>>>> stefan.johansson at oracle.com
>> <mailto:stefan.johansson at oracle.com>>
>> ???? >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com
>> <mailto:stefan.johansson at oracle.com>
>> ???? >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com
>> <mailto:stefan.johansson at oracle.com>>>> wrote:
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>> >???? Hi JC,
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>> >???? On 2018-04-11 00:56, JC Beyler wrote:
>> ???? >>>>>>>>>>>> >????? > Small update:
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >????? > Here is the fixed webrev for the '{' that
>> were out of
>> ???? >>>>>>>>>>>> alignment.
>> ???? >>>>>>>>>>>> >???? This
>> ???? >>>>>>>>>>>> >????? > passed release build JTREG
>> ???? >>>>>>>>>>>> ?????? for hotspot/jtreg/compiler/jvmti (just
>> ???? >>>>>>>>>>>> >???? to run
>> ???? >>>>>>>>>>>> >????? > something as a smoke screen)
>> ???? >>>>>>>>>>>> ?????? and hotspot/jtreg/compiler/aot/ (to
>> ???? >>>>>>>>>>>> >???? test
>> ???? >>>>>>>>>>>> >????? > Graal).
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >???? I think this looks better, I agree that
>> leaving _end is
>> ???? >>>>>>>>>>>> tempting to
>> ???? >>>>>>>>>>>> >???? avoid a lot of change, but I think this will
>> be better
>> ???? >>>>>>> in
>> ???? >>>>>>>>> the
>> ???? >>>>>>>>>>>> long run.
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>> >???? I still miss the changes to make the SA work.
>> To see a
>> ???? >>>>>>>>>>>> problem you
>> ???? >>>>>>>>>>>> >???? can run:
>> ???? >>>>>>>>>>>> >???? make CONF=fast run-test
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>
>> TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>> >???? Cheers,
>> ???? >>>>>>>>>>>> >???? Stefan
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>> >????? > Let me know what you think,
>> ???? >>>>>>>>>>>> >????? > Jc
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >????? > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler
>> ???? >>>>>>>>>>>> <jcbeyler at google.com <mailto:jcbeyler at google.com>
>> ??? <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>
>> ???? >>>>>>>>>>>> > <mailto:jcbeyler at google.com
>> <mailto:jcbeyler at google.com>
>> ??? <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>
>> ???? >>>>>>>>>
>> ???? >>>>>>>>>>>> >????? > <mailto:jcbeyler at google.com
>> <mailto:jcbeyler at google.com> <mailto:
>> ???? >>>>>>> jcbeyler at google.com <mailto:jcbeyler at google.com>
>> ???? >>>>>>>>>>
>> ???? >>>>>>>>>>>> <mailto:jcbeyler at google.com
>> <mailto:jcbeyler at google.com>
>> ??? <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>>>>
>> ???? >>>>>>>>> wrote:
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >????? >???? Hi Karen and Stefan,
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >????? >???? @Stefan: Naming is hard :)
>> ???? >>>>>>>>>>>> >????? >???? @Karen: thanks for the Graal comment,
>> I fixed it
>> ???? >>>>>>> in
>> ???? >>>>>>>>>>>> ?????? the new
>> ???? >>>>>>>>>>>> >???? webrev,
>> ???? >>>>>>>>>>>> >????? >???? let me know what you think :)
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >????? >???? I think the naming convention
>> suggested in this
>> ???? >>>>>>>>> webrev
>> ???? >>>>>>>>>>>> came from
>> ???? >>>>>>>>>>>> >????? >???? conversations in for JEP-331 and I am
>> actually
>> ???? >>>>>>>>>>> relatively
>> ???? >>>>>>>>>>>> >????? > indifferent to the final result (as long
>> as we
>> ???? >>>>>>> have
>> ???? >>>>>>>>>>>> some form of
>> ???? >>>>>>>>>>>> >????? >???? forward progress :)). To be honest,
>> I'd also be
>> ???? >>>>>>>>> happy
>> ???? >>>>>>>>>>>> ?????? to just
>> ???? >>>>>>>>>>>> >???? leave
>> ???? >>>>>>>>>>>> >????? >???? _end as is for all architectures and
>> Graal and
>> ???? >>>>>>> have
>> ???? >>>>>>>>> a
>> ???? >>>>>>>>>>> new
>> ???? >>>>>>>>>>>> >????? > _allocation_end. However, during initial
>> reviews
>> ???? >>>>>>> of
>> ???? >>>>>>>>>>>> JEP-331
>> ???? >>>>>>>>>>>> >???? it was
>> ???? >>>>>>>>>>>> >????? >???? deemed complicated to understand:
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >????? >???? _end -> the _end or sampling end
>> ???? >>>>>>>>>>>> >????? >???? _allocation_end -> end pointer for the
>> last
>> ???? >>>>>>> possible
>> ???? >>>>>>>>>>>> allocation
>> ???? >>>>>>>>>>>> >????? >???? hard_end -> allocation end + reserved
>> space
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >????? >???? That is how this naming came up and
>> why hard_end
>> ???? >>>>>>>>> went
>> ???? >>>>>>>>>>> to
>> ???? >>>>>>>>>>>> > "reserved_end".
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >????? >???? I'm really indifferent, so I offer as
>> a perusal:
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >????? >???? I noticed a few problems of alignement
>> of '{' so
>> ???? >>>>>>>>> I'll
>> ???? >>>>>>>>>>>> ?????? go fix
>> ???? >>>>>>>>>>>> >???? that.
>> ???? >>>>>>>>>>>> >????? >???? Basically this webrev does the following:
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >????? >???? - Uses fast_path_end instead of end
>> ???? >>>>>>>>>>>> >????? >???? - Reverts hard_end back to where it was
>> ???? >>>>>>>>>>>> >????? >???? - Adds the changes to Graal; there is
>> a bunch of
>> ???? >>>>>>>>>>>> changes in Graal
>> ???? >>>>>>>>>>>> >????? >???? because Graal still contains a bit of
>> code doing
>> ???? >>>>>>>>>>>> fasttlabrefills.
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >????? >???? Let me know what you think!
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >????? >???? Thanks,
>> ???? >>>>>>>>>>>> >????? >???? Jc
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >????? >???? On Tue, Apr 10, 2018 at 6:56 AM Karen
>> Kinnear
>> ???? >>>>>>>>>>>> >????? > <karen.kinnear at oracle.com
>> <mailto:karen.kinnear at oracle.com>
>> ???? >>>>>>>>>>>> <mailto:karen.kinnear at oracle.com
>> <mailto:karen.kinnear at oracle.com>> <mailto:
>> ???? >>>>>>>>> karen.kinnear at oracle.com
>> <mailto:karen.kinnear at oracle.com>
>> ???? >>>>>>>>>>>> <mailto:karen.kinnear at oracle.com
>> <mailto:karen.kinnear at oracle.com>>>
>> ???? >>>>>>>>>>>> > <mailto:karen.kinnear at oracle.com
>> <mailto:karen.kinnear at oracle.com>
>> ???? >>>>>>>>>>>> <mailto:karen.kinnear at oracle.com
>> <mailto:karen.kinnear at oracle.com>> <mailto:
>> ???? >>>>>>>>> karen.kinnear at oracle.com
>> <mailto:karen.kinnear at oracle.com>
>> ???? >>>>>>>>>>>> <mailto:karen.kinnear at oracle.com
>> <mailto:karen.kinnear at oracle.com>>>>>
>> ???? >>>>>>>>>>>> >???? wrote:
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >????? >???????? Hi JC,
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >????? >???????? A comment about Graal. The impact
>> on Graal
>> ???? >>>>>>> for
>> ???? >>>>>>>>> this
>> ???? >>>>>>>>>>>> > particular
>> ???? >>>>>>>>>>>> >????? >???????? change would be to break it - so
>> you?ll need
>> ???? >>>>>>>>>>>> >????? >???????? to complete the Graal changes for
>> this
>> ???? >>>>>>> renaming.
>> ???? >>>>>>>>>>>> That isn?t
>> ???? >>>>>>>>>>>> >????? >???????? optional or something that could be a
>> ???? >>>>>>>>> follow-on. It
>> ???? >>>>>>>>>>>> > >???????? is not ok to break a feature, even an
>> ???? >>>>>>>>> experimental
>> ???? >>>>>>>>>>>> one.
>> ???? >>>>>>>>>>>> >???? We will
>> ???? >>>>>>>>>>>> >????? >???????? discuss in the other thread potential
>> ???? >>>>>>> phasing of
>> ???? >>>>>>>>>>>> adding
>> ???? >>>>>>>>>>>> >???? sampling.
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >????? >???????? I did not do a thorough search
>> -you can do
>> ???? >>>>>>> that
>> ???? >>>>>>>>> -
>> ???? >>>>>>>>>>>> ?????? I did find
>> ???? >>>>>>>>>>>> >????? > src/jdk.internal.vm.compiler/share/classes/
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>
>> ???? >>>>>>>>>
>> ???? >>>>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>> ???? >>>>>>>>>>>> > >??????????? public final int threadTlabOffset =
>> ???? >>>>>>>>>>>> >????? > getFieldOffset("Thread::_tlab",
>> ???? >>>>>>> Integer.class,
>> ???? >>>>>>>>>>>> > >???????? "ThreadLocalAllocBuffer");
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>
>> ???? >>>>>>>>>
>> ???? >>>>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>> ???? >>>>>>>>>>>> > >??????????? private final int
>> ???? >>>>>>>>>>>> threadLocalAllocBufferStartOffset =
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_start",
>> ???? >>>>>>>>>>>> > Integer.class,
>> ???? >>>>>>>>>>>> >????? >???????? "HeapWord*");
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>
>> ???? >>>>>>>>>
>> ???? >>>>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>> ???? >>>>>>>>>>>> > >??????????? private final int
>> ???? >>>>>>>>>>> threadLocalAllocBufferEndOffset =
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_end",
>> ???? >>>>>>>>>>>> Integer.class,
>> ???? >>>>>>>>>>>> >????? >???????? "HeapWord*");
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>
>> ???? >>>>>>>>>
>> ???? >>>>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>> ???? >>>>>>>>>>>> > >??????????? private final int
>> ???? >>>>>>>>>>> threadLocalAllocBufferTopOffset =
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_top",
>> ???? >>>>>>>>>>>> Integer.class,
>> ???? >>>>>>>>>>>> >????? >???????? "HeapWord*");
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>
>> ???? >>>>>>>>>
>> ???? >>>>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>> ???? >>>>>>>>>>>> > >??????????? private final int
>> ???? >>>>>>>>>>>> threadLocalAllocBufferPfTopOffset =
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_pf_top",
>> ???? >>>>>>>>>>>> > Integer.class,
>> ???? >>>>>>>>>>>> >????? >???????? "HeapWord*");
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>
>> ???? >>>>>>>>>
>> ???? >>>>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>> ???? >>>>>>>>>>>> > >??????????? private final int
>> ???? >>>>>>>>>>>> > threadLocalAllocBufferSlowAllocationsOffset
>> ???? >>>>>>>>>>>> >????? >???????? =
>> ???? >>>>>>>>>>>>
>> getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
>> ???? >>>>>>>>>>>> >????? >???????? Integer.class, "unsigned");
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>
>> ???? >>>>>>>>>
>> ???? >>>>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>> ???? >>>>>>>>>>>> > >??????????? private final int
>> ???? >>>>>>>>>>>> > threadLocalAllocBufferFastRefillWasteOffset
>> ???? >>>>>>>>>>>> >????? >???????? =
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>
>> getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
>> ???? >>>>>>>>>>>> > >???????? Integer.class, "unsigned");
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>
>> ???? >>>>>>>>>
>> ???? >>>>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>> ???? >>>>>>>>>>>> > >??????????? private final int
>> ???? >>>>>>>>>>>> > threadLocalAllocBufferNumberOfRefillsOffset
>> ???? >>>>>>>>>>>> >????? >???????? =
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>
>> getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
>> ???? >>>>>>>>>>>> > >???????? Integer.class, "unsigned");
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>
>> ???? >>>>>>>>>
>> ???? >>>>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>> ???? >>>>>>>>>>>> > >??????????? private final int
>> ???? >>>>>>>>>>>> >????? > threadLocalAllocBufferRefillWasteLimitOffset
>> ???? >>>>>>> =
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>>
>> getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
>> ???? >>>>>>>>>>>> >????? >???????? Integer.class, "size_t");
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>
>> ???? >>>>>>>>>
>> ???? >>>>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>> ???? >>>>>>>>>>>> > >??????????? private final int
>> ???? >>>>>>>>>>>> > threadLocalAllocBufferDesiredSizeOffset =
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>>
>> getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
>> ???? >>>>>>>>>>>> >????? >???????? Integer.class, "size_t");
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>
>> ???? >>>>>>>>>
>> ???? >>>>>>>
>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>> ???? >>>>>>>>>>>> > >??????????? public final int tlabAlignmentReserve =
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>
>> ???? >>>>>>>>>
>> ???? >>>>>>>
>> getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
>> ???? >>>>>>>>>>>> > >???????? Integer.class, "size_t?);
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >????? >???????? hope this helps,
>> ???? >>>>>>>>>>>> >????? >???????? Karen
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >????? >>???????? On Apr 10, 2018, at 7:04 AM, Stefan
>> ???? >>>>>>> Johansson
>> ???? >>>>>>>>>>>> > >> <stefan.johansson at oracle.com
>> <mailto:stefan.johansson at oracle.com>
>> ???? >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com
>> <mailto:stefan.johansson at oracle.com>>
>> ???? >>>>>>>>>>>> > <mailto:stefan.johansson at oracle.com
>> <mailto:stefan.johansson at oracle.com>
>> ???? >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com
>> <mailto:stefan.johansson at oracle.com>>>
>> ???? >>>>>>>>>>>> >????? >> <mailto:stefan.johansson at oracle.com
>> ??? <mailto:stefan.johansson at oracle.com>
>> ???? >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com
>> <mailto:stefan.johansson at oracle.com>>
>> ???? >>>>>>>>>>>> > <mailto:stefan.johansson at oracle.com
>> <mailto:stefan.johansson at oracle.com>
>> ???? >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com
>> <mailto:stefan.johansson at oracle.com>>>>> wrote:
>> ???? >>>>>>>>>>>> >????? >>
>> ???? >>>>>>>>>>>> >????? >>???????? Hi JC,
>> ???? >>>>>>>>>>>> >????? >>
>> ???? >>>>>>>>>>>> >????? >>???????? I realize that the names have
>> been discussed
>> ???? >>>>>>>>>>>> before but I'm
>> ???? >>>>>>>>>>>> >????? >>???????? leaning towards suggesting
>> something new. We
>> ???? >>>>>>>>>>>> discussed this
>> ???? >>>>>>>>>>>> >????? >>???????? briefly here in the office and
>> others might
>> ???? >>>>>>>>> have
>> ???? >>>>>>>>>>>> different
>> ???? >>>>>>>>>>>> >????? >>???????? opinions. One point that came up
>> is that if
>> ???? >>>>>>> we
>> ???? >>>>>>>>> do
>> ???? >>>>>>>>>>>> this
>> ???? >>>>>>>>>>>> >???? change
>> ???? >>>>>>>>>>>> >????? >>???????? and change all usages of
>> ???? >>>>>>>>>>>> JavaThread::tlab_end_offset() it
>> ???? >>>>>>>>>>>> >????? >>???????? would be good to make sure the
>> new name is
>> ???? >>>>>>>>> good.
>> ???? >>>>>>>>>>>> ?????? To us
>> ???? >>>>>>>>>>>> >????? >> _current_end is not very descriptive, but
>> ???? >>>>>>>>> naming
>> ???? >>>>>>>>>>>> ?????? is hard and
>> ???? >>>>>>>>>>>> >????? >>???????? the best we could come up with is
>> ???? >>>>>>>>> _fast_path_end
>> ???? >>>>>>>>>>>> which would
>> ???? >>>>>>>>>>>> >????? >>???????? give the code:
>> ???? >>>>>>>>>>>> >????? >> cmpptr(end, Address(thread,
>> ???? >>>>>>>>>>>> >????? >> JavaThread::tlab_fast_path_end_offset()));
>> ???? >>>>>>>>>>>> >????? >> jcc(Assembler::above, slow_case);
>> ???? >>>>>>>>>>>> >????? >>
>> ???? >>>>>>>>>>>> >????? >>???????? I think this reads pretty good
>> and is fairly
>> ???? >>>>>>>>>>>> ?? clear. If we do
>> ???? >>>>>>>>>>>> >????? >>???????? this rename I think you can
>> re-use _end in
>> ???? >>>>>>>>> JEP-331
>> ???? >>>>>>>>>>>> >???? instead of
>> ???? >>>>>>>>>>>> >????? >>???????? calling it _allocation_end. But
>> that is a
>> ???? >>>>>>> later
>> ???? >>>>>>>>>>>> review :)
>> ???? >>>>>>>>>>>> >????? >>
>> ???? >>>>>>>>>>>> >????? >>???????? Also, is there a good reason for
>> renaming
>> ???? >>>>>>>>>>>> hard_end() to
>> ???? >>>>>>>>>>>> >????? >> reserved_end()?
>> ???? >>>>>>>>>>>> >????? >>
>> ???? >>>>>>>>>>>> >????? >>???????? One additional thing, you need to
>> update
>> ???? >>>>>>> the SA
>> ???? >>>>>>>>>>>> ?????? to reflect
>> ???? >>>>>>>>>>>> >????? >>???????? this change. I think the only
>> place you
>> ???? >>>>>>> need to
>> ???? >>>>>>>>>>>> ?????? fix is in:
>> ???? >>>>>>>>>>>> >????? >>
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>>>
>> ???? >>>>>>>>>
>> ???? >>>>>>>
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
>> ???? >>>>>>>>>>>> > >>
>> ???? >>>>>>>>>>>> >????? >>???????? Thanks,
>> ???? >>>>>>>>>>>> >????? >>???????? Stefan
>> ???? >>>>>>>>>>>> >????? >>
>> ???? >>>>>>>>>>>> >????? >>???????? On 2018-04-09 19:24, JC Beyler
>> wrote:
>> ???? >>>>>>>>>>>> >????? >>>???????? Hi all,
>> ???? >>>>>>>>>>>> >????? >>>???????? Small pre-amble to this request:
>> ???? >>>>>>>>>>>> >????? >>>???????? In my work to try to get a heap
>> sampler in
>> ???? >>>>>>>>>>>> OpenJDK (via JEP
>> ???? >>>>>>>>>>>> >????? >>>???????? 331
>> ???? >>>>>>>>>>>> > <https://bugs.openjdk.java.net/browse/JDK-8171119>),
>> ???? >>>>>>> I'm
>> ???? >>>>>>>>>>>> > >>>???????? trying to reduce the footprint of my
>> ???? >>>>>>> change so
>> ???? >>>>>>>>>>>> that the
>> ???? >>>>>>>>>>>> >????? >>> integration can be easier. I was told that
>> ???? >>>>>>>>>>>> generally a JEP
>> ???? >>>>>>>>>>>> >????? >>>???????? webrev should be feature
>> complete and go in
>> ???? >>>>>>>>>>> at-once.
>> ???? >>>>>>>>>>>> > However,
>> ???? >>>>>>>>>>>> >????? >>>???????? with the change touching quite a
>> bit of
>> ???? >>>>>>>>> various
>> ???? >>>>>>>>>>> code
>> ???? >>>>>>>>>>>> >???? pieces,
>> ???? >>>>>>>>>>>> >????? >>>???????? I was trying to figure out what
>> could be
>> ???? >>>>>>>>>>>> separated as not
>> ???? >>>>>>>>>>>> >????? >>>???????? "part of the feature".
>> ???? >>>>>>>>>>>> >????? >>>???????? I asked around and said that
>> perhaps a
>> ???? >>>>>>>>> solution
>> ???? >>>>>>>>>>>> would be to
>> ???? >>>>>>>>>>>> >????? >>>???????? cut up the renaming of TLAB's
>> end field
>> ???? >>>>>>> that I
>> ???? >>>>>>>>>>>> ?????? do in that
>> ???? >>>>>>>>>>>> >????? >>>???????? webrev. Because I'm renaming a
>> field in
>> ???? >>>>>>> TLAB
>> ???? >>>>>>>>>>> used by
>> ???? >>>>>>>>>>>> >???? various
>> ???? >>>>>>>>>>>> >????? >>> backends for that work, I have to update
>> ???? >>>>>>> every
>> ???? >>>>>>>>>>>> architecture
>> ???? >>>>>>>>>>>> >????? >>> dependent code to reflect it.
>> ???? >>>>>>>>>>>> >????? >>>???????? I entirely understand that
>> perhaps this is
>> ???? >>>>>>> not
>> ???? >>>>>>>>>>>> ?????? in the
>> ???? >>>>>>>>>>>> >???? habits
>> ???? >>>>>>>>>>>> >????? >>>???????? and very potentially might not
>> be the way
>> ???? >>>>>>>>> things
>> ???? >>>>>>>>>>> are
>> ???? >>>>>>>>>>>> > >>>???????? generally done. If so, I apologize
>> and let
>> ???? >>>>>>> me
>> ???? >>>>>>>>>>>> know if you
>> ???? >>>>>>>>>>>> >????? >>>???????? would not want this to go in
>> separately :)
>> ???? >>>>>>>>>>>> >????? >>>???????? Final note: there is still a
>> chance JEP-331
>> ???? >>>>>>>>> does
>> ???? >>>>>>>>>>>> ?????? not go in.
>> ???? >>>>>>>>>>>> >????? >>>???????? If it does not, we can leave the
>> new name
>> ???? >>>>>>> in
>> ???? >>>>>>>>>>>> place or I'll
>> ???? >>>>>>>>>>>> >????? >>>???????? happily revert it. I can even
>> create an
>> ???? >>>>>>> issue
>> ???? >>>>>>>>> to
>> ???? >>>>>>>>>>>> track this
>> ???? >>>>>>>>>>>> >????? >>>???????? if that makes it easier for all.
>> ???? >>>>>>>>>>>> >????? >>>???????? End of the pre-amble.
>> ???? >>>>>>>>>>>> >????? >>>???????? The 33-line change webrev in
>> question is
>> ???? >>>>>>> here:
>> ???? >>>>>>>>>>>> > >>>
>> ???? >>>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
>> ???? >>>>>>>>>>>> > >>>???????? I fixed all the architectures and
>> JVMCI and
>> ???? >>>>>>>>> ran
>> ???? >>>>>>>>>>>> ?????? a few
>> ???? >>>>>>>>>>>> >???? sanity
>> ???? >>>>>>>>>>>> >????? >>>???????? tests to ensure I had not missed
>> anything.
>> ???? >>>>>>>>>>>> >????? >>>???????? Thanks for your help and I hope
>> this is not
>> ???? >>>>>>>>> too
>> ???? >>>>>>>>>>> much
>> ???? >>>>>>>>>>>> > trouble,
>> ???? >>>>>>>>>>>> >????? >>>???????? Jc
>> ???? >>>>>>>>>>>> >????? >>>???????? Ps: there is a graal change that
>> needs to
>> ???? >>>>>>>>> happen
>> ???? >>>>>>>>>>>> ?????? but I was
>> ???? >>>>>>>>>>>> >????? >>>???????? not sure who/where
>> <https://teams.googleplex.com/u/where>
>> ???? >>>>>>> <https://teams.googleplex.com/u/where>
>> ???? >>>>>>>>> <https://teams.googleplex.com/u/where>
>> ???? >>>>>>>>>>> <https://teams.googleplex.com/u/where>
>> ???? >>>>>>>>>>>> <https://teams.googleplex.com/u/where>
>> ???? >>>>>>>>>>>> > <https://teams.googleplex.com/u/where>
>> ???? >>>>>>>>>>>> > <https://teams.googleplex.com/u/where> to
>> ???? >>>>>>>>>>>> >????? >>>???????? ask about it. I was told it
>> could happen
>> ???? >>>>>>> in a
>> ???? >>>>>>>>>>>> separate
>> ???? >>>>>>>>>>>> >????? >>>???????? webrev. Can anyone point me to
>> the right
>> ???? >>>>>>>>>>> direction?
>> ???? >>>>>>>>>>>> >???? Should it
>> ???? >>>>>>>>>>>> >????? >>>???????? just be hotspot-compiler-dev?
>> ???? >>>>>>>>>>>> >????? >
>> ???? >>>>>>>>>>>> >
>> ???? >>>>>>>>>>>>
>> ???? >>>>>>>>>
>> ???? >>>>>>>>>
>> ???? >>>>>>>
>> ???? >>>
>> ???? >
>>
From serguei.spitsyn at oracle.com Wed Apr 18 23:02:56 2018
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 18 Apr 2018 16:02:56 -0700
Subject: RFR (S): 8201326: Renaming ThreadLocalAllocationBuffer end to
fast_path_end
In-Reply-To: <9f9a95b5-deb0-ba74-9ef1-3d5de1d9a9ef@oracle.com>
References: <CAF9BGBwfr7t91jce4TOFQfZToVF8j_S12gEnVmuvEKtJZ-vcKw@mail.gmail.com>
<CAF9BGBxEPXLTiyD-xG_ECyveyW0PXQL0+-z7jkw3Rv4QrkkszQ@mail.gmail.com>
<ec1a3e0e-ca9b-8668-b260-1fd3e612b7f7@oracle.com>
<CAF9BGBy-LBKCwJHQPdAQ65VRcSFBwVkk9dm8MLC_nrefE_JdEw@mail.gmail.com>
<e6528c19-5691-1215-1ac5-0349801b79b5@oracle.com>
<CAF9BGBwBgyOoJTfJU_YmqYJgSZ+1985yx_sSMJC4wNJELw1XDQ@mail.gmail.com>
<e63675e1-d693-cd25-75b2-32b593e266a2@oracle.com>
<CAF9BGBz3g4yXMjf9TxrqLdMbfaswoa3U13qYTEUtv-mZCDMd8Q@mail.gmail.com>
<735b3949-d9cd-3d37-ebb4-f59ee61f18ad@oracle.com>
<ba26dc77-a5ba-b490-2a03-cf4abd79ac3c@oracle.com>
<ff9474cd-6f07-446c-12b5-2dafbca35ce3@oracle.com>
<19c34a75-e1f5-f1b2-2cd7-91300e7979c3@oracle.com>
<30260bf8-765b-3227-87c0-85f001ca4c55@oracle.com>
<129b0875-52e8-eabc-258a-5ad4f36aa226@oracle.com>
<CAF9BGBypU+AexV5vt-mJD5rLAqxfORwYa0f16s9iWwRhF2Z+3w@mail.gmail.com>
<b0699a0d-80c8-4bd1-3fd5-c8ac60b75e90@oracle.com>
<9f9a95b5-deb0-ba74-9ef1-3d5de1d9a9ef@oracle.com>
Message-ID: <86bf4bd4-530d-1694-668a-547ae02c59bc@oracle.com>
On 4/18/18 15:55, serguei.spitsyn at oracle.com wrote:
> Vladimir,
>
> Thanks a lot for making this resolved!
> It safes our time as we will stop all these renaming discussions now.
A typo above: safes => saves
Sorry for spamming.
Thanks,
Serguei
> On 4/18/18 15:06, Vladimir Kozlov wrote:
>> On 4/18/18 2:54 PM, JC Beyler wrote:
>>> Seems like there is no consensus really except that changing it has
>>> a few headaches involved. Should we then do the implementation of
>>> "8171119: Low-Overhead HeapProfiling" without changing the _end
>>> field and postpone this conversation to afterwards when Graal
>>> handles multi-release in a more mature?manner (read has been doing
>>> it for a while).
>>
>> I would prefer this way.
>
> +1
> One more question is if we have to close this enhancement as NAI or to
> keep it for post JEP renaming.
> I'd prefer to close it.
>
>>
>> Thanks,
>> Vladimir
>>
>>>
>>> Or is there still a path forward? (Re)Naming is hard, this is proof
>>> of that.
>>>
>>> That puts us back to what I had originally:
>>> _end: the fast path end, can be the allocation end or the
>>> to-be-sampled end
>>> _allocation_end: the actual allocation end of the current TLAB
>>> hard_end: _allocation_end?+ reserved space
>
> Right.
> It looks like the only way to move forward.
> It will make it simpler.
>
> Thanks,
> Serguei
>
>>>
>>> Thanks for all of your input and help on this,
>>> Jc
>>>
>>> On Wed, Apr 18, 2018 at 12:46 PM Vladimir Kozlov
>>> <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>>
>>> ??? On 4/18/18 12:15 PM, dean.long at oracle.com
>>> <mailto:dean.long at oracle.com> wrote:
>>> ???? > I will defer to Vladimir, but I would have been happy with
>>> something like:
>>> ???? >
>>> ???? > // preserve simple start/end abstraction for compiler
>>> ???? > HeapWord* end() const ? ? ?? { return fast_path_end(); }
>>> ???? > static ByteSize end_offset() { return fast_path_end_offset(); }
>>>
>>> ??? This is ugly.
>>>
>>> ???? >
>>> ???? > even though end_offset() would then refer to a virtual "end"
>>> field.
>>> ???? >
>>> ???? > Vladimir, are you also approving the Graal changes? :-)
>>>
>>> ??? You really made my day :(
>>>
>>> ??? S..t! We can't make this change in Graal as suggested because we
>>> will break Graal's JDK 8 support.
>>> ??? Graal has direct access to VM's fields through JVMCI. You have
>>> to guard change with JDK version
>>> ??? check.
>>>
>>> ??? Labs start addressing multi-releases so it may be not big issue
>>> anymore. See Doug's comment for
>>> ??? 8201318 RFR.
>>>
>>> ??? Anyway you have to file new PR (pull request) for Graal changes on
>>> ??? https://github.com/graalvm/mx/pulls.
>>> ??? And I am not sponsoring this. I don't think such renaming worse
>>> all our efforts.
>>>
>>> ??? Good luck,
>>> ??? Vladimir
>>>
>>> ???? >
>>> ???? > dl
>>> ???? >
>>> ???? > On 4/18/18 11:02 AM, Vladimir Kozlov wrote:
>>> ???? >> Ganging up on us ;)
>>> ???? >>
>>> ???? >> Yes, I missed original discussion about renaming on GC list.
>>> ???? >>
>>> ???? >> From my point of view next code looks better because it
>>> seems compare related values:
>>> ???? >>
>>> ???? >> cmpptr(end, Address(thread, JavaThread::tlab_end_offset()));
>>> ???? >>
>>> ???? >> But I would not strongly object renaming to move this JEP
>>> forward. Consider changes reviewed
>>> ??? and approved by me.
>>> ???? >>
>>> ???? >> Regards,
>>> ???? >> Vladimir
>>> ???? >>
>>> ???? >> On 4/18/18 6:29 AM, Daniel D. Daugherty wrote:
>>> ???? >>> Greetings,
>>> ???? >>>
>>> ???? >>> The idea of splitting this change off from "8171119:
>>> Low-Overhead Heap Profiling"
>>> ???? >>> came up during the design review. It might have been me
>>> that suggested the split
>>> ???? >>> off or it was someone else. Sorry I don't remember.
>>> ???? >>>
>>> ???? >>> In any case, the rename of "end" to "fast_path_end" is just
>>> a clarity change to
>>> ???? >>> the existing code and I think that change can easily stand
>>> on its own. That is
>>> ???? >>> particularly true if the accessors are renamed at the same
>>> time. I think having
>>> ???? >>> the accessor names match the field names is a pretty well
>>> known HotSpot rule
>>> ???? >>> so I'm not sure why we're talking about not renaming the
>>> accessors...
>>> ???? >>>
>>> ???? >>> Personally, I prefer "_fast_path_end" over "_current_end".
>>> ???? >>>
>>> ???? >>> Dan
>>> ???? >>>
>>> ???? >>>
>>> ???? >>> On 4/18/18 4:04 AM, Stefan Johansson wrote:
>>> ???? >>>> Hi,
>>> ???? >>>>
>>> ???? >>>> On 2018-04-18 02:02, Vladimir Kozlov wrote:
>>> ???? >>>>> ?> I think I like better not to add it. If no one is
>>> using it, there should be
>>> ???? >>>>> ?> no reason to add it? By not adding it, it also makes
>>> any future wish to
>>> ???? >>>>> ?> have it a nice indicator of: hey why do you want to
>>> see this? Same as
>>> ???? >>>>> ?> hard_end btw which is not visible. Am I missing
>>> something?
>>> ???? >>>>>
>>> ???? >>>>> I say "may" ;)
>>> ???? >>>>> You don't need new function if there is no use.
>>> ???? >>>>>
>>> ???? >>>>> ?>
>>> ???? >>>>> ?> So to summarize, the current consensus:
>>> ???? >>>>> ?>??? - _end can be renamed either to _current_end or
>>> _fast_path_end; that is
>>> ???? >>>>> ?> still up to a vote and choice :)
>>> ???? >>>>>
>>> ???? >>>>> Please, use _current_end. I was thinking about
>>> _sample_end but it does not reflect double
>>> ??? usage.
>>> ???? >>>>
>>> ???? >>>> I'm not sure if you have seen the discussion about naming
>>> on hotspot-gc-dev, but I and
>>> ??? others think that
>>> ???? >>>> _current_end doesn't describe the usage at all. Naming it
>>> _fast_path_end would clearly
>>> ??? state what it is, _sample_end
>>> ???? >>>> or something similar also crossed my mind but I think the
>>> code reads a lot better in the
>>> ??? compiler with the name
>>> ???? >>>> fast_path_end.
>>> ???? >>>>
>>> ???? >>>>>
>>> ???? >>>>> ?>??? - the access method end() and tlab_end_offset()
>>> remain the same to not
>>> ???? >>>>> ?> modify JIT/interpreter codes
>>> ???? >>>> I would find this very unfortunate, having accessors that
>>> don't match the members can
>>> ??? easily lead to
>>> ???? >>>> misunderstanding, especially if we have three different
>>> *_end members. Why do you think
>>> ??? this is the best way forward?
>>> ???? >>>>
>>> ???? >>>> My first thought was also that it would be nice to avoid
>>> all the compiler changes, but
>>> ??? then we would have to stick
>>> ???? >>>> with _end being the sample/current/fast-path end and I'm
>>> not sure that is a better
>>> ??? solution. I don't see the big
>>> ???? >>>> problem with changing those accessors to what they really
>>> access and I think the compiler
>>> ??? code reads good even after
>>> ???? >>>> the change. For example:
>>> ???? >>>> cmpptr(end, Address(thread,
>>> JavaThread::tlab_fast_path_end_offset()));
>>> ???? >>>> jcc(Assembler::above, slow_case);
>>> ???? >>>>
>>> ???? >>>>> ?>
>>> ???? >>>>> ?> If all agree to this, then the consequences are:
>>> ???? >>>>> ?>??? - JDK-8201326 becomes useless
>>> ???? >>>>> ?>??? - The work for JEP-331 becomes smaller in terms of
>>> file changes
>>> ???? >>>>> ?>??? - I'll still be needing a decision on the renaming
>>> of the TLAB _end field
>>> ???? >>>>> ?> (current suggestions are _current_end and
>>> _fast_path_end).
>>> ???? >>>>
>>> ???? >>>> We'll see where we end up. If JDK-8201326 ends up being a
>>> separate change I think it
>>> ??? should be pushed at the same
>>> ???? >>>> time as the rest of the JEP changes. To me it only makes
>>> sense to have it in the code base
>>> ??? if we also have the rest
>>> ???? >>>> of the changes.
>>> ???? >>>>
>>> ???? >>>> Thanks,
>>> ???? >>>> Stefan
>>> ???? >>>>
>>> ???? >>>>>
>>> ???? >>>>> Sounds good to me.
>>> ???? >>>>>
>>> ???? >>>>> Thanks,
>>> ???? >>>>> Vladimir
>>> ???? >>>>>
>>> ???? >>>>> On 4/17/18 4:51 PM, JC Beyler wrote:
>>> ???? >>>>>> Hi Vladimir and Dean,
>>> ???? >>>>>>
>>> ???? >>>>>> @Dean: seems that Vladimir is in agreement with you for
>>> renaming just the
>>> ???? >>>>>> field and not the method names so ack to your answer
>>> that came at the same
>>> ???? >>>>>> time :)
>>> ???? >>>>>>
>>> ???? >>>>>>
>>> ???? >>>>>>> Yes, from the beginning such changes should be
>>> discussed on common
>>> ???? >>>>>>> hotspot-dev list since all
>>> ???? >>>>>>> Hotspot's parts are affected.
>>> ???? >>>>>>>
>>> ???? >>>>>>
>>> ???? >>>>>> Sorry, being new to the scene, most of the conversation
>>> had been going on
>>> ???? >>>>>> in serviceability-dev.
>>> ???? >>>>>>
>>> ???? >>>>>>
>>> ???? >>>>>>>
>>> ???? >>>>>>> Graal specific question could be send to
>>> hotspot-compiler-dev list with
>>> ???? >>>>>>> [Graal] in subject.
>>> ???? >>>>>>>
>>> ???? >>>>>>> I looked on JEP's changes
>>> ???? >>>>>>> http://cr.openjdk.java.net/~jcbeyler/8171119/webrev.02/
>>> to understand how
>>> ???? >>>>>>> it works.
>>> ???? >>>>>>>
>>> ???? >>>>>>> Few questions about proposed JEP changes so I can
>>> understand it.
>>> ???? >>>>>>>
>>> ???? >>>>>>> You introducing new TLAB end for sampling and adjust it
>>> so that
>>> ???? >>>>>>> allocations in JITed code and
>>> ???? >>>>>>> Interpreter it will trigger slow path allocation where
>>> you do sampling.
>>> ???? >>>>>>> Right?
>>> ???? >>>>>>>
>>> ???? >>>>>>
>>> ???? >>>>>> Yes that is correct; if sampling is enabled of course.
>>> Btw, this is the current
>>> ???? >>>>>> webrev
>>> <http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.15/>.
>>> ???? >>>>>>
>>> ???? >>>>>>
>>> ???? >>>>>>>
>>> ???? >>>>>>> Do all changes to _end, _actual_end and other TLAB
>>> fields happen during
>>> ???? >>>>>>> slow allocation?
>>> ???? >>>>>>>
>>> ???? >>>>>>
>>> ???? >>>>>> Yes, to that effect, with Robbin's help, we finalized
>>> deprecating the
>>> ???? >>>>>> FastTLabRefill via JDK-8194084
>>> ???? >>>>>> <https://bugs.openjdk.java.net/browse/JDK-8194084>.
>>> Seems like I/we missed
>>> ???? >>>>>> that Graal does this as well. I filed GRAAL-64
>>> ???? >>>>>> <https://bugs.openjdk.java.net/browse/GRAAL-64> to not
>>> forget that Graal
>>> ???? >>>>>> would need to get that fixed.
>>> ???? >>>>>>
>>> ???? >>>>>>
>>> ???? >>>>>>
>>> ???? >>>>>>>
>>> ???? >>>>>>> I am concern about concurrent accesses to these fields
>>> from other threads
>>> ???? >>>>>>> if you have them (I don't
>>> ???? >>>>>>> see).
>>> ???? >>>>>>>
>>> ???? >>>>>>
>>> ???? >>>>>> Yes that is why we deprecated the FastTlabRefill. Other
>>> threads should not
>>> ???? >>>>>> be changing the thread local data structure so I don't
>>> see an issue there.
>>> ???? >>>>>> The major issue was that the fast paths could change the
>>> tlab without going
>>> ???? >>>>>> via the slowpath.
>>> ???? >>>>>>
>>> ???? >>>>>> I had a fix to detect this issue but removed it once
>>> JDK-8194084 was done;
>>> ???? >>>>>> Graal was missed in that work so that is why if sampling
>>> were enabled with
>>> ???? >>>>>> Graal, there is a chance things would break currently.
>>> That will get fixed
>>> ???? >>>>>> via GRAAL-64
>>> <https://bugs.openjdk.java.net/browse/GRAAL-64> whether it is
>>> ???? >>>>>> rendering the code also obsolete and going to the
>>> slowpath or whether it is
>>> ???? >>>>>> adding my fix again to detect a fastpath TLAB
>>> reallocation happened.
>>> ???? >>>>>>
>>> ???? >>>>>>
>>> ???? >>>>>>>
>>> ???? >>>>>>> Renaming. I am fine with renaming if it helps to
>>> understand code better. I
>>> ???? >>>>>>> agree with proposed
>>> ???? >>>>>>> changes to fields name:
>>> ???? >>>>>>>
>>> ???? >>>>>>> _current_end
>>> ???? >>>>>>> _allocation_end
>>> ???? >>>>>>>
>>> ???? >>>>>>> But, as Dean, I would suggest to keep names of access
>>> functions. This way
>>> ???? >>>>>>> we can say that allocation
>>> ???? >>>>>>> code in Interpreter and JITed code stay the same.
>>> ???? >>>>>>>
>>> ???? >>>>>>
>>> ???? >>>>>> Sounds good to me, then in that case, this webrev will
>>> disappear, which
>>> ???? >>>>>> also makes me happy, since it simplifies a lot of things
>>> (and reduces code
>>> ???? >>>>>> change).
>>> ???? >>>>>>
>>> ???? >>>>>>
>>> ???? >>>>>>>
>>> ???? >>>>>>> You may need only new method to access _allocation_end
>>> in places which
>>> ???? >>>>>>> look for real end of TLAB.
>>> ???? >>>>>>>
>>> ???? >>>>>>
>>> ???? >>>>>> I think I like better not to add it. If no one is using
>>> it, there should be
>>> ???? >>>>>> no reason to add it? By not adding it, it also makes any
>>> future wish to
>>> ???? >>>>>> have it a nice indicator of: hey why do you want to see
>>> this? Same as
>>> ???? >>>>>> hard_end btw which is not visible. Am I missing something?
>>> ???? >>>>>>
>>> ???? >>>>>> So to summarize, the current consensus:
>>> ???? >>>>>> ?? - _end can be renamed either to _current_end or
>>> _fast_path_end; that is
>>> ???? >>>>>> still up to a vote and choice :)
>>> ???? >>>>>> ?? - the access method end() and tlab_end_offset()
>>> remain the same to not
>>> ???? >>>>>> modify JIT/interpreter codes
>>> ???? >>>>>>
>>> ???? >>>>>> If all agree to this, then the consequences are:
>>> ???? >>>>>> ?? - JDK-8201326 becomes useless
>>> ???? >>>>>> ?? - The work for JEP-331 becomes smaller in terms of
>>> file changes
>>> ???? >>>>>> ?? - I'll still be needing a decision on the renaming of
>>> the TLAB _end field
>>> ???? >>>>>> (current suggestions are _current_end and _fast_path_end).
>>> ???? >>>>>>
>>> ???? >>>>>> Thanks for your help!
>>> ???? >>>>>> Jc
>>> ???? >>>>>>
>>> ???? >>>>>>
>>> ???? >>>>>>>
>>> ???? >>>>>>> Regards,
>>> ???? >>>>>>> Vladimir
>>> ???? >>>>>>>
>>> ???? >>>>>>> On 4/16/18 4:42 PM, JC Beyler wrote:
>>> ???? >>>>>>>> Hi Dean,
>>> ???? >>>>>>>>
>>> ???? >>>>>>>> I think perhaps this is also an attempt to figure out
>>> the naming of all
>>> ???? >>>>>>>> this because naming (or renaming like here) is often
>>> the start of big
>>> ???? >>>>>>>> conversations :).
>>> ???? >>>>>>>>
>>> ???? >>>>>>>> Originally, in the JEP-331 work, I had left the _end
>>> field as is and, by
>>> ???? >>>>>>>> doing so, this whole renaming webrev goes away.
>>> However, if we do that,
>>> ???? >>>>>>>> then the TLAB code contains:
>>> ???? >>>>>>>>
>>> ???? >>>>>>>> _end: the fast path end, can be the allocation end or
>>> the to-be-sampled
>>> ???? >>>>>>> end
>>> ???? >>>>>>>> _allocation_end: the actual allocation end of the
>>> current TLAB
>>> ???? >>>>>>>> hard_end: _allocation_end + reserved space
>>> ???? >>>>>>>>
>>> ???? >>>>>>>> With an early iteration of a webrev for JEP-331, a
>>> conversation occurred
>>> ???? >>>>>>>> about whether or not that was clear or not and it was
>>> determined that
>>> ???? >>>>>>> this
>>> ???? >>>>>>>> renaming was more clear:
>>> ???? >>>>>>>>
>>> ???? >>>>>>>> _current_end: the fast path end
>>> ???? >>>>>>>> _allocation_end: the actual allocation end of the
>>> current TLAB
>>> ???? >>>>>>>> reserved_end: _allocation_end + reserved space
>>> ???? >>>>>>>>
>>> ???? >>>>>>>> Because I'm trying to reduce the footprint of files
>>> changed, I pulled out
>>> ???? >>>>>>>> the renaming changes into this webrev. While talking
>>> about it with the GC
>>> ???? >>>>>>>> team, the renaming suggested became:
>>> ???? >>>>>>>>
>>> ???? >>>>>>>> _fast_path_end: the fast path end
>>> ???? >>>>>>>> _allocation_end: the actual allocation end of the
>>> current TLAB
>>> ???? >>>>>>>> hard_end: _allocation_end + reserved space
>>> ???? >>>>>>>>
>>> ???? >>>>>>>> Now, to be honest, any renaming or no renaming is fine
>>> by me. I like not
>>> ???? >>>>>>>> renaming the fields to not change the code of every
>>> backend and Graal; I
>>> ???? >>>>>>>> also like the fast_path_end rename due to it making
>>> the backend code easy
>>> ???? >>>>>>>> to read as mentioned in the GC mailing lis thread.
>>> ???? >>>>>>>>
>>> ???? >>>>>>>> So there are two questions really:
>>> ???? >>>>>>>> ???? - Should we rename the _end field and thus
>>> provoke the changes in
>>> ???? >>>>>>> this
>>> ???? >>>>>>>> webrev?
>>> ???? >>>>>>>> ???? - If we do want to change the field, should/could
>>> it go in an initial
>>> ???? >>>>>>>> webrev or should it go in the JEP-331 webrev
>>> whenever/ifever it goes in?
>>> ???? >>>>>>>> And if we do wait, could we at least converge on a
>>> renaming now so that
>>> ???? >>>>>>>> this does not become a point of contention for that
>>> webrev's review?
>>> ???? >>>>>>>>
>>> ???? >>>>>>>> If I read your answer correctly:
>>> ???? >>>>>>>> ?????? - You are saying that we should keep the _end
>>> field altogether; or
>>> ???? >>>>>>> at
>>> ???? >>>>>>>> least only rename the field not the methods to access
>>> it, thus reducing
>>> ???? >>>>>>> the
>>> ???? >>>>>>>> change scope.
>>> ???? >>>>>>>> ?????? - You are also saying to wait for the JEP-331
>>> webrev's final
>>> ???? >>>>>>> iteration
>>> ???? >>>>>>>> and integrate it in one step
>>> ???? >>>>>>>>
>>> ???? >>>>>>>> Have I understood your answer correctly?
>>> ???? >>>>>>>>
>>> ???? >>>>>>>> Again, I am fine with renaming to whatever or not
>>> renaming at all. I just
>>> ???? >>>>>>>> am trying to get forward progress here :)
>>> ???? >>>>>>>>
>>> ???? >>>>>>>> Thanks for your help!
>>> ???? >>>>>>>> Jc
>>> ???? >>>>>>>>
>>> ???? >>>>>>>> On Mon, Apr 16, 2018 at 3:29 PM <dean.long at oracle.com
>>> <mailto:dean.long at oracle.com>>
>>> ??? wrote:
>>> ???? >>>>>>>>
>>> ???? >>>>>>>>> Hi JC.? Others might disagree, but I would vote "no"
>>> on doing this
>>> ???? >>>>>>>>> renaming now, before the JEP, and even in the context
>>> of the JEP, I
>>> ???? >>>>>>>>> don't think renaming the field requires renaming all
>>> the uses.? The
>>> ???? >>>>>>>>> compiler code is only interested in the fast path, so
>>> it's implicitly
>>> ???? >>>>>>>>> understood.? Also, if there is a fast_path_end(),
>>> then isn't it logical
>>> ???? >>>>>>>>> to have fast_path_start() paired with it?? ("start"
>>> is already
>>> ???? >>>>>>>>> overloaded, but nobody is suggesting adding
>>> ???? >>>>>>>>> allocation_start()/current_start()/hard_start() are
>>> they?). My opinion
>>> ???? >>>>>>>>> is that it's fine the way it is.
>>> ???? >>>>>>>>>
>>> ???? >>>>>>>>> dl
>>> ???? >>>>>>>>>
>>> ???? >>>>>>>>> On 4/16/18 1:43 PM, JC Beyler wrote:
>>> ???? >>>>>>>>>> Hi all,
>>> ???? >>>>>>>>>>
>>> ???? >>>>>>>>>> I've left the mail thread from the hotspot-gc-dev
>>> below for tracking
>>> ???? >>>>>>>>>> purposes but will start a new request here.
>>> ???? >>>>>>>>>>
>>> ???? >>>>>>>>>> - I'm trying to push a renaming of a TLAB field to
>>> make my work for
>>> ???? >>>>>>>>> JEP-331
>>> ???? >>>>>>>>>> <http://openjdk.java.net/jeps/331> easier
>>> ???? >>>>>>>>>> ????? - There is an understanding that if JEP-331
>>> does not make it, this
>>> ???? >>>>>>>>> might
>>> ???? >>>>>>>>>> be useless and I'll revert if that is what the
>>> community wants; however
>>> ???? >>>>>>>>> the
>>> ???? >>>>>>>>>> new name seems better anyway so perhaps not?
>>> ???? >>>>>>>>>>
>>> ???? >>>>>>>>>> - The webrev renames a field used across the various
>>> back-ends and
>>> ???? >>>>>>> Graal
>>> ???? >>>>>>>>>> ????? - The webrev is here:
>>> ???? >>>>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.04/
>>> ???? >>>>>>>>>>
>>> ???? >>>>>>>>>> Could I please get some feedback on this?
>>> ???? >>>>>>>>>>
>>> ???? >>>>>>>>>> Thanks all for your help,
>>> ???? >>>>>>>>>> Jc
>>> ???? >>>>>>>>>>
>>> ???? >>>>>>>>>>
>>> ???? >>>>>>>>>>
>>> ???? >>>>>>>>>> On Fri, Apr 13, 2018 at 2:37 AM Stefan Johansson <
>>> ???? >>>>>>>>>> stefan.johansson at oracle.com
>>> <mailto:stefan.johansson at oracle.com>> wrote:
>>> ???? >>>>>>>>>>
>>> ???? >>>>>>>>>>> Hi JC,
>>> ???? >>>>>>>>>>>
>>> ???? >>>>>>>>>>> I don't have a name, but I've looked at bit more at
>>> the failures and I
>>> ???? >>>>>>>>>>> think they are unrelated and one of the local
>>> compiler engineers
>>> ???? >>>>>>> agree.
>>> ???? >>>>>>>>>>>
>>> ???? >>>>>>>>>>> I also ran some local testing and was not able to
>>> get any error with
>>> ???? >>>>>>> you
>>> ???? >>>>>>>>>>> latest changes, but verified that it doens't work
>>> without the graal
>>> ???? >>>>>>>>>>> parts. So they seem good. It might still be good to
>>> switch this over
>>> ???? >>>>>>> to
>>> ???? >>>>>>>>>>> the general hotspot-dev list to let someone with
>>> Graal knowledge to
>>> ???? >>>>>>> look
>>> ???? >>>>>>>>>>> at the change and make sure everything is correct.
>>> ???? >>>>>>>>>>>
>>> ???? >>>>>>>>>>> Thanks,
>>> ???? >>>>>>>>>>> Stefan
>>> ???? >>>>>>>>>>>
>>> ???? >>>>>>>>>>>
>>> ???? >>>>>>>>>>> On 2018-04-12 17:26, JC Beyler wrote:
>>> ???? >>>>>>>>>>>> Hi Stefan,
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>> Thanks for testing :). I've renamed the bug title
>>> in the JBS and will
>>> ???? >>>>>>>>>>>> emit a new webrev shortly. Do you have the name of
>>> a compiler
>>> ???? >>>>>>> engineer
>>> ???? >>>>>>>>>>>> in mind or should I perhaps now move this
>>> conversation to the general
>>> ???? >>>>>>>>>>>> hotspot-dev mailing list and ask there?
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>> The alternative is to add the compiler-mailing
>>> list to this email
>>> ???? >>>>>>>>> thread
>>> ???? >>>>>>>>>>>> and ask there before sending to the general list.
>>> What do you think
>>> ???? >>>>>>> is
>>> ???? >>>>>>>>>>> best?
>>> ???? >>>>>>>>>>>> Thanks for all your help,
>>> ???? >>>>>>>>>>>> Jc
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>> On Thu, Apr 12, 2018 at 2:09 AM Stefan Johansson
>>> ???? >>>>>>>>>>>> <stefan.johansson at oracle.com
>>> <mailto:stefan.johansson at oracle.com>
>>> ??? <mailto:stefan.johansson at oracle.com
>>> <mailto:stefan.johansson at oracle.com>>>
>>> ???? >>>>>>>>>>> wrote:
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>> On 2018-04-11 17:48, JC Beyler wrote:
>>> ???? >>>>>>>>>>>> > Hi Stefan,
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>> > Sorry about that, I must have missed adding the
>>> files or
>>> ???? >>>>>>>>>>>> something. Here
>>> ???? >>>>>>>>>>>> > is a webrev that added the changes for the SA file:
>>> ???? >>>>>>>>>>>> >
>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.03/
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>> No problem, this looks good. I kicked of a run in
>>> our test
>>> ???? >>>>>>> system
>>> ???? >>>>>>>>> to
>>> ???? >>>>>>>>>>>> get
>>> ???? >>>>>>>>>>>> some more coverage and have tried to include some
>>> Graal
>>> ???? >>>>>>> testing.
>>> ???? >>>>>>>>> I'll
>>> ???? >>>>>>>>>>>> let you know the results once they are done.
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>> Please also update the bug title both in JBS and
>>> the changeset.
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>> Cheers,
>>> ???? >>>>>>>>>>>> Stefan
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>> > I changed the method name, which propagated a
>>> change to:
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>
>>> ???? >>>>>>>>>
>>> ???? >>>>>>>
>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
>>>
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>> > I tried testing your test file. It exists in my
>>> branch (if
>>> ???? >>>>>>> the
>>> ???? >>>>>>>>>>>> same) under:
>>> ???? >>>>>>>>>>>> > hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>> > and interestingly (which generally means I did
>>> something
>>> ???? >>>>>>>>> wrong),
>>> ???? >>>>>>>>>>> it
>>> ???? >>>>>>>>>>>> > passed before/after the change so I could not
>>> verify that
>>> ???? >>>>>>> this
>>> ???? >>>>>>>>> is
>>> ???? >>>>>>>>>>>> ?????? a test
>>> ???? >>>>>>>>>>>> > showing that all is well in the world on my
>>> side. Any ideas
>>> ???? >>>>>>> of
>>> ???? >>>>>>>>>>>> what I
>>> ???? >>>>>>>>>>>> > did wrong?
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>> > I did again test it for
>>> hotspot/jtreg/compiler/aot/ and
>>> ???? >>>>>>>>>>>> > hotspot/jtreg/serviceability/jvmti and it passes
>>> those.
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>> > Thanks for all your help,
>>> ???? >>>>>>>>>>>> > Jc
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>> > On Wed, Apr 11, 2018 at 7:44 AM Stefan Johansson
>>> ???? >>>>>>>>>>>> > <stefan.johansson at oracle.com
>>> <mailto:stefan.johansson at oracle.com> <mailto:
>>> ???? >>>>>>>>> stefan.johansson at oracle.com
>>> <mailto:stefan.johansson at oracle.com>>
>>> ???? >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com
>>> <mailto:stefan.johansson at oracle.com>
>>> ???? >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com
>>> <mailto:stefan.johansson at oracle.com>>>> wrote:
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>> > Hi JC,
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>> > On 2018-04-11 00:56, JC Beyler wrote:
>>> ???? >>>>>>>>>>>> >????? > Small update:
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >????? > Here is the fixed webrev for the '{' that
>>> were out of
>>> ???? >>>>>>>>>>>> alignment.
>>> ???? >>>>>>>>>>>> > This
>>> ???? >>>>>>>>>>>> >????? > passed release build JTREG
>>> ???? >>>>>>>>>>>> for hotspot/jtreg/compiler/jvmti (just
>>> ???? >>>>>>>>>>>> > to run
>>> ???? >>>>>>>>>>>> >????? > something as a smoke screen)
>>> ???? >>>>>>>>>>>> and hotspot/jtreg/compiler/aot/ (to
>>> ???? >>>>>>>>>>>> > test
>>> ???? >>>>>>>>>>>> >????? > Graal).
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.02/
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> > I think this looks better, I agree that leaving
>>> _end is
>>> ???? >>>>>>>>>>>> tempting to
>>> ???? >>>>>>>>>>>> > avoid a lot of change, but I think this will be
>>> better
>>> ???? >>>>>>> in
>>> ???? >>>>>>>>> the
>>> ???? >>>>>>>>>>>> long run.
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>> > I still miss the changes to make the SA work. To
>>> see a
>>> ???? >>>>>>>>>>>> problem you
>>> ???? >>>>>>>>>>>> > can run:
>>> ???? >>>>>>>>>>>> > make CONF=fast run-test
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>
>>> TEST=open/test/hotspot/jtreg/serviceability/ClhsdbJhisto.java
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>> > Cheers,
>>> ???? >>>>>>>>>>>> > Stefan
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>> >????? > Let me know what you think,
>>> ???? >>>>>>>>>>>> >????? > Jc
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >????? > On Tue, Apr 10, 2018 at 3:21 PM JC Beyler
>>> ???? >>>>>>>>>>>> <jcbeyler at google.com <mailto:jcbeyler at google.com>
>>> ??? <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>
>>> ???? >>>>>>>>>>>> > <mailto:jcbeyler at google.com
>>> <mailto:jcbeyler at google.com>
>>> ??? <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>
>>> ???? >>>>>>>>>
>>> ???? >>>>>>>>>>>> >????? > <mailto:jcbeyler at google.com
>>> <mailto:jcbeyler at google.com> <mailto:
>>> ???? >>>>>>> jcbeyler at google.com <mailto:jcbeyler at google.com>
>>> ???? >>>>>>>>>>
>>> ???? >>>>>>>>>>>> <mailto:jcbeyler at google.com
>>> <mailto:jcbeyler at google.com>
>>> ??? <mailto:jcbeyler at google.com <mailto:jcbeyler at google.com>>>>>
>>> ???? >>>>>>>>> wrote:
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >????? >???? Hi Karen and Stefan,
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >????? >???? @Stefan: Naming is hard :)
>>> ???? >>>>>>>>>>>> >????? >???? @Karen: thanks for the Graal comment,
>>> I fixed it
>>> ???? >>>>>>> in
>>> ???? >>>>>>>>>>>> the new
>>> ???? >>>>>>>>>>>> > webrev,
>>> ???? >>>>>>>>>>>> >????? >???? let me know what you think :)
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >????? >???? I think the naming convention
>>> suggested in this
>>> ???? >>>>>>>>> webrev
>>> ???? >>>>>>>>>>>> came from
>>> ???? >>>>>>>>>>>> >????? >???? conversations in for JEP-331 and I am
>>> actually
>>> ???? >>>>>>>>>>> relatively
>>> ???? >>>>>>>>>>>> >????? > indifferent to the final result (as long
>>> as we
>>> ???? >>>>>>> have
>>> ???? >>>>>>>>>>>> some form of
>>> ???? >>>>>>>>>>>> >????? >???? forward progress :)). To be honest,
>>> I'd also be
>>> ???? >>>>>>>>> happy
>>> ???? >>>>>>>>>>>> to just
>>> ???? >>>>>>>>>>>> > leave
>>> ???? >>>>>>>>>>>> >????? >???? _end as is for all architectures and
>>> Graal and
>>> ???? >>>>>>> have
>>> ???? >>>>>>>>> a
>>> ???? >>>>>>>>>>> new
>>> ???? >>>>>>>>>>>> >????? > _allocation_end. However, during initial
>>> reviews
>>> ???? >>>>>>> of
>>> ???? >>>>>>>>>>>> JEP-331
>>> ???? >>>>>>>>>>>> > it was
>>> ???? >>>>>>>>>>>> >????? >???? deemed complicated to understand:
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >????? >???? _end -> the _end or sampling end
>>> ???? >>>>>>>>>>>> >????? >???? _allocation_end -> end pointer for
>>> the last
>>> ???? >>>>>>> possible
>>> ???? >>>>>>>>>>>> allocation
>>> ???? >>>>>>>>>>>> >????? >???? hard_end -> allocation end + reserved
>>> space
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >????? >???? That is how this naming came up and
>>> why hard_end
>>> ???? >>>>>>>>> went
>>> ???? >>>>>>>>>>> to
>>> ???? >>>>>>>>>>>> > "reserved_end".
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >????? >???? I'm really indifferent, so I offer as
>>> a perusal:
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.01/
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >????? >???? I noticed a few problems of
>>> alignement of '{' so
>>> ???? >>>>>>>>> I'll
>>> ???? >>>>>>>>>>>> go fix
>>> ???? >>>>>>>>>>>> > that.
>>> ???? >>>>>>>>>>>> >????? >???? Basically this webrev does the
>>> following:
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >????? >???? - Uses fast_path_end instead of end
>>> ???? >>>>>>>>>>>> >????? >???? - Reverts hard_end back to where it was
>>> ???? >>>>>>>>>>>> >????? >???? - Adds the changes to Graal; there is
>>> a bunch of
>>> ???? >>>>>>>>>>>> changes in Graal
>>> ???? >>>>>>>>>>>> >????? >???? because Graal still contains a bit of
>>> code doing
>>> ???? >>>>>>>>>>>> fasttlabrefills.
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >????? >???? Let me know what you think!
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >????? >???? Thanks,
>>> ???? >>>>>>>>>>>> >????? >???? Jc
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >????? >???? On Tue, Apr 10, 2018 at 6:56 AM Karen
>>> Kinnear
>>> ???? >>>>>>>>>>>> >????? > <karen.kinnear at oracle.com
>>> <mailto:karen.kinnear at oracle.com>
>>> ???? >>>>>>>>>>>> <mailto:karen.kinnear at oracle.com
>>> <mailto:karen.kinnear at oracle.com>> <mailto:
>>> ???? >>>>>>>>> karen.kinnear at oracle.com
>>> <mailto:karen.kinnear at oracle.com>
>>> ???? >>>>>>>>>>>> <mailto:karen.kinnear at oracle.com
>>> <mailto:karen.kinnear at oracle.com>>>
>>> ???? >>>>>>>>>>>> > <mailto:karen.kinnear at oracle.com
>>> <mailto:karen.kinnear at oracle.com>
>>> ???? >>>>>>>>>>>> <mailto:karen.kinnear at oracle.com
>>> <mailto:karen.kinnear at oracle.com>> <mailto:
>>> ???? >>>>>>>>> karen.kinnear at oracle.com
>>> <mailto:karen.kinnear at oracle.com>
>>> ???? >>>>>>>>>>>> <mailto:karen.kinnear at oracle.com
>>> <mailto:karen.kinnear at oracle.com>>>>>
>>> ???? >>>>>>>>>>>> > wrote:
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >????? >???????? Hi JC,
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >????? >???????? A comment about Graal. The impact
>>> on Graal
>>> ???? >>>>>>> for
>>> ???? >>>>>>>>> this
>>> ???? >>>>>>>>>>>> > particular
>>> ???? >>>>>>>>>>>> >????? >???????? change would be to break it - so
>>> you?ll need
>>> ???? >>>>>>>>>>>> >????? >???????? to complete the Graal changes for
>>> this
>>> ???? >>>>>>> renaming.
>>> ???? >>>>>>>>>>>> That isn?t
>>> ???? >>>>>>>>>>>> >????? >???????? optional or something that could
>>> be a
>>> ???? >>>>>>>>> follow-on. It
>>> ???? >>>>>>>>>>>> > >???????? is not ok to break a feature, even an
>>> ???? >>>>>>>>> experimental
>>> ???? >>>>>>>>>>>> one.
>>> ???? >>>>>>>>>>>> > We will
>>> ???? >>>>>>>>>>>> >????? >???????? discuss in the other thread
>>> potential
>>> ???? >>>>>>> phasing of
>>> ???? >>>>>>>>>>>> adding
>>> ???? >>>>>>>>>>>> > sampling.
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >????? >???????? I did not do a thorough search
>>> -you can do
>>> ???? >>>>>>> that
>>> ???? >>>>>>>>> -
>>> ???? >>>>>>>>>>>> ?????? I did find
>>> ???? >>>>>>>>>>>> >????? > src/jdk.internal.vm.compiler/share/classes/
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>
>>> ???? >>>>>>>>>
>>> ???? >>>>>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> ???? >>>>>>>>>>>> > >??????????? public final int threadTlabOffset =
>>> ???? >>>>>>>>>>>> >????? > getFieldOffset("Thread::_tlab",
>>> ???? >>>>>>> Integer.class,
>>> ???? >>>>>>>>>>>> > >???????? "ThreadLocalAllocBuffer");
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>
>>> ???? >>>>>>>>>
>>> ???? >>>>>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> ???? >>>>>>>>>>>> > >??????????? private final int
>>> ???? >>>>>>>>>>>> threadLocalAllocBufferStartOffset =
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_start",
>>> ???? >>>>>>>>>>>> > Integer.class,
>>> ???? >>>>>>>>>>>> >????? >???????? "HeapWord*");
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>
>>> ???? >>>>>>>>>
>>> ???? >>>>>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> ???? >>>>>>>>>>>> > >??????????? private final int
>>> ???? >>>>>>>>>>> threadLocalAllocBufferEndOffset =
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_end",
>>> ???? >>>>>>>>>>>> Integer.class,
>>> ???? >>>>>>>>>>>> >????? >???????? "HeapWord*");
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>
>>> ???? >>>>>>>>>
>>> ???? >>>>>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> ???? >>>>>>>>>>>> > >??????????? private final int
>>> ???? >>>>>>>>>>> threadLocalAllocBufferTopOffset =
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_top",
>>> ???? >>>>>>>>>>>> Integer.class,
>>> ???? >>>>>>>>>>>> >????? >???????? "HeapWord*");
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>
>>> ???? >>>>>>>>>
>>> ???? >>>>>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> ???? >>>>>>>>>>>> > >??????????? private final int
>>> ???? >>>>>>>>>>>> threadLocalAllocBufferPfTopOffset =
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>> getFieldOffset("ThreadLocalAllocBuffer::_pf_top",
>>> ???? >>>>>>>>>>>> > Integer.class,
>>> ???? >>>>>>>>>>>> >????? >???????? "HeapWord*");
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>
>>> ???? >>>>>>>>>
>>> ???? >>>>>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> ???? >>>>>>>>>>>> > >??????????? private final int
>>> ???? >>>>>>>>>>>> > threadLocalAllocBufferSlowAllocationsOffset
>>> ???? >>>>>>>>>>>> >????? >???????? =
>>> ???? >>>>>>>>>>>>
>>> getFieldOffset("ThreadLocalAllocBuffer::_slow_allocations",
>>> ???? >>>>>>>>>>>> >????? >???????? Integer.class, "unsigned");
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>
>>> ???? >>>>>>>>>
>>> ???? >>>>>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> ???? >>>>>>>>>>>> > >??????????? private final int
>>> ???? >>>>>>>>>>>> > threadLocalAllocBufferFastRefillWasteOffset
>>> ???? >>>>>>>>>>>> >????? >???????? =
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>
>>> getFieldOffset("ThreadLocalAllocBuffer::_fast_refill_waste",
>>> ???? >>>>>>>>>>>> > >???????? Integer.class, "unsigned");
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>
>>> ???? >>>>>>>>>
>>> ???? >>>>>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> ???? >>>>>>>>>>>> > >??????????? private final int
>>> ???? >>>>>>>>>>>> > threadLocalAllocBufferNumberOfRefillsOffset
>>> ???? >>>>>>>>>>>> >????? >???????? =
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>
>>> getFieldOffset("ThreadLocalAllocBuffer::_number_of_refills",
>>> ???? >>>>>>>>>>>> > >???????? Integer.class, "unsigned");
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>
>>> ???? >>>>>>>>>
>>> ???? >>>>>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> ???? >>>>>>>>>>>> > >??????????? private final int
>>> ???? >>>>>>>>>>>> >????? > threadLocalAllocBufferRefillWasteLimitOffset
>>> ???? >>>>>>> =
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>>
>>> getFieldOffset("ThreadLocalAllocBuffer::_refill_waste_limit",
>>> ???? >>>>>>>>>>>> >????? >???????? Integer.class, "size_t");
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>
>>> ???? >>>>>>>>>
>>> ???? >>>>>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> ???? >>>>>>>>>>>> > >??????????? private final int
>>> ???? >>>>>>>>>>>> > threadLocalAllocBufferDesiredSizeOffset =
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>>
>>> getFieldOffset("ThreadLocalAllocBuffer::_desired_size",
>>> ???? >>>>>>>>>>>> >????? >???????? Integer.class, "size_t");
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>
>>> ???? >>>>>>>>>
>>> ???? >>>>>>>
>>> org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java:
>>> ???? >>>>>>>>>>>> > >??????????? public final int
>>> tlabAlignmentReserve =
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>
>>> ???? >>>>>>>>>
>>> ???? >>>>>>>
>>> getFieldValue("CompilerToVM::Data::ThreadLocalAllocBuffer_alignment_reserve",
>>> ???? >>>>>>>>>>>> > >???????? Integer.class, "size_t?);
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >????? >???????? hope this helps,
>>> ???? >>>>>>>>>>>> >????? >???????? Karen
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >????? >>???????? On Apr 10, 2018, at 7:04 AM, Stefan
>>> ???? >>>>>>> Johansson
>>> ???? >>>>>>>>>>>> > >> <stefan.johansson at oracle.com
>>> <mailto:stefan.johansson at oracle.com>
>>> ???? >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com
>>> <mailto:stefan.johansson at oracle.com>>
>>> ???? >>>>>>>>>>>> > <mailto:stefan.johansson at oracle.com
>>> <mailto:stefan.johansson at oracle.com>
>>> ???? >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com
>>> <mailto:stefan.johansson at oracle.com>>>
>>> ???? >>>>>>>>>>>> >????? >> <mailto:stefan.johansson at oracle.com
>>> ??? <mailto:stefan.johansson at oracle.com>
>>> ???? >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com
>>> <mailto:stefan.johansson at oracle.com>>
>>> ???? >>>>>>>>>>>> > <mailto:stefan.johansson at oracle.com
>>> <mailto:stefan.johansson at oracle.com>
>>> ???? >>>>>>>>>>>> <mailto:stefan.johansson at oracle.com
>>> <mailto:stefan.johansson at oracle.com>>>>> wrote:
>>> ???? >>>>>>>>>>>> >????? >>
>>> ???? >>>>>>>>>>>> >????? >>???????? Hi JC,
>>> ???? >>>>>>>>>>>> >????? >>
>>> ???? >>>>>>>>>>>> >????? >>???????? I realize that the names have
>>> been discussed
>>> ???? >>>>>>>>>>>> before but I'm
>>> ???? >>>>>>>>>>>> >????? >>???????? leaning towards suggesting
>>> something new. We
>>> ???? >>>>>>>>>>>> discussed this
>>> ???? >>>>>>>>>>>> >????? >>???????? briefly here in the office and
>>> others might
>>> ???? >>>>>>>>> have
>>> ???? >>>>>>>>>>>> different
>>> ???? >>>>>>>>>>>> >????? >>???????? opinions. One point that came up
>>> is that if
>>> ???? >>>>>>> we
>>> ???? >>>>>>>>> do
>>> ???? >>>>>>>>>>>> this
>>> ???? >>>>>>>>>>>> > change
>>> ???? >>>>>>>>>>>> >????? >>???????? and change all usages of
>>> ???? >>>>>>>>>>>> JavaThread::tlab_end_offset() it
>>> ???? >>>>>>>>>>>> >????? >>???????? would be good to make sure the
>>> new name is
>>> ???? >>>>>>>>> good.
>>> ???? >>>>>>>>>>>> To us
>>> ???? >>>>>>>>>>>> >????? >> _current_end is not very descriptive, but
>>> ???? >>>>>>>>> naming
>>> ???? >>>>>>>>>>>> is hard and
>>> ???? >>>>>>>>>>>> >????? >>???????? the best we could come up with is
>>> ???? >>>>>>>>> _fast_path_end
>>> ???? >>>>>>>>>>>> which would
>>> ???? >>>>>>>>>>>> >????? >>???????? give the code:
>>> ???? >>>>>>>>>>>> >????? >> cmpptr(end, Address(thread,
>>> ???? >>>>>>>>>>>> >????? >> JavaThread::tlab_fast_path_end_offset()));
>>> ???? >>>>>>>>>>>> >????? >> jcc(Assembler::above, slow_case);
>>> ???? >>>>>>>>>>>> >????? >>
>>> ???? >>>>>>>>>>>> >????? >>???????? I think this reads pretty good
>>> and is fairly
>>> ???? >>>>>>>>>>>> clear. If we do
>>> ???? >>>>>>>>>>>> >????? >>???????? this rename I think you can
>>> re-use _end in
>>> ???? >>>>>>>>> JEP-331
>>> ???? >>>>>>>>>>>> > instead of
>>> ???? >>>>>>>>>>>> >????? >>???????? calling it _allocation_end. But
>>> that is a
>>> ???? >>>>>>> later
>>> ???? >>>>>>>>>>>> review :)
>>> ???? >>>>>>>>>>>> >????? >>
>>> ???? >>>>>>>>>>>> >????? >>???????? Also, is there a good reason for
>>> renaming
>>> ???? >>>>>>>>>>>> hard_end() to
>>> ???? >>>>>>>>>>>> >????? >> reserved_end()?
>>> ???? >>>>>>>>>>>> >????? >>
>>> ???? >>>>>>>>>>>> >????? >>???????? One additional thing, you need
>>> to update
>>> ???? >>>>>>> the SA
>>> ???? >>>>>>>>>>>> to reflect
>>> ???? >>>>>>>>>>>> >????? >>???????? this change. I think the only
>>> place you
>>> ???? >>>>>>> need to
>>> ???? >>>>>>>>>>>> fix is in:
>>> ???? >>>>>>>>>>>> >????? >>
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>>>
>>> ???? >>>>>>>>>
>>> ???? >>>>>>>
>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
>>> ???? >>>>>>>>>>>> > >>
>>> ???? >>>>>>>>>>>> >????? >>???????? Thanks,
>>> ???? >>>>>>>>>>>> >????? >>???????? Stefan
>>> ???? >>>>>>>>>>>> >????? >>
>>> ???? >>>>>>>>>>>> >????? >>???????? On 2018-04-09 19:24, JC Beyler
>>> wrote:
>>> ???? >>>>>>>>>>>> >????? >>>???????? Hi all,
>>> ???? >>>>>>>>>>>> >????? >>>???????? Small pre-amble to this request:
>>> ???? >>>>>>>>>>>> >????? >>>???????? In my work to try to get a heap
>>> sampler in
>>> ???? >>>>>>>>>>>> OpenJDK (via JEP
>>> ???? >>>>>>>>>>>> >????? >>>???????? 331
>>> ???? >>>>>>>>>>>> >
>>> <https://bugs.openjdk.java.net/browse/JDK-8171119>),
>>> ???? >>>>>>> I'm
>>> ???? >>>>>>>>>>>> > >>>???????? trying to reduce the footprint of my
>>> ???? >>>>>>> change so
>>> ???? >>>>>>>>>>>> that the
>>> ???? >>>>>>>>>>>> >????? >>> integration can be easier. I was told that
>>> ???? >>>>>>>>>>>> generally a JEP
>>> ???? >>>>>>>>>>>> >????? >>>???????? webrev should be feature
>>> complete and go in
>>> ???? >>>>>>>>>>> at-once.
>>> ???? >>>>>>>>>>>> > However,
>>> ???? >>>>>>>>>>>> >????? >>>???????? with the change touching quite
>>> a bit of
>>> ???? >>>>>>>>> various
>>> ???? >>>>>>>>>>> code
>>> ???? >>>>>>>>>>>> > pieces,
>>> ???? >>>>>>>>>>>> >????? >>>???????? I was trying to figure out what
>>> could be
>>> ???? >>>>>>>>>>>> separated as not
>>> ???? >>>>>>>>>>>> >????? >>>???????? "part of the feature".
>>> ???? >>>>>>>>>>>> >????? >>>???????? I asked around and said that
>>> perhaps a
>>> ???? >>>>>>>>> solution
>>> ???? >>>>>>>>>>>> would be to
>>> ???? >>>>>>>>>>>> >????? >>>???????? cut up the renaming of TLAB's
>>> end field
>>> ???? >>>>>>> that I
>>> ???? >>>>>>>>>>>> do in that
>>> ???? >>>>>>>>>>>> >????? >>>???????? webrev. Because I'm renaming a
>>> field in
>>> ???? >>>>>>> TLAB
>>> ???? >>>>>>>>>>> used by
>>> ???? >>>>>>>>>>>> > various
>>> ???? >>>>>>>>>>>> >????? >>> backends for that work, I have to update
>>> ???? >>>>>>> every
>>> ???? >>>>>>>>>>>> architecture
>>> ???? >>>>>>>>>>>> >????? >>> dependent code to reflect it.
>>> ???? >>>>>>>>>>>> >????? >>>???????? I entirely understand that
>>> perhaps this is
>>> ???? >>>>>>> not
>>> ???? >>>>>>>>>>>> in the
>>> ???? >>>>>>>>>>>> > habits
>>> ???? >>>>>>>>>>>> >????? >>>???????? and very potentially might not
>>> be the way
>>> ???? >>>>>>>>> things
>>> ???? >>>>>>>>>>> are
>>> ???? >>>>>>>>>>>> > >>>???????? generally done. If so, I apologize
>>> and let
>>> ???? >>>>>>> me
>>> ???? >>>>>>>>>>>> know if you
>>> ???? >>>>>>>>>>>> >????? >>>???????? would not want this to go in
>>> separately :)
>>> ???? >>>>>>>>>>>> >????? >>>???????? Final note: there is still a
>>> chance JEP-331
>>> ???? >>>>>>>>> does
>>> ???? >>>>>>>>>>>> not go in.
>>> ???? >>>>>>>>>>>> >????? >>>???????? If it does not, we can leave
>>> the new name
>>> ???? >>>>>>> in
>>> ???? >>>>>>>>>>>> place or I'll
>>> ???? >>>>>>>>>>>> >????? >>>???????? happily revert it. I can even
>>> create an
>>> ???? >>>>>>> issue
>>> ???? >>>>>>>>> to
>>> ???? >>>>>>>>>>>> track this
>>> ???? >>>>>>>>>>>> >????? >>>???????? if that makes it easier for all.
>>> ???? >>>>>>>>>>>> >????? >>>???????? End of the pre-amble.
>>> ???? >>>>>>>>>>>> >????? >>>???????? The 33-line change webrev in
>>> question is
>>> ???? >>>>>>> here:
>>> ???? >>>>>>>>>>>> > >>>
>>> ???? >>>>>>>>> http://cr.openjdk.java.net/~jcbeyler/8201326/webrev.00/
>>> ???? >>>>>>>>>>>> > >>>???????? I fixed all the architectures and
>>> JVMCI and
>>> ???? >>>>>>>>> ran
>>> ???? >>>>>>>>>>>> ?????? a few
>>> ???? >>>>>>>>>>>> > sanity
>>> ???? >>>>>>>>>>>> >????? >>>???????? tests to ensure I had not
>>> missed anything.
>>> ???? >>>>>>>>>>>> >????? >>>???????? Thanks for your help and I hope
>>> this is not
>>> ???? >>>>>>>>> too
>>> ???? >>>>>>>>>>> much
>>> ???? >>>>>>>>>>>> > trouble,
>>> ???? >>>>>>>>>>>> >????? >>>???????? Jc
>>> ???? >>>>>>>>>>>> >????? >>>???????? Ps: there is a graal change
>>> that needs to
>>> ???? >>>>>>>>> happen
>>> ???? >>>>>>>>>>>> but I was
>>> ???? >>>>>>>>>>>> >????? >>>???????? not sure who/where
>>> <https://teams.googleplex.com/u/where>
>>> ???? >>>>>>> <https://teams.googleplex.com/u/where>
>>> ???? >>>>>>>>> <https://teams.googleplex.com/u/where>
>>> ???? >>>>>>>>>>> <https://teams.googleplex.com/u/where>
>>> ???? >>>>>>>>>>>> <https://teams.googleplex.com/u/where>
>>> ???? >>>>>>>>>>>> > <https://teams.googleplex.com/u/where>
>>> ???? >>>>>>>>>>>> > <https://teams.googleplex.com/u/where> to
>>> ???? >>>>>>>>>>>> >????? >>>???????? ask about it. I was told it
>>> could happen
>>> ???? >>>>>>> in a
>>> ???? >>>>>>>>>>>> separate
>>> ???? >>>>>>>>>>>> >????? >>>???????? webrev. Can anyone point me to
>>> the right
>>> ???? >>>>>>>>>>> direction?
>>> ???? >>>>>>>>>>>> > Should it
>>> ???? >>>>>>>>>>>> >????? >>>???????? just be hotspot-compiler-dev?
>>> ???? >>>>>>>>>>>> >????? >
>>> ???? >>>>>>>>>>>> >
>>> ???? >>>>>>>>>>>>
>>> ???? >>>>>>>>>
>>> ???? >>>>>>>>>
>>> ???? >>>>>>>
>>> ???? >>>
>>> ???? >
>>>
>
From kim.barrett at oracle.com Wed Apr 18 23:55:59 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 18 Apr 2018 19:55:59 -0400
Subject: RFR: 8200235: Generalize jniFastGetField jobject/jweak resolve
In-Reply-To: <5AD728A8.9050606@oracle.com>
References: <5AD728A8.9050606@oracle.com>
Message-ID: <004C7D30-C23B-47FB-BC0D-C030A0F85AFD@oracle.com>
> On Apr 18, 2018, at 7:14 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>
> Hi,
>
> The fantastic jniFastGetField optimization that we all know and love, resolves jobjects/jweaks in native, possibly concurrent with GC safepoints.
> Currently it is assumed that it is "safe" to just unmask the potential jweak tag, and read the jobject/jweak oop and then speculatively read the integer value of that oop (resorting to the signal handler as plan B if the heap was concurrently unmapped in the safepoint).
>
> This happens to be safe with existing collectors, but ties very strongly to how these oops are processed (as it is normally strictly forbidden by mutators to resolve jobject/jweak in safepoints, except of course when using it to quickly read integers via JNI).
>
> My proposed solution is to add a try_resolve_jobject_in_native() function in the BarrierSetAssembler class, and allow it try to perform this resolution, but also give it an option to opt out should it find that this jobject/jweak really has to go through the proper VM transition. This allows a GC where this is not in general safe (but possibly mostly safe depending on GC-specific details such as pointer colouring) to override this special in-native jobject/jweak resolution. That should make everyone happy I hope.
>
> I provided changes for x86_64, SPARC and AArch64. PPC and S390 do not use jniFastGetField, and there are no current plans that I am aware of to introduce support for any new GC any time soon to the non-AArch64 arm port.
>
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8200235/webrev.00/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8200235
>
> Thanks,
> /Erik
Looks good.
From dean.long at oracle.com Thu Apr 19 05:20:58 2018
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Wed, 18 Apr 2018 22:20:58 -0700
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <19F3CB79-99F3-4288-AAB4-7E54D8828837@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<f1c9b155-7f06-262c-98f6-f0d3d3b025b6@redhat.com>
<d583942c-7151-d783-14cd-658b6295203a@oracle.com>
<cf5e6638-443e-1243-96f8-599d8950c1af@redhat.com>
<F3231CFC-7B66-4BB1-B911-95AD3B2C0A83@oracle.com>
<4616d0a8-61b0-a369-61cc-e4c82c39539e@redhat.com>
<19F3CB79-99F3-4288-AAB4-7E54D8828837@oracle.com>
Message-ID: <c2604b75-10ea-ceec-b381-fc11b3eb3f0a@oracle.com>
I don't see a PR to get this upstream to Graal.? Is someone working on
it?? If not I can do it.
dl
On 4/15/18 2:27 PM, Doug Simon wrote:
>
>> On 15 Apr 2018, at 12:03, Andrew Haley <aph at redhat.com> wrote:
>>
>> On 04/14/2018 01:29 PM, Doug Simon wrote:
>>>> In the meantime, be aware that Graal development on JDK11 is broken
>>>> until this change is pushed to Graal. As far as I know, Graal changes
>>>> are supposed to be reviewed by Graal developers.
>>> Changes like this one can be reviewed by anyone in the HotSpot
>>> compiler team or Graal team.
>> That's good to know. The change is obviously correct, but it needs to
>> be handled correctly.
> Right. The GitHub Graal code base needs to work from JDK 8 (with a JVMCI patch) onwards. We have just recently switched to using multi-release jars to make this process saner and avoid the use of reflection to access version dependent API. When GitHub Graal snapshots are taken for syncing the code into OpenJDK, the versioned directories are flattened to the non-versioned root directory following the same logic that would be applied when resolving a versioned class at runtime. The flattenmultireleasesources command[1] was added to mx to facilitate this flattening.
>
> The particular change in this webrev is a good opportunity to make GraalHotSpotVMConfig versioned in this way. I'll make the necessary changes for this in GitHub Graal. Normally, no manual change should be made to OpenJDK Graal but in this case I think it's necessary so that OpenJDK testing of Graal won't break.
>
>> For my information, though, I presume "changes like this" means simple
>> changes to JVMCI. That right?
> Sorry for my ambiguity. I meant that this is a simple change to both JVMCI and Graal and by now most HotSpot compiler developers should be able to review it. Of course, having a Graal developer look at it as well is recommended. The preferred way to do this is to open a PR at https://github.com/graalvm/mx/pulls.
>
> -Doug
>
> [1] https://github.com/graalvm/mx/commit/bad56c1101db758c3f8c6560fc62012c15be39e4
>
>> --
>> Andrew Haley
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=4ZggofCo53X0nV2fk4nYuyBqw3xG4MZTeRDFqVH-pnI&s=4mmTmtLnlPEwCZErTwYIz3N2z1cw2_X5GqZs0GCBYA8&e=>
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From erik.osterlund at oracle.com Thu Apr 19 05:44:05 2018
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Thu, 19 Apr 2018 07:44:05 +0200
Subject: RFR: 8200235: Generalize jniFastGetField jobject/jweak resolve
In-Reply-To: <004C7D30-C23B-47FB-BC0D-C030A0F85AFD@oracle.com>
References: <5AD728A8.9050606@oracle.com>
<004C7D30-C23B-47FB-BC0D-C030A0F85AFD@oracle.com>
Message-ID: <4F69BD83-A16F-4D2F-B9EC-9A2DB83B45FA@oracle.com>
Hi Kim,
Thanks for the review.
/Erik
On 19 Apr 2018, at 01:55, Kim Barrett <kim.barrett at oracle.com> wrote:
>> On Apr 18, 2018, at 7:14 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>>
>> Hi,
>>
>> The fantastic jniFastGetField optimization that we all know and love, resolves jobjects/jweaks in native, possibly concurrent with GC safepoints.
>> Currently it is assumed that it is "safe" to just unmask the potential jweak tag, and read the jobject/jweak oop and then speculatively read the integer value of that oop (resorting to the signal handler as plan B if the heap was concurrently unmapped in the safepoint).
>>
>> This happens to be safe with existing collectors, but ties very strongly to how these oops are processed (as it is normally strictly forbidden by mutators to resolve jobject/jweak in safepoints, except of course when using it to quickly read integers via JNI).
>>
>> My proposed solution is to add a try_resolve_jobject_in_native() function in the BarrierSetAssembler class, and allow it try to perform this resolution, but also give it an option to opt out should it find that this jobject/jweak really has to go through the proper VM transition. This allows a GC where this is not in general safe (but possibly mostly safe depending on GC-specific details such as pointer colouring) to override this special in-native jobject/jweak resolution. That should make everyone happy I hope.
>>
>> I provided changes for x86_64, SPARC and AArch64. PPC and S390 do not use jniFastGetField, and there are no current plans that I am aware of to introduce support for any new GC any time soon to the non-AArch64 arm port.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8200235/webrev.00/
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8200235
>>
>> Thanks,
>> /Erik
>
> Looks good.
>
From per.liden at oracle.com Thu Apr 19 06:34:42 2018
From: per.liden at oracle.com (Per Liden)
Date: Thu, 19 Apr 2018 08:34:42 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <c2604b75-10ea-ceec-b381-fc11b3eb3f0a@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<f1c9b155-7f06-262c-98f6-f0d3d3b025b6@redhat.com>
<d583942c-7151-d783-14cd-658b6295203a@oracle.com>
<cf5e6638-443e-1243-96f8-599d8950c1af@redhat.com>
<F3231CFC-7B66-4BB1-B911-95AD3B2C0A83@oracle.com>
<4616d0a8-61b0-a369-61cc-e4c82c39539e@redhat.com>
<19F3CB79-99F3-4288-AAB4-7E54D8828837@oracle.com>
<c2604b75-10ea-ceec-b381-fc11b3eb3f0a@oracle.com>
Message-ID: <37884cc1-38d9-945d-b552-36d213677efc@oracle.com>
Hi Dean,
Sorry for the delay. There was some confusion around how to deal with
this, but that has now been sorted out. I just sent the Graal upstream
request to hotspot-compiler-dev. Feel free to pick it up.
cheers,
Per
On 04/19/2018 07:20 AM, dean.long at oracle.com wrote:
> I don't see a PR to get this upstream to Graal.? Is someone working on
> it?? If not I can do it.
>
> dl
>
> On 4/15/18 2:27 PM, Doug Simon wrote:
>>
>>> On 15 Apr 2018, at 12:03, Andrew Haley <aph at redhat.com> wrote:
>>>
>>> On 04/14/2018 01:29 PM, Doug Simon wrote:
>>>>> In the meantime, be aware that Graal development on JDK11 is broken
>>>>> until this change is pushed to Graal.? As far as I know, Graal changes
>>>>> are supposed to be reviewed by Graal developers.
>>>> Changes like this one can be reviewed by anyone in the HotSpot
>>>> compiler team or Graal team.
>>> That's good to know.? The change is obviously correct, but it needs to
>>> be handled correctly.
>> Right. The GitHub Graal code base needs to work from JDK 8 (with a
>> JVMCI patch) onwards. We have just recently switched to using
>> multi-release jars to make this process saner and avoid the use of
>> reflection to access version dependent API. When GitHub Graal
>> snapshots are taken for syncing the code into OpenJDK, the versioned
>> directories are flattened to the non-versioned root directory
>> following the same logic that would be applied when resolving a
>> versioned class at runtime. The flattenmultireleasesources command[1]
>> was added to mx to facilitate this flattening.
>>
>> The particular change in this webrev is a good opportunity to make
>> GraalHotSpotVMConfig versioned in this way. I'll make the necessary
>> changes for this in GitHub Graal. Normally, no manual change should be
>> made to OpenJDK Graal but in this case I think it's necessary so that
>> OpenJDK testing of Graal won't break.
>>
>>> For my information, though, I presume "changes like this" means simple
>>> changes to JVMCI.? That right?
>> Sorry for my ambiguity. I meant that this is a simple change to both
>> JVMCI and Graal and by now most HotSpot compiler developers should be
>> able to review it. Of course, having a Graal developer look at it as
>> well is recommended. The preferred way to do this is to open a PR at
>> https://github.com/graalvm/mx/pulls.
>>
>> -Doug
>>
>> [1]
>> https://github.com/graalvm/mx/commit/bad56c1101db758c3f8c6560fc62012c15be39e4
>>
>>
>>> --
>>> Andrew Haley
>>> Java Platform Lead Engineer
>>> Red Hat UK Ltd.
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=4ZggofCo53X0nV2fk4nYuyBqw3xG4MZTeRDFqVH-pnI&s=4mmTmtLnlPEwCZErTwYIz3N2z1cw2_X5GqZs0GCBYA8&e=>
>>>
>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
From dean.long at oracle.com Thu Apr 19 06:41:45 2018
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Wed, 18 Apr 2018 23:41:45 -0700
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <37884cc1-38d9-945d-b552-36d213677efc@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<f1c9b155-7f06-262c-98f6-f0d3d3b025b6@redhat.com>
<d583942c-7151-d783-14cd-658b6295203a@oracle.com>
<cf5e6638-443e-1243-96f8-599d8950c1af@redhat.com>
<F3231CFC-7B66-4BB1-B911-95AD3B2C0A83@oracle.com>
<4616d0a8-61b0-a369-61cc-e4c82c39539e@redhat.com>
<19F3CB79-99F3-4288-AAB4-7E54D8828837@oracle.com>
<c2604b75-10ea-ceec-b381-fc11b3eb3f0a@oracle.com>
<37884cc1-38d9-945d-b552-36d213677efc@oracle.com>
Message-ID: <a35ee91b-7fce-7deb-cf32-d3895526b3e2@oracle.com>
Oh, was there a discussion I missed where it was sorted out?? I was
expecting a PR at https://github.com/graalvm/mx/pulls, not upstream
request sent to hotspot-compiler-dev.
dl
On 4/18/18 11:34 PM, Per Liden wrote:
> Hi Dean,
>
> Sorry for the delay. There was some confusion around how to deal with
> this, but that has now been sorted out. I just sent the Graal upstream
> request to hotspot-compiler-dev. Feel free to pick it up.
>
> cheers,
> Per
>
> On 04/19/2018 07:20 AM, dean.long at oracle.com wrote:
>> I don't see a PR to get this upstream to Graal.? Is someone working
>> on it?? If not I can do it.
>>
>> dl
>>
>> On 4/15/18 2:27 PM, Doug Simon wrote:
>>>
>>>> On 15 Apr 2018, at 12:03, Andrew Haley <aph at redhat.com> wrote:
>>>>
>>>> On 04/14/2018 01:29 PM, Doug Simon wrote:
>>>>>> In the meantime, be aware that Graal development on JDK11 is broken
>>>>>> until this change is pushed to Graal.? As far as I know, Graal
>>>>>> changes
>>>>>> are supposed to be reviewed by Graal developers.
>>>>> Changes like this one can be reviewed by anyone in the HotSpot
>>>>> compiler team or Graal team.
>>>> That's good to know.? The change is obviously correct, but it needs to
>>>> be handled correctly.
>>> Right. The GitHub Graal code base needs to work from JDK 8 (with a
>>> JVMCI patch) onwards. We have just recently switched to using
>>> multi-release jars to make this process saner and avoid the use of
>>> reflection to access version dependent API. When GitHub Graal
>>> snapshots are taken for syncing the code into OpenJDK, the versioned
>>> directories are flattened to the non-versioned root directory
>>> following the same logic that would be applied when resolving a
>>> versioned class at runtime. The flattenmultireleasesources
>>> command[1] was added to mx to facilitate this flattening.
>>>
>>> The particular change in this webrev is a good opportunity to make
>>> GraalHotSpotVMConfig versioned in this way. I'll make the necessary
>>> changes for this in GitHub Graal. Normally, no manual change should
>>> be made to OpenJDK Graal but in this case I think it's necessary so
>>> that OpenJDK testing of Graal won't break.
>>>
>>>> For my information, though, I presume "changes like this" means simple
>>>> changes to JVMCI.? That right?
>>> Sorry for my ambiguity. I meant that this is a simple change to both
>>> JVMCI and Graal and by now most HotSpot compiler developers should
>>> be able to review it. Of course, having a Graal developer look at it
>>> as well is recommended. The preferred way to do this is to open a PR
>>> at https://github.com/graalvm/mx/pulls.
>>>
>>> -Doug
>>>
>>> [1]
>>> https://github.com/graalvm/mx/commit/bad56c1101db758c3f8c6560fc62012c15be39e4
>>>
>>>
>>>> --
>>>> Andrew Haley
>>>> Java Platform Lead Engineer
>>>> Red Hat UK Ltd.
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=4ZggofCo53X0nV2fk4nYuyBqw3xG4MZTeRDFqVH-pnI&s=4mmTmtLnlPEwCZErTwYIz3N2z1cw2_X5GqZs0GCBYA8&e=>
>>>>
>>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>>
From christoph.langer at sap.com Thu Apr 19 07:24:05 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 19 Apr 2018 07:24:05 +0000
Subject: RFR(XS): 8202000: AIX build broken after JDK-8195099
Message-ID: <ea09f90c35074542b77ecc975e5520f6@sap.com>
Hi,
after JDK-8195099, the AIX build is broken.
Please review this small fix which consists of renaming 2 macros that conflict with other macros coming in from a system header.
Bug: https://bugs.openjdk.java.net/browse/JDK-8202000
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8202000.0/
Thanks,
Christoph
From thomas.stuefe at gmail.com Thu Apr 19 07:26:45 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 19 Apr 2018 09:26:45 +0200
Subject: RFR(XS): 8202000: AIX build broken after JDK-8195099
In-Reply-To: <ea09f90c35074542b77ecc975e5520f6@sap.com>
References: <ea09f90c35074542b77ecc975e5520f6@sap.com>
Message-ID: <CAA-vtUwUsAVsziL+GWzwMjWtWXcsxh3A=hotP+QJTTX0P0U8ow@mail.gmail.com>
Seems trivial and fine. Thanks for fixing.
..Thomas
On Thu, Apr 19, 2018 at 9:24 AM, Langer, Christoph
<christoph.langer at sap.com> wrote:
> Hi,
>
>
>
> after JDK-8195099, the AIX build is broken.
>
>
>
> Please review this small fix which consists of renaming 2 macros that
> conflict with other macros coming in from a system header.
>
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202000
>
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8202000.0/
>
>
>
> Thanks,
>
> Christoph
>
>
From goetz.lindenmaier at sap.com Thu Apr 19 07:27:05 2018
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 19 Apr 2018 07:27:05 +0000
Subject: RFR(XS): 8202000: AIX build broken after JDK-8195099
In-Reply-To: <ea09f90c35074542b77ecc975e5520f6@sap.com>
References: <ea09f90c35074542b77ecc975e5520f6@sap.com>
Message-ID: <354fe465b55a4bcca46a3783ae247c9a@sap.com>
Hi Christoph,
Change looks good, thanks for fixing!
Best regards,
Goetz.
> -----Original Message-----
> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-
> bounces at openjdk.java.net] On Behalf Of Langer, Christoph
> Sent: Donnerstag, 19. April 2018 09:24
> To: hotspot-dev at openjdk.java.net
> Cc: ppc-aix-port-dev at openjdk.java.net
> Subject: [CAUTION] RFR(XS): 8202000: AIX build broken after JDK-8195099
>
> Hi,
>
>
>
> after JDK-8195099, the AIX build is broken.
>
>
>
> Please review this small fix which consists of renaming 2 macros that conflict
> with other macros coming in from a system header.
>
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202000
> <https://bugs.openjdk.java.net/browse/JDK-8202000>
>
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8202000.0/
> <http://cr.openjdk.java.net/~clanger/webrevs/8202000.0/>
>
>
>
> Thanks,
>
> Christoph
>
>
From matthias.baesken at sap.com Thu Apr 19 07:31:28 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 19 Apr 2018 07:31:28 +0000
Subject: RFR(XS): 8202000: AIX build broken after JDK-8195099
In-Reply-To: <ea09f90c35074542b77ecc975e5520f6@sap.com>
References: <ea09f90c35074542b77ecc975e5520f6@sap.com>
Message-ID: <80eb3c39d4a846e99faec1854c2590b0@sap.com>
Hi Christoph, looks good (not a Reviewer however) .
Best regards, Matthias
From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Langer, Christoph
Sent: Donnerstag, 19. April 2018 09:24
To: hotspot-dev at openjdk.java.net
Cc: ppc-aix-port-dev at openjdk.java.net
Subject: [CAUTION] RFR(XS): 8202000: AIX build broken after JDK-8195099
Hi,
after JDK-8195099, the AIX build is broken.
Please review this small fix which consists of renaming 2 macros that conflict with other macros coming in from a system header.
Bug: https://bugs.openjdk.java.net/browse/JDK-8202000
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8202000.0/
Thanks,
Christoph
From per.liden at oracle.com Thu Apr 19 07:38:48 2018
From: per.liden at oracle.com (Per Liden)
Date: Thu, 19 Apr 2018 09:38:48 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <a35ee91b-7fce-7deb-cf32-d3895526b3e2@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<f1c9b155-7f06-262c-98f6-f0d3d3b025b6@redhat.com>
<d583942c-7151-d783-14cd-658b6295203a@oracle.com>
<cf5e6638-443e-1243-96f8-599d8950c1af@redhat.com>
<F3231CFC-7B66-4BB1-B911-95AD3B2C0A83@oracle.com>
<4616d0a8-61b0-a369-61cc-e4c82c39539e@redhat.com>
<19F3CB79-99F3-4288-AAB4-7E54D8828837@oracle.com>
<c2604b75-10ea-ceec-b381-fc11b3eb3f0a@oracle.com>
<37884cc1-38d9-945d-b552-36d213677efc@oracle.com>
<a35ee91b-7fce-7deb-cf32-d3895526b3e2@oracle.com>
Message-ID: <262fbc13-181c-090d-deda-ca2060a0de99@oracle.com>
For small/trivial changes like this, Vladimir K informed me that I can
send an upstream request, with subject [Graal upstream] and the
patch/webrev to hotspot-compiler-dev.
/Per
On 04/19/2018 08:41 AM, dean.long at oracle.com wrote:
> Oh, was there a discussion I missed where it was sorted out?? I was
> expecting a PR at https://github.com/graalvm/mx/pulls, not upstream
> request sent to hotspot-compiler-dev.
>
> dl
>
> On 4/18/18 11:34 PM, Per Liden wrote:
>> Hi Dean,
>>
>> Sorry for the delay. There was some confusion around how to deal with
>> this, but that has now been sorted out. I just sent the Graal upstream
>> request to hotspot-compiler-dev. Feel free to pick it up.
>>
>> cheers,
>> Per
>>
>> On 04/19/2018 07:20 AM, dean.long at oracle.com wrote:
>>> I don't see a PR to get this upstream to Graal.? Is someone working
>>> on it?? If not I can do it.
>>>
>>> dl
>>>
>>> On 4/15/18 2:27 PM, Doug Simon wrote:
>>>>
>>>>> On 15 Apr 2018, at 12:03, Andrew Haley <aph at redhat.com> wrote:
>>>>>
>>>>> On 04/14/2018 01:29 PM, Doug Simon wrote:
>>>>>>> In the meantime, be aware that Graal development on JDK11 is broken
>>>>>>> until this change is pushed to Graal.? As far as I know, Graal
>>>>>>> changes
>>>>>>> are supposed to be reviewed by Graal developers.
>>>>>> Changes like this one can be reviewed by anyone in the HotSpot
>>>>>> compiler team or Graal team.
>>>>> That's good to know.? The change is obviously correct, but it needs to
>>>>> be handled correctly.
>>>> Right. The GitHub Graal code base needs to work from JDK 8 (with a
>>>> JVMCI patch) onwards. We have just recently switched to using
>>>> multi-release jars to make this process saner and avoid the use of
>>>> reflection to access version dependent API. When GitHub Graal
>>>> snapshots are taken for syncing the code into OpenJDK, the versioned
>>>> directories are flattened to the non-versioned root directory
>>>> following the same logic that would be applied when resolving a
>>>> versioned class at runtime. The flattenmultireleasesources
>>>> command[1] was added to mx to facilitate this flattening.
>>>>
>>>> The particular change in this webrev is a good opportunity to make
>>>> GraalHotSpotVMConfig versioned in this way. I'll make the necessary
>>>> changes for this in GitHub Graal. Normally, no manual change should
>>>> be made to OpenJDK Graal but in this case I think it's necessary so
>>>> that OpenJDK testing of Graal won't break.
>>>>
>>>>> For my information, though, I presume "changes like this" means simple
>>>>> changes to JVMCI.? That right?
>>>> Sorry for my ambiguity. I meant that this is a simple change to both
>>>> JVMCI and Graal and by now most HotSpot compiler developers should
>>>> be able to review it. Of course, having a Graal developer look at it
>>>> as well is recommended. The preferred way to do this is to open a PR
>>>> at https://github.com/graalvm/mx/pulls.
>>>>
>>>> -Doug
>>>>
>>>> [1]
>>>> https://github.com/graalvm/mx/commit/bad56c1101db758c3f8c6560fc62012c15be39e4
>>>>
>>>>
>>>>> --
>>>>> Andrew Haley
>>>>> Java Platform Lead Engineer
>>>>> Red Hat UK Ltd.
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=4ZggofCo53X0nV2fk4nYuyBqw3xG4MZTeRDFqVH-pnI&s=4mmTmtLnlPEwCZErTwYIz3N2z1cw2_X5GqZs0GCBYA8&e=>
>>>>>
>>>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>>>
>
From christoph.langer at sap.com Thu Apr 19 07:40:43 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 19 Apr 2018 07:40:43 +0000
Subject: RFR(XS): 8202000: AIX build broken after JDK-8195099
In-Reply-To: <354fe465b55a4bcca46a3783ae247c9a@sap.com>
References: <ea09f90c35074542b77ecc975e5520f6@sap.com>
<354fe465b55a4bcca46a3783ae247c9a@sap.com>
Message-ID: <efd9ed33a2654e5d99410a92634ede13@sap.com>
Thanks for reviewing. I will run it through jdk-submit, then push it.
> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Donnerstag, 19. April 2018 09:27
> To: Langer, Christoph <christoph.langer at sap.com>; hotspot-
> dev at openjdk.java.net
> Cc: ppc-aix-port-dev at openjdk.java.net
> Subject: RE: RFR(XS): 8202000: AIX build broken after JDK-8195099
>
> Hi Christoph,
>
> Change looks good, thanks for fixing!
>
> Best regards,
> Goetz.
>
> > -----Original Message-----
> > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-
> > bounces at openjdk.java.net] On Behalf Of Langer, Christoph
> > Sent: Donnerstag, 19. April 2018 09:24
> > To: hotspot-dev at openjdk.java.net
> > Cc: ppc-aix-port-dev at openjdk.java.net
> > Subject: [CAUTION] RFR(XS): 8202000: AIX build broken after JDK-8195099
> >
> > Hi,
> >
> >
> >
> > after JDK-8195099, the AIX build is broken.
> >
> >
> >
> > Please review this small fix which consists of renaming 2 macros that
> conflict
> > with other macros coming in from a system header.
> >
> >
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8202000
> > <https://bugs.openjdk.java.net/browse/JDK-8202000>
> >
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8202000.0/
> > <http://cr.openjdk.java.net/~clanger/webrevs/8202000.0/>
> >
> >
> >
> > Thanks,
> >
> > Christoph
> >
> >
From christoph.langer at sap.com Thu Apr 19 08:00:46 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 19 Apr 2018 08:00:46 +0000
Subject: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
In-Reply-To: <d8b60482-35a8-304a-9a4d-3c0e37b0e0cc@oracle.com>
References: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
<CAA-vtUz48xUdXQzDEAuS2JDdnis7n2pAjfJ52dgFkhKskNoX9Q@mail.gmail.com>
<b65af851-d138-42b2-847a-fd6650a1767b@oracle.com>
<CAA-vtUz+cyza6GOnVN7p-9XJ-JYo_vBozMNh0K=7woUbV4mKzA@mail.gmail.com>
<b0fcb60f-ff76-9b98-871c-8692f4504442@oracle.com>
<43ae45216d3545518b274dd7246d7862@sap.com>
<4dcc535e-4906-05a8-0636-65191f8a8695@oracle.com>
<5fc75353a1a74c22a0c24e2bdfc2d05b@sap.com>
<CAA-vtUyKJ4dXw7RS+CvTkKj5j0R+UB-4_pwpHqDExKCYGR8vhQ@mail.gmail.com>
<d8b60482-35a8-304a-9a4d-3c0e37b0e0cc@oracle.com>
Message-ID: <b623fc51e0d647888f641c62e4e16656@sap.com>
Hi David, Thomas,
@David: No, I don't think it needs to be dialed back at this point, but I agree, the bug should be updated somewhat to the current scope by mentioning that the goal is to get rid of jio_print and jio_printf completely (along with call_jio_print in ostream.cpp). Those 2 functions were just 2 hooks used in ostream.cpp and got routed through jio_vfprintf anyway, except for the raw write case when no vfprint_hook was installed - and we'll preserve that.
As for your concern, Thomas: I don't think this should hold us back here. The jio_vfprintf function is used ubiquitously throughout the jdk and the same concern would apply. Though obviously the vfprintf hook functionality is not documented very well, I guess in fact we rely on Posix compliant vfprintf implementations already for quite some time. Plus we are not talking about a downport into a delivered JDK here but it's about the upcoming JDK11.
Best regards
Christoph
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Donnerstag, 19. April 2018 00:11
> To: Thomas St?fe <thomas.stuefe at gmail.com>; Langer, Christoph
> <christoph.langer at sap.com>
> Cc: daniel.daugherty at oracle.com; hotspot-dev at openjdk.java.net; hotspot-
> runtime-dev at openjdk.java.net
> Subject: Re: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
>
> I'm losing track of the original goal here and the scope of this seems
> to be blowing out into unknown territory. We don't know why we need the
> raw write; and we don't know what we can assume about the vprintf-hook.
>
> I suggest to dial this back to whatever real issue was initially being
> addressed.
>
> Cheers,
> David
>
> On 19/04/2018 1:55 AM, Thomas St?fe wrote:
> > Hi Chrisoph,
> >
> > thanks for the new webrev, this looks all very reasonable.
> >
> > Unfortunately a small issue occurred to me while thinking this over...
> > Sigh, this turns out to be more complicated than I thought.
> >
> > The original intent of this change was to get rid of that extra copy
> > step we do in "call_jio_print" which aims to ensure that the string we
> > hand down to jio_print is zero terminated.
> >
> > But ultimately, the problem was never jio_print, but the vfprintf
> > hook: The vfprintf hook has the form "foo(FILE*, char* fmt, ....) and
> > this is a contract with an embedding program - it has to provide a
> > "fprinf-like function" but ultimately can do whatever it wants with
> > the arguments we give it.
> >
> > (IMHO this whole vfprintf hook thing was very badly designed. We had a
> > number of issues with this already. For a discussion about some
> > details, see e.g.
> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> May/026794.html
> > .)
> >
> > The problem I see is that now we may call the vfprintf hook with
> > something like ("%.*s", precision, s) with the explicit intention of
> > passing in not-zero-terminated strings for s and a precision which
> > prevents us reading beyond the end of s. This was the whole point - we
> > avoid the copy step.
> >
> > As we discussed offlist, this would be a perfectly valid fix were we
> > to feed those arguments to a standard fprintf() function which is
> > POSIX compatible, because POSIX states for the format specifier 's':
> >
> > <quote>
> > The argument shall be a pointer to an array of char. Bytes from the
> > array shall be written up to (but not including) any terminating null
> > byte. If the precision is specified, no more than that many bytes
> > shall be written. If the precision is not specified or is greater than
> > the size of the array, the application shall ensure that the array
> > contains a null byte.
> > </quote>
> >
> > This explicitly allows us to pass a pointer to a non-zero-terminated
> > string as long as the precision is smaller than its length.
> >
> > However, the argument vfprintf hook can be anything. It is a
> > user-provided function. Usually they will probably just call vxxprintf
> > functions from the libc, but for all we know they may roll their own
> > printf routine. So, we may uncover bugs in their implementation.
> >
> > Seeing that the vfprintf hook is very badly documented, we move in
> > gray area here. We may break user code which has a bad, non-Posix
> > implementation of the vfprintf hook.
> >
> > I would like to know if others think this concern is valid.
> >
> > Otherwise, the patch looks good.
> >
> >
> > ..Thomas
> >
> >
> >
> > On Wed, Apr 18, 2018 at 5:01 PM, Langer, Christoph
> > <christoph.langer at sap.com> wrote:
> >> Hi,
> >>
> >>>> I think it could be cleaned up nicely by removing jio_print and jio_printf
> >>> from jvm.cpp and doing all in ostream.cpp. At the one place where we
> would
> >>> call jio_print after my patch, we can do the vfprintf hook check and then
> >>> either write to the hook or do the raw write. And the other 2 places
> where
> >>> jio_printf is employed, we can just call
> >>> jio_vfprintf(defaultStream::output_stream()). I don't see any other
> users of
> >>> jio_print and jio_printf in the jdk repo.
> >>>>
> >>>> Any objections to that (e.g. some Oracle closed coding that'd break)?
> >>> Otherwise I'll prepare something...
> >>>
> >>> $ grep -r jio_print closed
> >>>
> >>> Showed nothing found.
> >>
> >> I've prepared a new webrev:
> http://cr.openjdk.java.net/~clanger/webrevs/8201649.1/
> >>
> >> I remove jio_printf and jio_print completely.
> >>
> >> If we agree that in defaultStream::write(), the raw write is not needed
> and we can use fprintf, we could further simplify the code to just call
> jio_fprintf.
> >>
> >> Furhtermore, I have updated the jio_*print* function declarations in
> jvm.cpp to match those of jvm.h. Is that desired (I thought yes, in times
> where we try to get rid of the mapfiles anyway). I wonder if those symbols
> can be taken out of make/hotspot/symbols/symbols-shared then...
> >>
> >> Best regards
> >> Christoph
From kim.barrett at oracle.com Thu Apr 19 08:18:35 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 19 Apr 2018 04:18:35 -0400
Subject: RFR: 8200557: OopStorage parallel iteration scales poorly
Message-ID: <7CBB6FF2-AC36-4723-BBA1-B4FA277C707B@oracle.com>
Please review this change to OopStorage parallel iteration to improve
the scaling with additional threads.
Two sources of poor scaling were found: (1) contention when claiming
blocks, and (2) each worker thread ended up touching the majority of
the blocks, even those not processed by that thread.
To address this, we changed the representation of the sequence of all
blocks. Rather than being a doubly-linked intrusive list linked
through the blocks, it is now an array of pointers to blocks. We use
a combination of refcounts and an RCU-inspired mechanism to safely
manage the array storage when it needs to grow, avoiding the need to
lock access to the array while performing concurrent iteration.
The use of an array for the sequence of all blocks permits parallel
iteration to claim ranges of indices using Atomic::add, which can be
more efficient on some platforms than using cmpxchg loops. It also
allows a worker thread to only touch exactly those blocks it is going
to process, rather than walking a list of blocks. The only
complicating factor is that we have to account for possible overshoot
in a claim attempt.
Blocks know their position in the array, to facilitate empty block
deletion (an empty block might be anywhere in the active array, and we
don't want to have to search for it). This also helps with
allocation_status, eliminating the verification search that was needed
with the list representation. allocation_status is now constant-time,
which directly benefits -Xcheck:jni.
A new gtest-based performance demonstration is included. It's not
really a test, in that it doesn't do any verification. Rather, it
performs parallel iteration and reports total time, per-thread times,
and per-thread percentage of blocks processed. This is done for a
variety of thread counts, to show the parallel speedup and load
balancing. Running on my dual 6 core Xeon, I'm seeing more or less
linear speedup for up to 10 threads processing 1M OopStorage entries.
CR:
https://bugs.openjdk.java.net/browse/JDK-8200557
Webrev:
http://cr.openjdk.java.net/~kbarrett/8200557/open.00/
Testing:
jdk-tier{1-3}, hs-tier{1-5}, on all Oracle supported platforms
From per.liden at oracle.com Thu Apr 19 08:32:52 2018
From: per.liden at oracle.com (Per Liden)
Date: Thu, 19 Apr 2018 10:32:52 +0200
Subject: RFR 8201785: Make ModRefBarrierSetAssembler abstract on all
platforms
In-Reply-To: <1148c233-dcaa-9de8-ecce-f416a0aa7634@redhat.com>
References: <1148c233-dcaa-9de8-ecce-f416a0aa7634@redhat.com>
Message-ID: <e538323d-c8cb-9d1b-4785-9e7a4d410eb6@oracle.com>
Looks good to me!
/Per
On 04/18/2018 01:57 PM, Aleksey Shipilev wrote:
> RFE:
> https://bugs.openjdk.java.net/browse/JDK-8201785
>
> Webrev:
> http://cr.openjdk.java.net/~shade/8201785/webrev.02/
>
> Found this when while rebasing Epsilon to the recent jdk/jdk. ModRefBSAssembler is abstract on some
> platforms (x86, sparc), but not on the others (aarch64, ppc). I think this allows missing the
> required overrides of oop_store_at in ModRefBSAssembler subclasses, which should be caught
> mechanically. (Epsilon used to defer to ModRefBSAssembler, and it was successfully instantiated!)
>
> PPC folks, would you like to give it a spin on your platforms?
>
> Testing: x86_64 and aarch64 non-PCH builds, Epsilon tests
>
> Thanks,
> -Aleksey
>
From robbin.ehn at oracle.com Thu Apr 19 08:36:02 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Thu, 19 Apr 2018 10:36:02 +0200
Subject: RFR 8201799: Build failures after JDK-8195099 (Concurrent
safe-memory-reclamation mechanism)
In-Reply-To: <9670dc77-9c31-e2b0-5b74-35466cd5b45e@redhat.com>
References: <150dc231-d81e-58da-fa46-fd2397bb7ca2@redhat.com>
<1524055186.6872.7.camel@oracle.com>
<9670dc77-9c31-e2b0-5b74-35466cd5b45e@redhat.com>
Message-ID: <6eacfa12-53c4-53b1-b3c0-7cde894f92ea@oracle.com>
On 2018-04-18 15:07, Aleksey Shipilev wrote:
> Thanks guys, I verified that removal of the include does not break aarch64 build, and pushed:
> http://hg.openjdk.java.net/jdk/jdk/rev/0c2ceb50783e
Thanks!
/Robbin
>
> -Aleksey
>
> On 04/18/2018 02:39 PM, Thomas Schatzl wrote:
>> Hi,
>>
>> On Wed, 2018-04-18 at 13:50 +0200, Aleksey Shipilev wrote:
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8201799
>>>
>>> Fix:
>>>
>>> diff -r bfba4712d4ff
>>> src/hotspot/share/utilities/globalCounter.inline.hpp
>>> --- a/src/hotspot/share/utilities/globalCounter.inline.hpp Wed
>>> Apr 18 11:36:48 2018 +0200
>>> +++ b/src/hotspot/share/utilities/globalCounter.inline.hpp Wed
>>> Apr 18 13:50:34 2018 +0200
>>> @@ -27,6 +27,7 @@
>>>
>>> #include "runtime/orderAccess.inline.hpp"
>>> #include "runtime/thread.hpp"
>>
>> Agree with David that this line should be removed before pushing.
>>
>>> +#include "runtime/thread.inline.hpp"
>>> #include "utilities/globalCounter.hpp"
>>>
>>> inline void GlobalCounter::critical_section_begin(Thread *thread) {
>>>
>>> Testing: failing aarch64 build
>>
>> Seems good to go.
>>
>> Thomas
>>
>
>
From shade at redhat.com Thu Apr 19 08:41:26 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 19 Apr 2018 10:41:26 +0200
Subject: RFR 8201785: Make ModRefBarrierSetAssembler abstract on all
platforms
In-Reply-To: <e538323d-c8cb-9d1b-4785-9e7a4d410eb6@oracle.com>
References: <1148c233-dcaa-9de8-ecce-f416a0aa7634@redhat.com>
<e538323d-c8cb-9d1b-4785-9e7a4d410eb6@oracle.com>
Message-ID: <58bf3511-989e-6d57-b365-d952fe57b4cd@redhat.com>
On 04/19/2018 10:32 AM, Per Liden wrote:
> Looks good to me!
>
> /Per
>
> On 04/18/2018 01:57 PM, Aleksey Shipilev wrote:
>> RFE:
>> ?? https://bugs.openjdk.java.net/browse/JDK-8201785
>>
>> Webrev:
>> ?? http://cr.openjdk.java.net/~shade/8201785/webrev.02/
>>
>> Found this when while rebasing Epsilon to the recent jdk/jdk. ModRefBSAssembler is abstract on some
>> platforms (x86, sparc), but not on the others (aarch64, ppc). I think this allows missing the
>> required overrides of oop_store_at in ModRefBSAssembler subclasses, which should be caught
>> mechanically. (Epsilon used to defer to ModRefBSAssembler, and it was successfully instantiated!)
>>
>> PPC folks, would you like to give it a spin on your platforms?
Thanks, Per. Thomas S, Martin D, do you trust me with PPC here? :)
-Aleksey
From thomas.stuefe at gmail.com Thu Apr 19 09:12:22 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 19 Apr 2018 11:12:22 +0200
Subject: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
In-Reply-To: <b623fc51e0d647888f641c62e4e16656@sap.com>
References: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
<CAA-vtUz48xUdXQzDEAuS2JDdnis7n2pAjfJ52dgFkhKskNoX9Q@mail.gmail.com>
<b65af851-d138-42b2-847a-fd6650a1767b@oracle.com>
<CAA-vtUz+cyza6GOnVN7p-9XJ-JYo_vBozMNh0K=7woUbV4mKzA@mail.gmail.com>
<b0fcb60f-ff76-9b98-871c-8692f4504442@oracle.com>
<43ae45216d3545518b274dd7246d7862@sap.com>
<4dcc535e-4906-05a8-0636-65191f8a8695@oracle.com>
<5fc75353a1a74c22a0c24e2bdfc2d05b@sap.com>
<CAA-vtUyKJ4dXw7RS+CvTkKj5j0R+UB-4_pwpHqDExKCYGR8vhQ@mail.gmail.com>
<d8b60482-35a8-304a-9a4d-3c0e37b0e0cc@oracle.com>
<b623fc51e0d647888f641c62e4e16656@sap.com>
Message-ID: <CAA-vtUzcazFtehWh3zOxHk-CSmazD7XLEF3CMrQ3_A0AaoXJrw@mail.gmail.com>
Hi Christoph,
On Thu, Apr 19, 2018 at 10:00 AM, Langer, Christoph
<christoph.langer at sap.com> wrote:
> Hi David, Thomas,
>
> @David: No, I don't think it needs to be dialed back at this point, but I agree, the bug should be updated somewhat to the current scope by mentioning that the goal is to get rid of jio_print and jio_printf completely (along with call_jio_print in ostream.cpp). Those 2 functions were just 2 hooks used in ostream.cpp and got routed through jio_vfprintf anyway, except for the raw write case when no vfprint_hook was installed - and we'll preserve that.
>
Hm. Instead of broading the scope of the issue, I would actually
prefer the bug description to be clarified and limited to the original
problem we tried to solve. Because that was a real valid problem.
If only to get David's full review and not to confuse him further :)
Just to recuperate, the original problem was:
We have situations where we would like to feed non-zero-terminated
strings with a given string length to jio_print(). One of these
occasions is when the attach framework tries to write multiple lines
via defaultStream::print_raw().
But jio_print() takes a zero terminated string. Non-zero terminated
strings are therefore zero terminated by creating a copy of the string
and adding a zero - see call_jio_helper().
This copying happens with a fixed buffer and sometimes causes
truncation. These issues are hard to find, since they seem to be
random - if the input string just happens to be followed by a zero,
the copy step is avoided and no truncation happens.
Christophs fix aims to get rid of the copying step to avoid
truncation. All the rest is fluff and cleanup.
> As for your concern, Thomas: I don't think this should hold us back here. The jio_vfprintf function is used ubiquitously throughout the jdk and the same concern would apply. Though obviously the vfprintf hook functionality is not documented very well, I guess in fact we rely on Posix compliant vfprintf implementations already for quite some time. Plus we are not talking about a downport into a delivered JDK here but it's about the upcoming JDK11.
>
Okay...
Best regards, Thomas
> Best regards
> Christoph
>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Donnerstag, 19. April 2018 00:11
>> To: Thomas St?fe <thomas.stuefe at gmail.com>; Langer, Christoph
>> <christoph.langer at sap.com>
>> Cc: daniel.daugherty at oracle.com; hotspot-dev at openjdk.java.net; hotspot-
>> runtime-dev at openjdk.java.net
>> Subject: Re: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
>>
>> I'm losing track of the original goal here and the scope of this seems
>> to be blowing out into unknown territory. We don't know why we need the
>> raw write; and we don't know what we can assume about the vprintf-hook.
>>
>> I suggest to dial this back to whatever real issue was initially being
>> addressed.
>>
>> Cheers,
>> David
>>
>> On 19/04/2018 1:55 AM, Thomas St?fe wrote:
>> > Hi Chrisoph,
>> >
>> > thanks for the new webrev, this looks all very reasonable.
>> >
>> > Unfortunately a small issue occurred to me while thinking this over...
>> > Sigh, this turns out to be more complicated than I thought.
>> >
>> > The original intent of this change was to get rid of that extra copy
>> > step we do in "call_jio_print" which aims to ensure that the string we
>> > hand down to jio_print is zero terminated.
>> >
>> > But ultimately, the problem was never jio_print, but the vfprintf
>> > hook: The vfprintf hook has the form "foo(FILE*, char* fmt, ....) and
>> > this is a contract with an embedding program - it has to provide a
>> > "fprinf-like function" but ultimately can do whatever it wants with
>> > the arguments we give it.
>> >
>> > (IMHO this whole vfprintf hook thing was very badly designed. We had a
>> > number of issues with this already. For a discussion about some
>> > details, see e.g.
>> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
>> May/026794.html
>> > .)
>> >
>> > The problem I see is that now we may call the vfprintf hook with
>> > something like ("%.*s", precision, s) with the explicit intention of
>> > passing in not-zero-terminated strings for s and a precision which
>> > prevents us reading beyond the end of s. This was the whole point - we
>> > avoid the copy step.
>> >
>> > As we discussed offlist, this would be a perfectly valid fix were we
>> > to feed those arguments to a standard fprintf() function which is
>> > POSIX compatible, because POSIX states for the format specifier 's':
>> >
>> > <quote>
>> > The argument shall be a pointer to an array of char. Bytes from the
>> > array shall be written up to (but not including) any terminating null
>> > byte. If the precision is specified, no more than that many bytes
>> > shall be written. If the precision is not specified or is greater than
>> > the size of the array, the application shall ensure that the array
>> > contains a null byte.
>> > </quote>
>> >
>> > This explicitly allows us to pass a pointer to a non-zero-terminated
>> > string as long as the precision is smaller than its length.
>> >
>> > However, the argument vfprintf hook can be anything. It is a
>> > user-provided function. Usually they will probably just call vxxprintf
>> > functions from the libc, but for all we know they may roll their own
>> > printf routine. So, we may uncover bugs in their implementation.
>> >
>> > Seeing that the vfprintf hook is very badly documented, we move in
>> > gray area here. We may break user code which has a bad, non-Posix
>> > implementation of the vfprintf hook.
>> >
>> > I would like to know if others think this concern is valid.
>> >
>> > Otherwise, the patch looks good.
>> >
>> >
>> > ..Thomas
>> >
>> >
>> >
>> > On Wed, Apr 18, 2018 at 5:01 PM, Langer, Christoph
>> > <christoph.langer at sap.com> wrote:
>> >> Hi,
>> >>
>> >>>> I think it could be cleaned up nicely by removing jio_print and jio_printf
>> >>> from jvm.cpp and doing all in ostream.cpp. At the one place where we
>> would
>> >>> call jio_print after my patch, we can do the vfprintf hook check and then
>> >>> either write to the hook or do the raw write. And the other 2 places
>> where
>> >>> jio_printf is employed, we can just call
>> >>> jio_vfprintf(defaultStream::output_stream()). I don't see any other
>> users of
>> >>> jio_print and jio_printf in the jdk repo.
>> >>>>
>> >>>> Any objections to that (e.g. some Oracle closed coding that'd break)?
>> >>> Otherwise I'll prepare something...
>> >>>
>> >>> $ grep -r jio_print closed
>> >>>
>> >>> Showed nothing found.
>> >>
>> >> I've prepared a new webrev:
>> http://cr.openjdk.java.net/~clanger/webrevs/8201649.1/
>> >>
>> >> I remove jio_printf and jio_print completely.
>> >>
>> >> If we agree that in defaultStream::write(), the raw write is not needed
>> and we can use fprintf, we could further simplify the code to just call
>> jio_fprintf.
>> >>
>> >> Furhtermore, I have updated the jio_*print* function declarations in
>> jvm.cpp to match those of jvm.h. Is that desired (I thought yes, in times
>> where we try to get rid of the mapfiles anyway). I wonder if those symbols
>> can be taken out of make/hotspot/symbols/symbols-shared then...
>> >>
>> >> Best regards
>> >> Christoph
From aph at redhat.com Thu Apr 19 09:25:12 2018
From: aph at redhat.com (Andrew Haley)
Date: Thu, 19 Apr 2018 10:25:12 +0100
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <262fbc13-181c-090d-deda-ca2060a0de99@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<f1c9b155-7f06-262c-98f6-f0d3d3b025b6@redhat.com>
<d583942c-7151-d783-14cd-658b6295203a@oracle.com>
<cf5e6638-443e-1243-96f8-599d8950c1af@redhat.com>
<F3231CFC-7B66-4BB1-B911-95AD3B2C0A83@oracle.com>
<4616d0a8-61b0-a369-61cc-e4c82c39539e@redhat.com>
<19F3CB79-99F3-4288-AAB4-7E54D8828837@oracle.com>
<c2604b75-10ea-ceec-b381-fc11b3eb3f0a@oracle.com>
<37884cc1-38d9-945d-b552-36d213677efc@oracle.com>
<a35ee91b-7fce-7deb-cf32-d3895526b3e2@oracle.com>
<262fbc13-181c-090d-deda-ca2060a0de99@oracle.com>
Message-ID: <eb777750-3ab2-9635-8ffc-59217ba209c6@redhat.com>
On 04/19/2018 08:38 AM, Per Liden wrote:
> For small/trivial changes like this, Vladimir K informed me that I can
> send an upstream request, with subject [Graal upstream] and the
> patch/webrev to hotspot-compiler-dev.
But surely someone still has to do it.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From martin.doerr at sap.com Thu Apr 19 09:59:58 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 19 Apr 2018 09:59:58 +0000
Subject: RFR 8201785: Make ModRefBarrierSetAssembler abstract on all
platforms
In-Reply-To: <58bf3511-989e-6d57-b365-d952fe57b4cd@redhat.com>
References: <1148c233-dcaa-9de8-ecce-f416a0aa7634@redhat.com>
<e538323d-c8cb-9d1b-4785-9e7a4d410eb6@oracle.com>
<58bf3511-989e-6d57-b365-d952fe57b4cd@redhat.com>
Message-ID: <cd2ab2b58ec84856a52101b2016183ec@sap.com>
Hi Aleksey,
PPC64 and s390 parts look good. Reviewed and built on linux.
Thanks and best regards,
Martin
-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Aleksey Shipilev
Sent: Donnerstag, 19. April 2018 10:41
To: Per Liden <per.liden at oracle.com>; hotspot-dev at openjdk.java.net
Subject: Re: RFR 8201785: Make ModRefBarrierSetAssembler abstract on all platforms
On 04/19/2018 10:32 AM, Per Liden wrote:
> Looks good to me!
>
> /Per
>
> On 04/18/2018 01:57 PM, Aleksey Shipilev wrote:
>> RFE:
>> ?? https://bugs.openjdk.java.net/browse/JDK-8201785
>>
>> Webrev:
>> ?? http://cr.openjdk.java.net/~shade/8201785/webrev.02/
>>
>> Found this when while rebasing Epsilon to the recent jdk/jdk. ModRefBSAssembler is abstract on some
>> platforms (x86, sparc), but not on the others (aarch64, ppc). I think this allows missing the
>> required overrides of oop_store_at in ModRefBSAssembler subclasses, which should be caught
>> mechanically. (Epsilon used to defer to ModRefBSAssembler, and it was successfully instantiated!)
>>
>> PPC folks, would you like to give it a spin on your platforms?
Thanks, Per. Thomas S, Martin D, do you trust me with PPC here? :)
-Aleksey
From shade at redhat.com Thu Apr 19 10:03:31 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 19 Apr 2018 12:03:31 +0200
Subject: RFR 8201785: Make ModRefBarrierSetAssembler abstract on all
platforms
In-Reply-To: <cd2ab2b58ec84856a52101b2016183ec@sap.com>
References: <1148c233-dcaa-9de8-ecce-f416a0aa7634@redhat.com>
<e538323d-c8cb-9d1b-4785-9e7a4d410eb6@oracle.com>
<58bf3511-989e-6d57-b365-d952fe57b4cd@redhat.com>
<cd2ab2b58ec84856a52101b2016183ec@sap.com>
Message-ID: <0f8aa09d-d6fe-9857-5593-1c72e741d283@redhat.com>
Thanks for testing, pushed.
-Aleksey
On 04/19/2018 11:59 AM, Doerr, Martin wrote:
> Hi Aleksey,
>
> PPC64 and s390 parts look good. Reviewed and built on linux.
>
> Thanks and best regards,
> Martin
>
>
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Aleksey Shipilev
> Sent: Donnerstag, 19. April 2018 10:41
> To: Per Liden <per.liden at oracle.com>; hotspot-dev at openjdk.java.net
> Subject: Re: RFR 8201785: Make ModRefBarrierSetAssembler abstract on all platforms
>
> On 04/19/2018 10:32 AM, Per Liden wrote:
>> Looks good to me!
>>
>> /Per
>>
>> On 04/18/2018 01:57 PM, Aleksey Shipilev wrote:
>>> RFE:
>>> ?? https://bugs.openjdk.java.net/browse/JDK-8201785
>>>
>>> Webrev:
>>> ?? http://cr.openjdk.java.net/~shade/8201785/webrev.02/
>>>
>>> Found this when while rebasing Epsilon to the recent jdk/jdk. ModRefBSAssembler is abstract on some
>>> platforms (x86, sparc), but not on the others (aarch64, ppc). I think this allows missing the
>>> required overrides of oop_store_at in ModRefBSAssembler subclasses, which should be caught
>>> mechanically. (Epsilon used to defer to ModRefBSAssembler, and it was successfully instantiated!)
>>>
>>> PPC folks, would you like to give it a spin on your platforms?
>
> Thanks, Per. Thomas S, Martin D, do you trust me with PPC here? :)
>
> -Aleksey
>
>
From christoph.langer at sap.com Thu Apr 19 11:08:00 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 19 Apr 2018 11:08:00 +0000
Subject: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
In-Reply-To: <CAA-vtUzcazFtehWh3zOxHk-CSmazD7XLEF3CMrQ3_A0AaoXJrw@mail.gmail.com>
References: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
<CAA-vtUz48xUdXQzDEAuS2JDdnis7n2pAjfJ52dgFkhKskNoX9Q@mail.gmail.com>
<b65af851-d138-42b2-847a-fd6650a1767b@oracle.com>
<CAA-vtUz+cyza6GOnVN7p-9XJ-JYo_vBozMNh0K=7woUbV4mKzA@mail.gmail.com>
<b0fcb60f-ff76-9b98-871c-8692f4504442@oracle.com>
<43ae45216d3545518b274dd7246d7862@sap.com>
<4dcc535e-4906-05a8-0636-65191f8a8695@oracle.com>
<5fc75353a1a74c22a0c24e2bdfc2d05b@sap.com>
<CAA-vtUyKJ4dXw7RS+CvTkKj5j0R+UB-4_pwpHqDExKCYGR8vhQ@mail.gmail.com>
<d8b60482-35a8-304a-9a4d-3c0e37b0e0cc@oracle.com>
<b623fc51e0d647888f641c62e4e16656@sap.com>
<CAA-vtUzcazFtehWh3zOxHk-CSmazD7XLEF3CMrQ3_A0AaoXJrw@mail.gmail.com>
Message-ID: <8dfc9463054f485ab5ca9bc8fee00c3e@sap.com>
Hi Thomas, David,
> > @David: No, I don't think it needs to be dialed back at this point, but I
> agree, the bug should be updated somewhat to the current scope by
> mentioning that the goal is to get rid of jio_print and jio_printf completely
> (along with call_jio_print in ostream.cpp). Those 2 functions were just 2
> hooks used in ostream.cpp and got routed through jio_vfprintf anyway,
> except for the raw write case when no vfprint_hook was installed - and we'll
> preserve that.
> >
>
> Hm. Instead of broading the scope of the issue, I would actually
> prefer the bug description to be clarified and limited to the original
> problem we tried to solve. Because that was a real valid problem.
>
> If only to get David's full review and not to confuse him further :)
Ok, I agree. So I tried to clarify the bug a bit more in its original sense. And we'd be back to webrev #0.
Bug: https://bugs.openjdk.java.net/browse/JDK-8201649
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201649.0/
The change of the webrev is missing a cast in line 2729 - (len needs to be casted int). This produces a build warning which turns into an error in some platforms. I'll have that fixed in the submitted version.
For the further cleanup of jio_print methods I'll probably file another bug.
As I think we already had a principal agreement about this proposal earlier, I would consider this reviewed by stuefe and dholmes if I don't hear back from you today. I would push this tomorrow after push to jdk-submit and further internal testing here at SAP.
Thanks
Christoph
From david.holmes at oracle.com Thu Apr 19 12:06:33 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 19 Apr 2018 22:06:33 +1000
Subject: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
In-Reply-To: <8dfc9463054f485ab5ca9bc8fee00c3e@sap.com>
References: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
<CAA-vtUz48xUdXQzDEAuS2JDdnis7n2pAjfJ52dgFkhKskNoX9Q@mail.gmail.com>
<b65af851-d138-42b2-847a-fd6650a1767b@oracle.com>
<CAA-vtUz+cyza6GOnVN7p-9XJ-JYo_vBozMNh0K=7woUbV4mKzA@mail.gmail.com>
<b0fcb60f-ff76-9b98-871c-8692f4504442@oracle.com>
<43ae45216d3545518b274dd7246d7862@sap.com>
<4dcc535e-4906-05a8-0636-65191f8a8695@oracle.com>
<5fc75353a1a74c22a0c24e2bdfc2d05b@sap.com>
<CAA-vtUyKJ4dXw7RS+CvTkKj5j0R+UB-4_pwpHqDExKCYGR8vhQ@mail.gmail.com>
<d8b60482-35a8-304a-9a4d-3c0e37b0e0cc@oracle.com>
<b623fc51e0d647888f641c62e4e16656@sap.com>
<CAA-vtUzcazFtehWh3zOxHk-CSmazD7XLEF3CMrQ3_A0AaoXJrw@mail.gmail.com>
<8dfc9463054f485ab5ca9bc8fee00c3e@sap.com>
Message-ID: <ddb4644a-9977-a471-6e41-69572793d08c@oracle.com>
Hi Christoph,
On 19/04/2018 9:08 PM, Langer, Christoph wrote:
> Hi Thomas, David,
>
>>> @David: No, I don't think it needs to be dialed back at this point, but I
>> agree, the bug should be updated somewhat to the current scope by
>> mentioning that the goal is to get rid of jio_print and jio_printf completely
>> (along with call_jio_print in ostream.cpp). Those 2 functions were just 2
>> hooks used in ostream.cpp and got routed through jio_vfprintf anyway,
>> except for the raw write case when no vfprint_hook was installed - and we'll
>> preserve that.
You preserved it in the sense it's still there, but you changed two call
sites so they can never now hit it. So I'm back to the unanswerable
"does that matter?".
Unless someone can do the archaeology on this I'm going to have to abstain.
David
-----
>>>
>>
>> Hm. Instead of broading the scope of the issue, I would actually
>> prefer the bug description to be clarified and limited to the original
>> problem we tried to solve. Because that was a real valid problem.
>>
>> If only to get David's full review and not to confuse him further :)
>
> Ok, I agree. So I tried to clarify the bug a bit more in its original sense. And we'd be back to webrev #0.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201649
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201649.0/
>
> The change of the webrev is missing a cast in line 2729 - (len needs to be casted int). This produces a build warning which turns into an error in some platforms. I'll have that fixed in the submitted version.
>
> For the further cleanup of jio_print methods I'll probably file another bug.
>
> As I think we already had a principal agreement about this proposal earlier, I would consider this reviewed by stuefe and dholmes if I don't hear back from you today. I would push this tomorrow after push to jdk-submit and further internal testing here at SAP.
>
> Thanks
> Christoph
>
From thomas.stuefe at gmail.com Thu Apr 19 12:27:27 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 19 Apr 2018 14:27:27 +0200
Subject: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
In-Reply-To: <8dfc9463054f485ab5ca9bc8fee00c3e@sap.com>
References: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
<CAA-vtUz48xUdXQzDEAuS2JDdnis7n2pAjfJ52dgFkhKskNoX9Q@mail.gmail.com>
<b65af851-d138-42b2-847a-fd6650a1767b@oracle.com>
<CAA-vtUz+cyza6GOnVN7p-9XJ-JYo_vBozMNh0K=7woUbV4mKzA@mail.gmail.com>
<b0fcb60f-ff76-9b98-871c-8692f4504442@oracle.com>
<43ae45216d3545518b274dd7246d7862@sap.com>
<4dcc535e-4906-05a8-0636-65191f8a8695@oracle.com>
<5fc75353a1a74c22a0c24e2bdfc2d05b@sap.com>
<CAA-vtUyKJ4dXw7RS+CvTkKj5j0R+UB-4_pwpHqDExKCYGR8vhQ@mail.gmail.com>
<d8b60482-35a8-304a-9a4d-3c0e37b0e0cc@oracle.com>
<b623fc51e0d647888f641c62e4e16656@sap.com>
<CAA-vtUzcazFtehWh3zOxHk-CSmazD7XLEF3CMrQ3_A0AaoXJrw@mail.gmail.com>
<8dfc9463054f485ab5ca9bc8fee00c3e@sap.com>
Message-ID: <CAA-vtUy4RXKVx0QkRLHw9sMAJho0jSnVgRUjK8tDya9Fp=Uc4w@mail.gmail.com>
On Thu, Apr 19, 2018 at 1:08 PM, Langer, Christoph
<christoph.langer at sap.com> wrote:
> Hi Thomas, David,
>
>> > @David: No, I don't think it needs to be dialed back at this point, but I
>> agree, the bug should be updated somewhat to the current scope by
>> mentioning that the goal is to get rid of jio_print and jio_printf completely
>> (along with call_jio_print in ostream.cpp). Those 2 functions were just 2
>> hooks used in ostream.cpp and got routed through jio_vfprintf anyway,
>> except for the raw write case when no vfprint_hook was installed - and we'll
>> preserve that.
>> >
>>
>> Hm. Instead of broading the scope of the issue, I would actually
>> prefer the bug description to be clarified and limited to the original
>> problem we tried to solve. Because that was a real valid problem.
>>
>> If only to get David's full review and not to confuse him further :)
>
> Ok, I agree. So I tried to clarify the bug a bit more in its original sense. And we'd be back to webrev #0.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201649
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201649.0/
>
> The change of the webrev is missing a cast in line 2729 - (len needs to be casted int). This produces a build warning which turns into an error in some platforms. I'll have that fixed in the submitted version.
>
> For the further cleanup of jio_print methods I'll probably file another bug.
>
> As I think we already had a principal agreement about this proposal earlier, I would consider this reviewed by stuefe and dholmes if I don't hear back from you today. I would push this tomorrow after push to jdk-submit and further internal testing here at SAP.
>
I am fine with webrev 0, beside the concern I already voiced about
feeding ("%.*s", prec, not-zero-terminated-string) to a vfprintf hook.
Not sure if David is though. I did not read his initial mail as
review, so I think we should wait for his confirmation.
..Thomas
> Thanks
> Christoph
>
From per.liden at oracle.com Thu Apr 19 13:10:53 2018
From: per.liden at oracle.com (Per Liden)
Date: Thu, 19 Apr 2018 15:10:53 +0200
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <eb777750-3ab2-9635-8ffc-59217ba209c6@redhat.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<f1c9b155-7f06-262c-98f6-f0d3d3b025b6@redhat.com>
<d583942c-7151-d783-14cd-658b6295203a@oracle.com>
<cf5e6638-443e-1243-96f8-599d8950c1af@redhat.com>
<F3231CFC-7B66-4BB1-B911-95AD3B2C0A83@oracle.com>
<4616d0a8-61b0-a369-61cc-e4c82c39539e@redhat.com>
<19F3CB79-99F3-4288-AAB4-7E54D8828837@oracle.com>
<c2604b75-10ea-ceec-b381-fc11b3eb3f0a@oracle.com>
<37884cc1-38d9-945d-b552-36d213677efc@oracle.com>
<a35ee91b-7fce-7deb-cf32-d3895526b3e2@oracle.com>
<262fbc13-181c-090d-deda-ca2060a0de99@oracle.com>
<eb777750-3ab2-9635-8ffc-59217ba209c6@redhat.com>
Message-ID: <4b931b69-f768-2bc9-98f9-343c9f4d5900@oracle.com>
On 04/19/2018 11:25 AM, Andrew Haley wrote:
> On 04/19/2018 08:38 AM, Per Liden wrote:
>> For small/trivial changes like this, Vladimir K informed me that I can
>> send an upstream request, with subject [Graal upstream] and the
>> patch/webrev to hotspot-compiler-dev.
>
> But surely someone still has to do it.
Right, the agreement is that someone in the compiler group then picks it
up and sponsor/upstream it.
cheers,
Per
From christoph.langer at sap.com Thu Apr 19 13:55:52 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 19 Apr 2018 13:55:52 +0000
Subject: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
In-Reply-To: <ddb4644a-9977-a471-6e41-69572793d08c@oracle.com>
References: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
<CAA-vtUz48xUdXQzDEAuS2JDdnis7n2pAjfJ52dgFkhKskNoX9Q@mail.gmail.com>
<b65af851-d138-42b2-847a-fd6650a1767b@oracle.com>
<CAA-vtUz+cyza6GOnVN7p-9XJ-JYo_vBozMNh0K=7woUbV4mKzA@mail.gmail.com>
<b0fcb60f-ff76-9b98-871c-8692f4504442@oracle.com>
<43ae45216d3545518b274dd7246d7862@sap.com>
<4dcc535e-4906-05a8-0636-65191f8a8695@oracle.com>
<5fc75353a1a74c22a0c24e2bdfc2d05b@sap.com>
<CAA-vtUyKJ4dXw7RS+CvTkKj5j0R+UB-4_pwpHqDExKCYGR8vhQ@mail.gmail.com>
<d8b60482-35a8-304a-9a4d-3c0e37b0e0cc@oracle.com>
<b623fc51e0d647888f641c62e4e16656@sap.com>
<CAA-vtUzcazFtehWh3zOxHk-CSmazD7XLEF3CMrQ3_A0AaoXJrw@mail.gmail.com>
<8dfc9463054f485ab5ca9bc8fee00c3e@sap.com>
<ddb4644a-9977-a471-6e41-69572793d08c@oracle.com>
Message-ID: <914df27d59224c8b90126aec2ac333fb@sap.com>
Hi,
with my means of searching in the public OpenJDK repositories I can only find that 'call_jio_print' has always been there. No idea about the backgrounds of why we need this buffer copy approach instead of using jio_printf directly.
So, can someone else please help reviewing http://cr.openjdk.java.net/~clanger/webrevs/8201649.0/ ?
Thanks
Christoph
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Donnerstag, 19. April 2018 14:07
> To: Langer, Christoph <christoph.langer at sap.com>; Thomas St?fe
> <thomas.stuefe at gmail.com>
> Cc: daniel.daugherty at oracle.com; hotspot-dev at openjdk.java.net; hotspot-
> runtime-dev at openjdk.java.net
> Subject: Re: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
>
> Hi Christoph,
>
> On 19/04/2018 9:08 PM, Langer, Christoph wrote:
> > Hi Thomas, David,
> >
> >>> @David: No, I don't think it needs to be dialed back at this point, but I
> >> agree, the bug should be updated somewhat to the current scope by
> >> mentioning that the goal is to get rid of jio_print and jio_printf completely
> >> (along with call_jio_print in ostream.cpp). Those 2 functions were just 2
> >> hooks used in ostream.cpp and got routed through jio_vfprintf anyway,
> >> except for the raw write case when no vfprint_hook was installed - and
> we'll
> >> preserve that.
>
> You preserved it in the sense it's still there, but you changed two call
> sites so they can never now hit it. So I'm back to the unanswerable
> "does that matter?".
>
> Unless someone can do the archaeology on this I'm going to have to abstain.
>
> David
> -----
>
> >>>
> >>
> >> Hm. Instead of broading the scope of the issue, I would actually
> >> prefer the bug description to be clarified and limited to the original
> >> problem we tried to solve. Because that was a real valid problem.
> >>
> >> If only to get David's full review and not to confuse him further :)
> >
> > Ok, I agree. So I tried to clarify the bug a bit more in its original sense. And
> we'd be back to webrev #0.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8201649
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201649.0/
> >
> > The change of the webrev is missing a cast in line 2729 - (len needs to be
> casted int). This produces a build warning which turns into an error in some
> platforms. I'll have that fixed in the submitted version.
> >
> > For the further cleanup of jio_print methods I'll probably file another bug.
> >
> > As I think we already had a principal agreement about this proposal earlier,
> I would consider this reviewed by stuefe and dholmes if I don't hear back
> from you today. I would push this tomorrow after push to jdk-submit and
> further internal testing here at SAP.
> >
> > Thanks
> > Christoph
> >
From erik.osterlund at oracle.com Thu Apr 19 14:36:49 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Thu, 19 Apr 2018 16:36:49 +0200
Subject: RFR 8201799: Build failures after JDK-8195099 (Concurrent
safe-memory-reclamation mechanism)
In-Reply-To: <803cb23d4b754d2384d9681950f5297c@sap.com>
References: <150dc231-d81e-58da-fa46-fd2397bb7ca2@redhat.com>
<ee7c6a6c-7697-ca4b-dd3d-484ca24aeabd@oracle.com> <5AD73E53.90904@oracle.com>
<803cb23d4b754d2384d9681950f5297c@sap.com>
Message-ID: <5AD8A981.20607@oracle.com>
Hi Doerr,
I would welcome doing the same to Atomic::inc/dec/add/sub that has
already been done for Atomic::cmpxchg. I think that should make everyone
involved happy.
Thanks,
/Erik
On 2018-04-18 18:37, Doerr, Martin wrote:
> Hi Erik,
>
> thank you for bringing this issue up again.
>
> In my opinion, good multi-threaded code specifies ordering semantics precisely for each lock-free access. I think this was done well enough here by adding a comment.
>
> It'd be great if we could specify semantics for Atomic:add like we do for Atomic::cmpchgx.
> However, the double-fence is a very bad default from performance perspective. I wonder if PPC64 is the only platform which gets hit.
> Would it be acceptable to set the default to memory_order_acquire_release and specify memory_order_conservative for the new usage? I think this would fit perfectly for PPC64, but some people may not like it. One could say PPC64 is the problem, but one could also say the VM code is the problem ??
>
> I don't really like the straight forward fix to insert a fence with #ifdef AIX.
>
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: Erik ?sterlund [mailto:erik.osterlund at oracle.com]
> Sent: Mittwoch, 18. April 2018 14:47
> To: David Holmes <david.holmes at oracle.com>; Aleksey Shipilev <shade at redhat.com>; hotspot-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>
> Subject: Re: RFR 8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism)
>
> Hi,
>
> Please also note that the Atomic::add used in write_synchronize assumes
> bidirectional fencing (which is the contract provided by Atomic::add).
> This is however not true for the PPC backend of Atomic::add - it has
> acq_rel semantics instead. So this mechanism is currently not safe to
> use on PPC.
>
> From globalCounter.cpp:
> 61 // Atomic::add must provide fence since we have storeload
> dependency.
> 62 volatile uintx gbl_cnt = Atomic::add((uintx)COUNTER_INCREMENT,
> &_global_counter._counter);
>
> Might want to have a look at the safe use of this mechanism on PPC as a
> follow-up.
>
> Thanks,
> /Erik
>
> On 2018-04-18 14:27, David Holmes wrote:
>> Hi Aleksey,
>>
>> On 18/04/2018 9:50 PM, Aleksey Shipilev wrote:
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8201799
>>>
>>> Fix:
>>>
>>> diff -r bfba4712d4ff
>>> src/hotspot/share/utilities/globalCounter.inline.hpp
>>> --- a/src/hotspot/share/utilities/globalCounter.inline.hpp Wed Apr 18
>>> 11:36:48 2018 +0200
>>> +++ b/src/hotspot/share/utilities/globalCounter.inline.hpp Wed Apr 18
>>> 13:50:34 2018 +0200
>>> @@ -27,6 +27,7 @@
>>>
>>> #include "runtime/orderAccess.inline.hpp"
>>> #include "runtime/thread.hpp"
>> The above line can be deleted now.
>>
>>> +#include "runtime/thread.inline.hpp"
>> Fix is good.
>>
>> Thanks,
>> David
>>
>>> #include "utilities/globalCounter.hpp"
>>>
>>> inline void GlobalCounter::critical_section_begin(Thread *thread) {
>>>
>>> Testing: failing aarch64 build
>>>
>>> Thanks,
>>> -Aleksey
>>>
From vladimir.kozlov at oracle.com Thu Apr 19 15:59:55 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 19 Apr 2018 08:59:55 -0700
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <a35ee91b-7fce-7deb-cf32-d3895526b3e2@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<f1c9b155-7f06-262c-98f6-f0d3d3b025b6@redhat.com>
<d583942c-7151-d783-14cd-658b6295203a@oracle.com>
<cf5e6638-443e-1243-96f8-599d8950c1af@redhat.com>
<F3231CFC-7B66-4BB1-B911-95AD3B2C0A83@oracle.com>
<4616d0a8-61b0-a369-61cc-e4c82c39539e@redhat.com>
<19F3CB79-99F3-4288-AAB4-7E54D8828837@oracle.com>
<c2604b75-10ea-ceec-b381-fc11b3eb3f0a@oracle.com>
<37884cc1-38d9-945d-b552-36d213677efc@oracle.com>
<a35ee91b-7fce-7deb-cf32-d3895526b3e2@oracle.com>
Message-ID: <286706d9-7c0f-4c18-66b3-3834f22ea8f5@oracle.com>
Yes, that was discussion I mentioned on our meeting with Labs. I proposed to send such request to our group with [Graal
upstream] in subject.
My proposal was for compiler group to sponsor small upstream Graal changes from other groups after they pushed it into
OpenJDK. We will create PR and handle review process (I think we need to include original author in PR review too).
Changes should be pushed upstream before next "Graal update" pushed into OpenJDK. Changes could be modified after review
- it is fine since we overwrite Graal code in OpenJDK anyway with each sync.
That is only way I see we can keep code in OpenJDK working all time and let changes from other groups move forward faster.
The only issue I see is we have to handle Graal support for JDK 8 when we change VM structures in current JDK which
other group usually don't include in their changes. We have to teach them eventually.
I think this will happen not frequently and we can handle it.
Note, this only applies for small changes like current one. For big Graal changes authors have to prepare PR review them
self before pushing into Graal and OpenJDK (we can help them to prepare and learn process) because they know changes the
best.
Regards,
Vladimir
On 4/18/18 11:41 PM, dean.long at oracle.com wrote:
> Oh, was there a discussion I missed where it was sorted out?? I was expecting a PR at
> https://github.com/graalvm/mx/pulls, not upstream request sent to hotspot-compiler-dev.
>
> dl
>
> On 4/18/18 11:34 PM, Per Liden wrote:
>> Hi Dean,
>>
>> Sorry for the delay. There was some confusion around how to deal with this, but that has now been sorted out. I just
>> sent the Graal upstream request to hotspot-compiler-dev. Feel free to pick it up.
>>
>> cheers,
>> Per
>>
>> On 04/19/2018 07:20 AM, dean.long at oracle.com wrote:
>>> I don't see a PR to get this upstream to Graal.? Is someone working on it?? If not I can do it.
>>>
>>> dl
>>>
>>> On 4/15/18 2:27 PM, Doug Simon wrote:
>>>>
>>>>> On 15 Apr 2018, at 12:03, Andrew Haley <aph at redhat.com> wrote:
>>>>>
>>>>> On 04/14/2018 01:29 PM, Doug Simon wrote:
>>>>>>> In the meantime, be aware that Graal development on JDK11 is broken
>>>>>>> until this change is pushed to Graal.? As far as I know, Graal changes
>>>>>>> are supposed to be reviewed by Graal developers.
>>>>>> Changes like this one can be reviewed by anyone in the HotSpot
>>>>>> compiler team or Graal team.
>>>>> That's good to know.? The change is obviously correct, but it needs to
>>>>> be handled correctly.
>>>> Right. The GitHub Graal code base needs to work from JDK 8 (with a JVMCI patch) onwards. We have just recently
>>>> switched to using multi-release jars to make this process saner and avoid the use of reflection to access version
>>>> dependent API. When GitHub Graal snapshots are taken for syncing the code into OpenJDK, the versioned directories
>>>> are flattened to the non-versioned root directory following the same logic that would be applied when resolving a
>>>> versioned class at runtime. The flattenmultireleasesources command[1] was added to mx to facilitate this flattening.
>>>>
>>>> The particular change in this webrev is a good opportunity to make GraalHotSpotVMConfig versioned in this way. I'll
>>>> make the necessary changes for this in GitHub Graal. Normally, no manual change should be made to OpenJDK Graal but
>>>> in this case I think it's necessary so that OpenJDK testing of Graal won't break.
>>>>
>>>>> For my information, though, I presume "changes like this" means simple
>>>>> changes to JVMCI.? That right?
>>>> Sorry for my ambiguity. I meant that this is a simple change to both JVMCI and Graal and by now most HotSpot
>>>> compiler developers should be able to review it. Of course, having a Graal developer look at it as well is
>>>> recommended. The preferred way to do this is to open a PR at https://github.com/graalvm/mx/pulls.
>>>>
>>>> -Doug
>>>>
>>>> [1] https://github.com/graalvm/mx/commit/bad56c1101db758c3f8c6560fc62012c15be39e4
>>>>
>>>>> --
>>>>> Andrew Haley
>>>>> Java Platform Lead Engineer
>>>>> Red Hat UK Ltd.
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=4ZggofCo53X0nV2fk4nYuyBqw3xG4MZTeRDFqVH-pnI&s=4mmTmtLnlPEwCZErTwYIz3N2z1cw2_X5GqZs0GCBYA8&e=>
>>>>>
>>>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>>>
>
From aph at redhat.com Thu Apr 19 17:12:21 2018
From: aph at redhat.com (Andrew Haley)
Date: Thu, 19 Apr 2018 18:12:21 +0100
Subject: RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific
data belonging to a thread
In-Reply-To: <286706d9-7c0f-4c18-66b3-3834f22ea8f5@oracle.com>
References: <56feb039-7379-ca03-28f7-69826a351dc6@oracle.com>
<978ac809-21b0-c933-4283-3473c2a60866@oracle.com>
<1e72a3a4-9540-6d66-709b-c017e1137595@oracle.com>
<f1c9b155-7f06-262c-98f6-f0d3d3b025b6@redhat.com>
<d583942c-7151-d783-14cd-658b6295203a@oracle.com>
<cf5e6638-443e-1243-96f8-599d8950c1af@redhat.com>
<F3231CFC-7B66-4BB1-B911-95AD3B2C0A83@oracle.com>
<4616d0a8-61b0-a369-61cc-e4c82c39539e@redhat.com>
<19F3CB79-99F3-4288-AAB4-7E54D8828837@oracle.com>
<c2604b75-10ea-ceec-b381-fc11b3eb3f0a@oracle.com>
<37884cc1-38d9-945d-b552-36d213677efc@oracle.com>
<a35ee91b-7fce-7deb-cf32-d3895526b3e2@oracle.com>
<286706d9-7c0f-4c18-66b3-3834f22ea8f5@oracle.com>
Message-ID: <f2bfae87-939c-370e-43b8-1777ae776c1e@redhat.com>
On 04/19/2018 04:59 PM, Vladimir Kozlov wrote:
> Changes should be pushed upstream before next "Graal update" pushed into OpenJDK. Changes could be modified after review
> - it is fine since we overwrite Graal code in OpenJDK anyway with each sync.
Yes, absolutely, and it must be done in a quick manner for changes that
break Graal. Pretty please. :-)
It does have the unfortunate(?) effect of enforcing some synchronization
between Graal and HotSpot.
> I think this will happen not frequently and we can handle it.
Hmmm. It's nice to hope!
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From david.holmes at oracle.com Fri Apr 20 01:38:59 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Apr 2018 11:38:59 +1000
Subject: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
In-Reply-To: <914df27d59224c8b90126aec2ac333fb@sap.com>
References: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
<CAA-vtUz48xUdXQzDEAuS2JDdnis7n2pAjfJ52dgFkhKskNoX9Q@mail.gmail.com>
<b65af851-d138-42b2-847a-fd6650a1767b@oracle.com>
<CAA-vtUz+cyza6GOnVN7p-9XJ-JYo_vBozMNh0K=7woUbV4mKzA@mail.gmail.com>
<b0fcb60f-ff76-9b98-871c-8692f4504442@oracle.com>
<43ae45216d3545518b274dd7246d7862@sap.com>
<4dcc535e-4906-05a8-0636-65191f8a8695@oracle.com>
<5fc75353a1a74c22a0c24e2bdfc2d05b@sap.com>
<CAA-vtUyKJ4dXw7RS+CvTkKj5j0R+UB-4_pwpHqDExKCYGR8vhQ@mail.gmail.com>
<d8b60482-35a8-304a-9a4d-3c0e37b0e0cc@oracle.com>
<b623fc51e0d647888f641c62e4e16656@sap.com>
<CAA-vtUzcazFtehWh3zOxHk-CSmazD7XLEF3CMrQ3_A0AaoXJrw@mail.gmail.com>
<8dfc9463054f485ab5ca9bc8fee00c3e@sap.com>
<ddb4644a-9977-a471-6e41-69572793d08c@oracle.com>
<914df27d59224c8b90126aec2ac333fb@sap.com>
Message-ID: <18c823a6-62be-0e04-b87d-d93e2103ce65@oracle.com>
Hi Christoph,
I managed to find some time to dig deeper ...
On 19/04/2018 11:55 PM, Langer, Christoph wrote:
> Hi,
>
> with my means of searching in the public OpenJDK repositories I can only find that 'call_jio_print' has always been there. No idea about the backgrounds of why we need this buffer copy approach instead of using jio_printf directly.
Some relatively recent history:
https://bugs.openjdk.java.net/browse/JDK-6518269
The real history:
- April 2000: jio_print was introduced to "Make print more reliable
inside signal handler." It was actually a conversion from a character
version:
// HotSpot specific jio method
void jio_putchar(int c) {
if (Arguments::vfprintf_hook() != NULL) {
jio_fprintf(stdout, "%c", c);
} else {
putchar(c);
}
}
to the current string version. That's what the 'atomic' reference is
about - printing the entire string instead of char-by-char which could
lead to interspersing.
- The putchar version was added in Jun 1999.
From what I can see the putchar version either went the jio_fprintf
path if the hook was installed else a raw pucthar. The string version
then followed suit.
With that in mind I don't think the "raw write" has any significance.
So this is Reviewed.
Thanks,
David
-----
>
> So, can someone else please help reviewing http://cr.openjdk.java.net/~clanger/webrevs/8201649.0/ ?
>
> Thanks
> Christoph
>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Donnerstag, 19. April 2018 14:07
>> To: Langer, Christoph <christoph.langer at sap.com>; Thomas St?fe
>> <thomas.stuefe at gmail.com>
>> Cc: daniel.daugherty at oracle.com; hotspot-dev at openjdk.java.net; hotspot-
>> runtime-dev at openjdk.java.net
>> Subject: Re: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
>>
>> Hi Christoph,
>>
>> On 19/04/2018 9:08 PM, Langer, Christoph wrote:
>>> Hi Thomas, David,
>>>
>>>>> @David: No, I don't think it needs to be dialed back at this point, but I
>>>> agree, the bug should be updated somewhat to the current scope by
>>>> mentioning that the goal is to get rid of jio_print and jio_printf completely
>>>> (along with call_jio_print in ostream.cpp). Those 2 functions were just 2
>>>> hooks used in ostream.cpp and got routed through jio_vfprintf anyway,
>>>> except for the raw write case when no vfprint_hook was installed - and
>> we'll
>>>> preserve that.
>>
>> You preserved it in the sense it's still there, but you changed two call
>> sites so they can never now hit it. So I'm back to the unanswerable
>> "does that matter?".
>>
>> Unless someone can do the archaeology on this I'm going to have to abstain.
>>
>> David
>> -----
>>
>>>>>
>>>>
>>>> Hm. Instead of broading the scope of the issue, I would actually
>>>> prefer the bug description to be clarified and limited to the original
>>>> problem we tried to solve. Because that was a real valid problem.
>>>>
>>>> If only to get David's full review and not to confuse him further :)
>>>
>>> Ok, I agree. So I tried to clarify the bug a bit more in its original sense. And
>> we'd be back to webrev #0.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201649
>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201649.0/
>>>
>>> The change of the webrev is missing a cast in line 2729 - (len needs to be
>> casted int). This produces a build warning which turns into an error in some
>> platforms. I'll have that fixed in the submitted version.
>>>
>>> For the further cleanup of jio_print methods I'll probably file another bug.
>>>
>>> As I think we already had a principal agreement about this proposal earlier,
>> I would consider this reviewed by stuefe and dholmes if I don't hear back
>> from you today. I would push this tomorrow after push to jdk-submit and
>> further internal testing here at SAP.
>>>
>>> Thanks
>>> Christoph
>>>
From christoph.langer at sap.com Fri Apr 20 07:33:49 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 20 Apr 2018 07:33:49 +0000
Subject: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
In-Reply-To: <18c823a6-62be-0e04-b87d-d93e2103ce65@oracle.com>
References: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
<CAA-vtUz48xUdXQzDEAuS2JDdnis7n2pAjfJ52dgFkhKskNoX9Q@mail.gmail.com>
<b65af851-d138-42b2-847a-fd6650a1767b@oracle.com>
<CAA-vtUz+cyza6GOnVN7p-9XJ-JYo_vBozMNh0K=7woUbV4mKzA@mail.gmail.com>
<b0fcb60f-ff76-9b98-871c-8692f4504442@oracle.com>
<43ae45216d3545518b274dd7246d7862@sap.com>
<4dcc535e-4906-05a8-0636-65191f8a8695@oracle.com>
<5fc75353a1a74c22a0c24e2bdfc2d05b@sap.com>
<CAA-vtUyKJ4dXw7RS+CvTkKj5j0R+UB-4_pwpHqDExKCYGR8vhQ@mail.gmail.com>
<d8b60482-35a8-304a-9a4d-3c0e37b0e0cc@oracle.com>
<b623fc51e0d647888f641c62e4e16656@sap.com>
<CAA-vtUzcazFtehWh3zOxHk-CSmazD7XLEF3CMrQ3_A0AaoXJrw@mail.gmail.com>
<8dfc9463054f485ab5ca9bc8fee00c3e@sap.com>
<ddb4644a-9977-a471-6e41-69572793d08c@oracle.com>
<914df27d59224c8b90126aec2ac333fb@sap.com>
<18c823a6-62be-0e04-b87d-d93e2103ce65@oracle.com>
Message-ID: <7a9a5a8b61b94299bc49b4f3edf521e6@sap.com>
Hi David,
thanks a lot for taking this deep dive - somebody outside Oracle would not have access to this information. So I am glad that we understand the backgrounds better now.
The patch is running through jdk/submit currently, will push if everything runs fine. Our internal testing did not show regressions.
One question, as I'm planning to finish my work on this with another item to clean up the jio_*print* functions: You think that the raw write could be replaced with a call to vfprintf under this circumstances? Shouldn't the risk of interspersing characters be higher with vfprintf compared to raw write?
Best regards
Christoph
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Freitag, 20. April 2018 03:39
> To: Langer, Christoph <christoph.langer at sap.com>; hotspot-
> dev at openjdk.java.net
> Cc: daniel.daugherty at oracle.com; hotspot-runtime-dev at openjdk.java.net;
> Thomas St?fe <thomas.stuefe at gmail.com>
> Subject: Re: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
>
> Hi Christoph,
>
> I managed to find some time to dig deeper ...
>
> On 19/04/2018 11:55 PM, Langer, Christoph wrote:
> > Hi,
> >
> > with my means of searching in the public OpenJDK repositories I can only
> find that 'call_jio_print' has always been there. No idea about the
> backgrounds of why we need this buffer copy approach instead of using
> jio_printf directly.
>
> Some relatively recent history:
>
> https://bugs.openjdk.java.net/browse/JDK-6518269
>
> The real history:
>
> - April 2000: jio_print was introduced to "Make print more reliable
> inside signal handler." It was actually a conversion from a character
> version:
>
> // HotSpot specific jio method
> void jio_putchar(int c) {
> if (Arguments::vfprintf_hook() != NULL) {
> jio_fprintf(stdout, "%c", c);
> } else {
> putchar(c);
> }
> }
>
> to the current string version. That's what the 'atomic' reference is
> about - printing the entire string instead of char-by-char which could
> lead to interspersing.
>
> - The putchar version was added in Jun 1999.
>
> From what I can see the putchar version either went the jio_fprintf
> path if the hook was installed else a raw pucthar. The string version
> then followed suit.
>
> With that in mind I don't think the "raw write" has any significance.
>
> So this is Reviewed.
>
> Thanks,
> David
> -----
>
> >
> > So, can someone else please help reviewing
> http://cr.openjdk.java.net/~clanger/webrevs/8201649.0/ ?
> >
> > Thanks
> > Christoph
> >
> >> -----Original Message-----
> >> From: David Holmes [mailto:david.holmes at oracle.com]
> >> Sent: Donnerstag, 19. April 2018 14:07
> >> To: Langer, Christoph <christoph.langer at sap.com>; Thomas St?fe
> >> <thomas.stuefe at gmail.com>
> >> Cc: daniel.daugherty at oracle.com; hotspot-dev at openjdk.java.net;
> hotspot-
> >> runtime-dev at openjdk.java.net
> >> Subject: Re: RFR(S): 8201649: Remove dubious call_jio_print in
> ostream.cpp
> >>
> >> Hi Christoph,
> >>
> >> On 19/04/2018 9:08 PM, Langer, Christoph wrote:
> >>> Hi Thomas, David,
> >>>
> >>>>> @David: No, I don't think it needs to be dialed back at this point, but I
> >>>> agree, the bug should be updated somewhat to the current scope by
> >>>> mentioning that the goal is to get rid of jio_print and jio_printf
> completely
> >>>> (along with call_jio_print in ostream.cpp). Those 2 functions were just 2
> >>>> hooks used in ostream.cpp and got routed through jio_vfprintf
> anyway,
> >>>> except for the raw write case when no vfprint_hook was installed - and
> >> we'll
> >>>> preserve that.
> >>
> >> You preserved it in the sense it's still there, but you changed two call
> >> sites so they can never now hit it. So I'm back to the unanswerable
> >> "does that matter?".
> >>
> >> Unless someone can do the archaeology on this I'm going to have to
> abstain.
> >>
> >> David
> >> -----
> >>
> >>>>>
> >>>>
> >>>> Hm. Instead of broading the scope of the issue, I would actually
> >>>> prefer the bug description to be clarified and limited to the original
> >>>> problem we tried to solve. Because that was a real valid problem.
> >>>>
> >>>> If only to get David's full review and not to confuse him further :)
> >>>
> >>> Ok, I agree. So I tried to clarify the bug a bit more in its original sense.
> And
> >> we'd be back to webrev #0.
> >>>
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201649
> >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201649.0/
> >>>
> >>> The change of the webrev is missing a cast in line 2729 - (len needs to be
> >> casted int). This produces a build warning which turns into an error in
> some
> >> platforms. I'll have that fixed in the submitted version.
> >>>
> >>> For the further cleanup of jio_print methods I'll probably file another
> bug.
> >>>
> >>> As I think we already had a principal agreement about this proposal
> earlier,
> >> I would consider this reviewed by stuefe and dholmes if I don't hear back
> >> from you today. I would push this tomorrow after push to jdk-submit and
> >> further internal testing here at SAP.
> >>>
> >>> Thanks
> >>> Christoph
> >>>
From david.holmes at oracle.com Fri Apr 20 08:00:31 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Apr 2018 18:00:31 +1000
Subject: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
In-Reply-To: <7a9a5a8b61b94299bc49b4f3edf521e6@sap.com>
References: <fd6299f6e7ad445d8939d915ef0ed403@sap.com>
<CAA-vtUz48xUdXQzDEAuS2JDdnis7n2pAjfJ52dgFkhKskNoX9Q@mail.gmail.com>
<b65af851-d138-42b2-847a-fd6650a1767b@oracle.com>
<CAA-vtUz+cyza6GOnVN7p-9XJ-JYo_vBozMNh0K=7woUbV4mKzA@mail.gmail.com>
<b0fcb60f-ff76-9b98-871c-8692f4504442@oracle.com>
<43ae45216d3545518b274dd7246d7862@sap.com>
<4dcc535e-4906-05a8-0636-65191f8a8695@oracle.com>
<5fc75353a1a74c22a0c24e2bdfc2d05b@sap.com>
<CAA-vtUyKJ4dXw7RS+CvTkKj5j0R+UB-4_pwpHqDExKCYGR8vhQ@mail.gmail.com>
<d8b60482-35a8-304a-9a4d-3c0e37b0e0cc@oracle.com>
<b623fc51e0d647888f641c62e4e16656@sap.com>
<CAA-vtUzcazFtehWh3zOxHk-CSmazD7XLEF3CMrQ3_A0AaoXJrw@mail.gmail.com>
<8dfc9463054f485ab5ca9bc8fee00c3e@sap.com>
<ddb4644a-9977-a471-6e41-69572793d08c@oracle.com>
<914df27d59224c8b90126aec2ac333fb@sap.com>
<18c823a6-62be-0e04-b87d-d93e2103ce65@oracle.com>
<7a9a5a8b61b94299bc49b4f3edf521e6@sap.com>
Message-ID: <3f6ffe14-d6b2-0365-dae9-7f920ca023a9@oracle.com>
On 20/04/2018 5:33 PM, Langer, Christoph wrote:
> Hi David,
>
> thanks a lot for taking this deep dive - somebody outside Oracle would not have access to this information. So I am glad that we understand the backgrounds better now.
I was just hoping it would be someone else inside Oracle :)
>
> The patch is running through jdk/submit currently, will push if everything runs fine. Our internal testing did not show regressions.
>
> One question, as I'm planning to finish my work on this with another item to clean up the jio_*print* functions: You think that the raw write could be replaced with a call to vfprintf under this circumstances? Shouldn't the risk of interspersing characters be higher with vfprintf compared to raw write?
I would expect vfprintf to expand everything before itself doing a write
to the underlying stream ... but I haven't looked at the details of the
stream implementation. The interspersing, actually I should have said
interleaving, was an issue of using putchar rather than write.
I don't think it will make a difference if we only use the vprintf.
David
> Best regards
> Christoph
>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Freitag, 20. April 2018 03:39
>> To: Langer, Christoph <christoph.langer at sap.com>; hotspot-
>> dev at openjdk.java.net
>> Cc: daniel.daugherty at oracle.com; hotspot-runtime-dev at openjdk.java.net;
>> Thomas St?fe <thomas.stuefe at gmail.com>
>> Subject: Re: RFR(S): 8201649: Remove dubious call_jio_print in ostream.cpp
>>
>> Hi Christoph,
>>
>> I managed to find some time to dig deeper ...
>>
>> On 19/04/2018 11:55 PM, Langer, Christoph wrote:
>>> Hi,
>>>
>>> with my means of searching in the public OpenJDK repositories I can only
>> find that 'call_jio_print' has always been there. No idea about the
>> backgrounds of why we need this buffer copy approach instead of using
>> jio_printf directly.
>>
>> Some relatively recent history:
>>
>> https://bugs.openjdk.java.net/browse/JDK-6518269
>>
>> The real history:
>>
>> - April 2000: jio_print was introduced to "Make print more reliable
>> inside signal handler." It was actually a conversion from a character
>> version:
>>
>> // HotSpot specific jio method
>> void jio_putchar(int c) {
>> if (Arguments::vfprintf_hook() != NULL) {
>> jio_fprintf(stdout, "%c", c);
>> } else {
>> putchar(c);
>> }
>> }
>>
>> to the current string version. That's what the 'atomic' reference is
>> about - printing the entire string instead of char-by-char which could
>> lead to interspersing.
>>
>> - The putchar version was added in Jun 1999.
>>
>> From what I can see the putchar version either went the jio_fprintf
>> path if the hook was installed else a raw pucthar. The string version
>> then followed suit.
>>
>> With that in mind I don't think the "raw write" has any significance.
>>
>> So this is Reviewed.
>>
>> Thanks,
>> David
>> -----
>>
>>>
>>> So, can someone else please help reviewing
>> http://cr.openjdk.java.net/~clanger/webrevs/8201649.0/ ?
>>>
>>> Thanks
>>> Christoph
>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Donnerstag, 19. April 2018 14:07
>>>> To: Langer, Christoph <christoph.langer at sap.com>; Thomas St?fe
>>>> <thomas.stuefe at gmail.com>
>>>> Cc: daniel.daugherty at oracle.com; hotspot-dev at openjdk.java.net;
>> hotspot-
>>>> runtime-dev at openjdk.java.net
>>>> Subject: Re: RFR(S): 8201649: Remove dubious call_jio_print in
>> ostream.cpp
>>>>
>>>> Hi Christoph,
>>>>
>>>> On 19/04/2018 9:08 PM, Langer, Christoph wrote:
>>>>> Hi Thomas, David,
>>>>>
>>>>>>> @David: No, I don't think it needs to be dialed back at this point, but I
>>>>>> agree, the bug should be updated somewhat to the current scope by
>>>>>> mentioning that the goal is to get rid of jio_print and jio_printf
>> completely
>>>>>> (along with call_jio_print in ostream.cpp). Those 2 functions were just 2
>>>>>> hooks used in ostream.cpp and got routed through jio_vfprintf
>> anyway,
>>>>>> except for the raw write case when no vfprint_hook was installed - and
>>>> we'll
>>>>>> preserve that.
>>>>
>>>> You preserved it in the sense it's still there, but you changed two call
>>>> sites so they can never now hit it. So I'm back to the unanswerable
>>>> "does that matter?".
>>>>
>>>> Unless someone can do the archaeology on this I'm going to have to
>> abstain.
>>>>
>>>> David
>>>> -----
>>>>
>>>>>>>
>>>>>>
>>>>>> Hm. Instead of broading the scope of the issue, I would actually
>>>>>> prefer the bug description to be clarified and limited to the original
>>>>>> problem we tried to solve. Because that was a real valid problem.
>>>>>>
>>>>>> If only to get David's full review and not to confuse him further :)
>>>>>
>>>>> Ok, I agree. So I tried to clarify the bug a bit more in its original sense.
>> And
>>>> we'd be back to webrev #0.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201649
>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201649.0/
>>>>>
>>>>> The change of the webrev is missing a cast in line 2729 - (len needs to be
>>>> casted int). This produces a build warning which turns into an error in
>> some
>>>> platforms. I'll have that fixed in the submitted version.
>>>>>
>>>>> For the further cleanup of jio_print methods I'll probably file another
>> bug.
>>>>>
>>>>> As I think we already had a principal agreement about this proposal
>> earlier,
>>>> I would consider this reviewed by stuefe and dholmes if I don't hear back
>>>> from you today. I would push this tomorrow after push to jdk-submit and
>>>> further internal testing here at SAP.
>>>>>
>>>>> Thanks
>>>>> Christoph
>>>>>
From erik.osterlund at oracle.com Fri Apr 20 13:49:23 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Fri, 20 Apr 2018 15:49:23 +0200
Subject: RFR: 8201543: Modularize C1 GC barriers
In-Reply-To: <5AD0C89E.7050807@oracle.com>
References: <5AD0C89E.7050807@oracle.com>
Message-ID: <5AD9EFE3.4020203@oracle.com>
Hi everyone,
I sat down with Rickard and Per at the office to have a look at this,
and have built a new webrev based on their feedback.
The main elements in the delta are the following:
1) Wrap various context information that is passed around in the
BarrierSetC1 hierarchy in a wrapper object (to reduce boiler plate),
that has been named LIRAccess. It contains the address elements (base
and offset, as either LIRItem or LIROpr), as well as the decorators, and
the CodeEmitInfo of the address (for patching), the CodeEmitInfo for the
access (for things like implicit null checks), and the LIRGenerator
instance, that would normally be passed around to every function.
2) Added #ifdef COMPILER1 in the G1BarrierSetC1 classes to be polite to
people trying to build HotSpot with a generated interpreter but no C1
compiler.
3) Added a decorator_fixup() method that applies various implicit
decorator rules for sane defaults (for example, IN_HEAP_ARRAY implies
IN_HEAP). This is a 1:1 mirror to the DecoratorFixup meta function used
in the runtime backend. Both are now located in accessDecorator.hpp. One
for use by templates (DecoratorFixup), and one for use by code
generators that do not use templates (decorator_fixup()).
4) Removed some unnecessary includes and friend class declarations.
5) Made BarrierSetC1 a member of LIRGenerator to reduce boiler plate
further.
6) Changed name of the lir_generator variable passed around to gen, to
be consistent with what other code in C1 does when passing around the
LIRGenerator instance.
Incremental webrev:
http://cr.openjdk.java.net/~eosterlund/8201543/webrev.00_01/
Full webrev:
http://cr.openjdk.java.net/~eosterlund/8201543/webrev.01/
Big thanks to Rickard and Per for having a look at this.
Thanks,
/Erik
On 2018-04-13 17:11, Erik ?sterlund wrote:
> Hi,
>
> The GC barriers for C1 are not as modular as they could be. It
> currently uses switch statements to check which GC barrier set is
> being used, and calls one or another barrier based on that, in a way
> that it can only be used for write barriers.
>
> The solution I propose is to add the same facilities that have been
> added in runtime and the interpreter already: a barrier set backend
> for C1. I call it BarrierSetC1, and it helps us generate decorated
> accesses that give the GC control over the details how to generate
> this access. It recognizes the same decorators (accessDecorators.hpp)
> that the other parts of the VM recognize. Each concrete barrier set
> has its own backend. For now, these are CardTableBarrierSetC1 and
> G1BarrierSetC1, but this should pave way for upcoming concurrently
> compacting GCs as well.
>
> Two decorators were added for C1 specifically (found in
> c1_Decorators.hpp):
> C1_NEEDS_PATCHING for accesses where the index is not yet load because
> the class has yet to be loaded, and
> C1_MASK_BOOLEAN for accesses that need to mask untrusted boolean values.
>
> LIRGenerator calls a wrapper called access_store_at, access_load_at,
> etc (there are variants for cpmxchg, xchg and atomic add as well).
> The access call calls straight into the BarrierSetC1 hierarchy using
> virtual calls. It is structured in a way very similar to
> BarrierSetAssembler.
>
> BarrierSetC1 can also be called during initialization to generate
> stubs and runtime methods required by C1. For G1BarrierSetC1, this
> results in calling the BarrierSetAssembler for the platform specific
> code. This way, the BarrierSetC1 hierarchy has been carefully kept in
> shared code, and the switch statements for generating G1 code have
> been removed. Some code that used to be platform specific (like unsafe
> get/set and array store) have been broken out to shared code, with the
> actual platform specific details (some register allocation for store
> check and atomics) broken out to platform specific methods. This way,
> calls to access are kept in platform specific code.
>
> As usual, big thanks go to Martin Doerr for helping out with S390 and
> PPC, and Roman for taking care of AArch64.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8201543
>
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.00/
>
> Thanks,
> /Erik
From erik.osterlund at oracle.com Fri Apr 20 14:43:32 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Fri, 20 Apr 2018 16:43:32 +0200
Subject: RFR: 8202082: Remove explicit CMS checks in
CardTableBarrierSetAssembler
Message-ID: <5AD9FC94.70607@oracle.com>
Hi,
In CardTableBarrierSetAssembler, we sometimes need fencing due to the
card table being scanned concurrently when using CMS with pre-cleaning.
Rather than explicitly checking for those CMS flags in the generic
CardTableBarrierSetAssembler class, it is preferrable to check the
CardTable scanned_concurrently() property which already precisely
reflects that.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8202082
Webrev:
http://cr.openjdk.java.net/~eosterlund/8202082/webrev.00/
Thanks,
/Erik
From gnu.andrew at redhat.com Sat Apr 21 14:50:31 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Sat, 21 Apr 2018 15:50:31 +0100
Subject: RFR: build pragma error with gcc 4.4.7
In-Reply-To: <2dd2d37c-e0d7-ad13-6da6-92196ab6749d@oracle.com>
References: <3196d61c-9b7c-b795-a68d-6e50a3416f41@redhat.com>
<2dd2d37c-e0d7-ad13-6da6-92196ab6749d@oracle.com>
Message-ID: <CABi63P5EqTZ5dRsgzE32nbKTHE37ocDrM02oLqyH-KSFuB6fHA@mail.gmail.com>
On 16 March 2018 at 11:05, David Holmes <david.holmes at oracle.com> wrote:
> Hi Michal,
>
> On 16/03/2018 8:48 PM, Michal Vala wrote:
>>
>> Hi,
>>
>> I've been trying to build latest jdk with gcc 4.4.7 and I hit compile
>> error due to pragma used in function:
>
>
> That's a very old gcc. Our "official" version is 4.9.2 but we're working on
> getting gcc 7.x working as well. This code causes no problem on 4.9.2+ so to
> make any change we'd have to know it will continue to work on later
> versions.
>
> Also a google search indicates the "pragma diagnostic push" and pop weren't
> added until gcc 4.6 ??
>
> David
> -----
>
That's why PRAGMA_DIAG_PUSH/POP were defined by:
https://bugs.openjdk.java.net/browse/JDK-8037816
The mistake was in:
https://bugs.openjdk.java.net/browse/JDK-8187667
using the pragma directly, rather than via the define as elsewhere
in the codebase.
$ grep -r 'PRAGMA_DIAG_PUSH' jdk/src/hotspot/
jdk/src/hotspot/share/code/compressedStream.cpp:PRAGMA_DIAG_PUSH
jdk/src/hotspot/share/code/codeCache.cpp:PRAGMA_DIAG_PUSH
jdk/src/hotspot/share/utilities/compilerWarnings.hpp:#define
PRAGMA_DIAG_PUSH _Pragma("GCC diagnostic push")
jdk/src/hotspot/share/utilities/compilerWarnings.hpp:#ifndef PRAGMA_DIAG_PUSH
jdk/src/hotspot/share/utilities/compilerWarnings.hpp:#define PRAGMA_DIAG_PUSH
jdk/src/hotspot/share/utilities/xmlstream.cpp:PRAGMA_DIAG_PUSH
jdk/src/hotspot/share/classfile/classFileError.cpp:PRAGMA_DIAG_PUSH
jdk/src/hotspot/share/classfile/classFileParser.cpp:PRAGMA_DIAG_PUSH
jdk/src/hotspot/share/jvmci/jvmciRuntime.cpp:PRAGMA_DIAG_PUSH
jdk/src/hotspot/share/jvmci/jvmciRuntime.cpp:PRAGMA_DIAG_PUSH
jdk/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp:PRAGMA_DIAG_PUSH
jdk/src/hotspot/os/linux/osContainer_linux.cpp:PRAGMA_DIAG_PUSH
--
Andrew :)
Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
From gnu.andrew at redhat.com Sat Apr 21 15:18:48 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Sat, 21 Apr 2018 16:18:48 +0100
Subject: RFR: build pragma error with gcc 4.4.7
In-Reply-To: <01173273-2A13-4FE0-81EE-3C50954D7A90@oracle.com>
References: <3196d61c-9b7c-b795-a68d-6e50a3416f41@redhat.com>
<01173273-2A13-4FE0-81EE-3C50954D7A90@oracle.com>
Message-ID: <CABi63P5FPbfdw9jynsKHa+i7=T1kaSJsyEC7tZ6eW0pZZx8Tbg@mail.gmail.com>
On 19 March 2018 at 23:23, Kim Barrett <kim.barrett at oracle.com> wrote:
>> On Mar 16, 2018, at 6:48 AM, Michal Vala <mvala at redhat.com> wrote:
>>
>> Hi,
>>
>> I've been trying to build latest jdk with gcc 4.4.7 and I hit compile error due to pragma used in function:
>>
>> /mnt/ramdisk/openjdk/src/hotspot/os/linux/os_linux.inline.hpp:103: error: #pragma GCC diagnostic not allowed inside functions
>>
>>
>> I'm sending little patch that fixes the issue by wrapping whole function. I've also created a macro for ignoring deprecated declaration inside compilerWarnings.hpp to line up with others.
>>
>> Can someone please review? If it's ok, I would also need a sponsor.
>>
>>
>> diff -r 422615764e12 src/hotspot/os/linux/os_linux.inline.hpp
>> --- a/src/hotspot/os/linux/os_linux.inline.hpp Thu Mar 15 14:54:10 2018 -0700
>> +++ b/src/hotspot/os/linux/os_linux.inline.hpp Fri Mar 16 10:50:24 2018 +0100
>> @@ -96,13 +96,12 @@
>> return ::ftruncate64(fd, length);
>> }
>>
>> -inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf)
>> -{
>> // readdir_r has been deprecated since glibc 2.24.
>> // See https://sourceware.org/bugzilla/show_bug.cgi?id=19056 for more details.
>> -#pragma GCC diagnostic push
>> -#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
>> -
>> +PRAGMA_DIAG_PUSH
>> +PRAGMA_DEPRECATED_IGNORED
>> +inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf)
>> +{
>> dirent* p;
>> int status;
>> assert(dirp != NULL, "just checking");
>> @@ -114,11 +113,11 @@
>> if((status = ::readdir_r(dirp, dbuf, &p)) != 0) {
>> errno = status;
>> return NULL;
>> - } else
>> + } else {
>> return p;
>> -
>> -#pragma GCC diagnostic pop
>> + }
>> }
>> +PRAGMA_DIAG_POP
>>
>> inline int os::closedir(DIR *dirp) {
>> assert(dirp != NULL, "argument is NULL");
>> diff -r 422615764e12 src/hotspot/share/utilities/compilerWarnings.hpp
>> --- a/src/hotspot/share/utilities/compilerWarnings.hpp Thu Mar 15 14:54:10 2018 -0700
>> +++ b/src/hotspot/share/utilities/compilerWarnings.hpp Fri Mar 16 10:50:24 2018 +0100
>> @@ -48,6 +48,7 @@
>> #define PRAGMA_FORMAT_NONLITERAL_IGNORED _Pragma("GCC diagnostic ignored \"-Wformat-nonliteral\"") \
>> _Pragma("GCC diagnostic ignored \"-Wformat-security\"")
>> #define PRAGMA_FORMAT_IGNORED _Pragma("GCC diagnostic ignored \"-Wformat\"")
>> +#define PRAGMA_DEPRECATED_IGNORED _Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"")
>>
>> #if defined(__clang_major__) && \
>> (__clang_major__ >= 4 || \
>>
>>
>> Thanks!
>>
>> --
>> Michal Vala
>> OpenJDK QE
>> Red Hat Czech
>
> Given that there seem to be no callers of os::readdir that share the
> DIR* among multiple threads, it would seem easier to just replace the
> use of ::readdir_r with ::readdir. That seems to be the intent in the
> deprecation decision; use ::readdir, and either don't share a DIR*
> among threads, or use external locking when doing so.
>
That was my analysis when I looked at this as well. Something as simple as:
diff --git a/src/os/linux/vm/os_linux.inline.hpp
b/src/os/linux/vm/os_linux.inline.hpp
--- a/src/os/linux/vm/os_linux.inline.hpp
+++ b/src/os/linux/vm/os_linux.inline.hpp
@@ -116,19 +116,9 @@
inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf)
{
- dirent* p;
- int status;
assert(dirp != NULL, "just checking");
- // NOTE: Linux readdir_r (on RH 6.2 and 7.2 at least) is NOT like the POSIX
- // version. Here is the doc for this function:
- // http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_262.html
-
- if((status = ::readdir_r(dirp, dbuf, &p)) != 0) {
- errno = status;
- return NULL;
- } else
- return p;
+ return ::readdir(dirp);
}
inline int os::closedir(DIR *dirp) {
has been working fine for me locally for a while. I believe Michal is going to
post an updated version of that, along with some cleanup of dbuf usage
in Linux-only code (as dbuf is now unused).
However, I wouldn't suggest backporting such a change to older JDKs.
There, we should backport the changeset to mute it, updating it to
work with older compilers. I already did so in OpenJDK 7.
> There are also problems with the patch as provided.
>
> (1) Since PRAGMA_DIAG_PUSH/POP do nothing in the version of gcc this
> change is being made in support of, the warning would be disabled for
> all following code in any translation unit that includes this file.
> That doesn't seem good.
No, but it's really the only solution on those compilers. We have such
usage already elsewhere e.g.
// Silence -Wformat-security warning for fatal()
PRAGMA_DIAG_PUSH
PRAGMA_FORMAT_NONLITERAL_IGNORED
fatal(buf);
PRAGMA_DIAG_POP
return true; // silence compiler warnings
}
in src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp
If there are other warnings, then they will picked up on newer compilers,
especially when building with -Werror. I don't think it's likely people are
doing development on older compilers, but rather that we have to use
them to build for older platforms.
This isn't the first time I've encountered something which built fine locally,
and then failed when building on an old version of RHEL, and I suspect
it won't be the last.
>
> (2) The default empty definition for PRAGMA_DEPRECATED_IGNORED is
> missing. That means the macro can't be used in shared code, in which
> case having defined in (shared) compilerWarnings.hpp is questionable.
>
Yes, I don't see the need to change that line (other than for consistency)
and didn't when I made the same change in 7:
http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/2a2721def4a0#l7.2
--
Andrew :)
Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
From dms at samersoff.net Sun Apr 22 10:11:37 2018
From: dms at samersoff.net (Dmitry Samersoff)
Date: Sun, 22 Apr 2018 13:11:37 +0300
Subject: JEP 328 : Flight Recorder open source preview
In-Reply-To: <98495f12-6074-4ff6-5080-8cf601ce7367@samersoff.net>
References: <687dbe1f-80dc-46ff-9f9f-da03687322e6@default>
<98495f12-6074-4ff6-5080-8cf601ce7367@samersoff.net>
Message-ID: <4065cba9-b1dc-baa1-3e48-67e0cd33d734@samersoff.net>
Markus,
1. I attached small patch that allows me to compile hotspot with jfr.
It includes changes suggested by Erik and few other ones.
2. It seems to me that something goes wrong with recording of full stack
trace on AArch64.
*All advices of debugging this issue are much appreciated. What place in
JFR code is responsible for stacktrace recording?*
These two tests are failing
jdk/jfr/api/consumer/TestRecordedFullStackTrace.java:
jdk/jfr/event/profiling/TestFullStackTrace.java:
with:
java.lang.RuntimeException: Wrong stacktrace depth. Expected:63:
expected 63 to equal 3
at jdk.test.lib.Asserts.fail(Asserts.java:594)
at jdk.test.lib.Asserts.assertEquals(Asserts.java:205)
at
jdk.jfr.api.consumer.TestRecordedFullStackTrace.checkEvent(TestRecordedFullStackTrace.java:142)
at
jdk.jfr.api.consumer.TestRecordedFullStackTrace.hasValidStackTraces(TestRecordedFullStackTrace.java:109)
at
jdk.jfr.api.consumer.TestRecordedFullStackTrace.assertStackTraces(TestRecordedFullStackTrace.java:91)
at
jdk.jfr.api.consumer.TestRecordedFullStackTrace.main(TestRecordedFullStackTrace.java:70)
-Dmitry
On 04/15/2018 03:34 PM, Dmitry Samersoff wrote:
> Hi Markus,
>
> I'm trying to compile the patch but get following errors:
>
> Compiling 1616 files for jdk.localedata
>
> .../hs/src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java:60:
> error: package jdk.internal.misc is not visible
> import jdk.internal.misc.Unsafe;
> ^
> (package jdk.internal.misc is declared in module java.base, which does
> not export it to module jdk.jfr)
>
> .../hs/src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java:61:
> error: package jdk.internal.module does not exist
> import jdk.internal.module.Modules;
> ^
> .../hs/src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java:31: error:
> package jdk.internal is not visible
> import jdk.internal.HotSpotIntrinsicCandidate;
>
> etc.
>
> Any ideas of what could be wrong?
>
> -Dmitry
>
> On 04/07/2018 01:28 PM, Markus Gronlund wrote:
>> Greetings,
>>
>>
>>
>> This is a preview of a large part of the source code for JEP 328 : Flight Recorder[1].
>>
>>
>>
>> Webrev: http://cr.openjdk.java.net/~mgronlun/JEP328_FlightRecorder/Preview/webrev/index.html
>>
>>
>>
>> It has been tested on the following platforms:
>>
>> * Linux-x64
>>
>> * Windows-x64
>>
>> * MacOSX-x64
>>
>>
>>
>> We are planning to send out the code for full review in a couple of weeks.
>>
>>
>>
>> At this point, we are preparing changes to move to a single backend, as suggested in the JEP.
>>
>> These will encompass the following:
>>
>>
>>
>> 1. Rename macro INCLUDE_TRACE to INCLUDE_JFR.
>>
>> 2. Remove flag -XX:[+|-]EnableTracing.
>>
>> 3. Cleanup unused elements and attributes by restructuring the trace xml files.
>>
>> 4. Move code under hotspot/share/trace to hotspot/share/jfr/metadata.
>>
>>
>>
>> Thank you
>>
>> Markus and Erik
>>
>>
>>
>> [1] http://openjdk.java.net/jeps/328
>>
>>
>>
>> PS the patch was generated from the hs repository [2] using change [3] as parent.
>>
>> [2] http://hg.openjdk.java.net/jdk/hs
>>
>> [3] changeset: 49618:947560700a09
>>
>> user: stefank
>>
>> date: Fri Apr 06 13:55:25 2018 +0200
>>
>> summary: 8201136: Move GC flags from globals.hpp to GC specific files
>>
>
>
--
Dmitry Samersoff
http://devnull.samersoff.net
* There will come soft rains ...
-------------- next part --------------
diff -r 65a624584dda src/java.base/share/classes/module-info.java
--- a/src/java.base/share/classes/module-info.java Sun Apr 22 09:25:31 2018 +0000
+++ b/src/java.base/share/classes/module-info.java Sun Apr 22 09:59:02 2018 +0000
@@ -134,6 +134,8 @@
exports com.sun.security.ntlm to
java.security.sasl;
+ exports jdk.internal to
+ jdk.jfr;
exports jdk.internal.jimage to
jdk.jlink;
exports jdk.internal.jimage.decompressor to
@@ -149,16 +151,28 @@
exports jdk.internal.org.objectweb.asm to
jdk.jartool,
jdk.jlink,
+ jdk.jfr,
jdk.scripting.nashorn,
jdk.internal.vm.ci;
exports jdk.internal.org.objectweb.asm.tree to
+ jdk.jfr,
jdk.jlink;
exports jdk.internal.org.objectweb.asm.util to
+ jdk.jfr,
jdk.scripting.nashorn;
exports jdk.internal.org.objectweb.asm.commons to
+ jdk.jfr,
jdk.scripting.nashorn;
exports jdk.internal.org.objectweb.asm.signature to
jdk.scripting.nashorn;
+ exports jdk.internal.org.xml.sax to
+ jdk.jfr;
+ exports jdk.internal.org.xml.sax.helpers to
+ jdk.jfr;
+ exports jdk.internal.util.xml to
+ jdk.jfr;
+ exports jdk.internal.util.xml.impl to
+ jdk.jfr;
exports jdk.internal.misc to
java.desktop,
java.logging,
@@ -173,6 +187,7 @@
jdk.compiler,
jdk.incubator.httpclient,
jdk.jdeps,
+ jdk.jfr,
jdk.jlink,
jdk.jshell,
jdk.net,
@@ -184,6 +199,7 @@
java.instrument,
java.management.rmi,
jdk.jartool,
+ jdk.jfr,
jdk.jlink;
exports jdk.internal.perf to
java.management,
@@ -312,7 +328,6 @@
exports sun.util.resources to
jdk.localedata;
-
// the service types defined by the APIs in this module
uses java.lang.System.LoggerFinder;
diff -r 65a624584dda src/java.management/share/classes/module-info.java
--- a/src/java.management/share/classes/module-info.java Sun Apr 22 09:25:31 2018 +0000
+++ b/src/java.management/share/classes/module-info.java Sun Apr 22 09:59:02 2018 +0000
@@ -64,6 +64,7 @@
exports sun.management.counter.perf to
jdk.management.agent;
exports sun.management.spi to
+ jdk.management.jfr,
jdk.management,
jdk.internal.vm.compiler.management;
diff -r 65a624584dda test/jdk/jdk/jfr/api/consumer/TestRecordedFullStackTrace.java
--- a/test/jdk/jdk/jfr/api/consumer/TestRecordedFullStackTrace.java Sun Apr 22 09:25:31 2018 +0000
+++ b/test/jdk/jdk/jfr/api/consumer/TestRecordedFullStackTrace.java Sun Apr 22 09:59:02 2018 +0000
@@ -139,7 +139,7 @@
try {
stacktrace = event.getStackTrace();
List<RecordedFrame> frames = stacktrace.getFrames();
- Asserts.assertEquals(Math.min(MAX_DEPTH, expectedDepth), frames.size(), "Wrong stacktrace depth. Expected:" + expectedDepth);
+ // DMS: tmp Asserts.assertEquals(Math.min(MAX_DEPTH, expectedDepth), frames.size(), "Wrong stacktrace depth. Expected:" + expectedDepth);
List<String> expectedMethods = getExpectedMethods(expectedDepth);
Asserts.assertEquals(expectedMethods.size(), frames.size(), "Wrong expectedMethods depth. Test error.");
diff -r 65a624584dda test/jdk/jdk/jfr/event/os/TestCPUInformation.java
--- a/test/jdk/jdk/jfr/event/os/TestCPUInformation.java Sun Apr 22 09:25:31 2018 +0000
+++ b/test/jdk/jdk/jfr/event/os/TestCPUInformation.java Sun Apr 22 09:59:02 2018 +0000
@@ -54,7 +54,9 @@
Events.assertField(event, "cores").atLeast(1);
Events.assertField(event, "sockets").atLeast(1);
Events.assertField(event, "cpu").containsAny("Intel", "AMD", "Unknown x86", "sparc", "ARM", "PPC", "PowerPC", "AArch64");
- Events.assertField(event, "description").containsAny("Intel", "AMD", "Unknown x86", "SPARC", "ARM", "PPC", "PowerPC", "AArch64");
+// DMS: Line below is incorrect.
+// Description line for AArch64 looks like '0x43:0x1:0x0a1:1, simd, crc, aes, sha1, sha256, lse'
+// Events.assertField(event, "description").containsAny("Intel", "AMD", "Unknown x86", "SPARC", "ARM", "PPC", "PowerPC", "AArch64");
}
}
}
From Yang.Zhang at arm.com Mon Apr 23 07:14:08 2018
From: Yang.Zhang at arm.com (Yang Zhang)
Date: Mon, 23 Apr 2018 07:14:08 +0000
Subject: 8185505: AArch64: Port AOT
In-Reply-To: <5147cd22-8c3c-d72f-bf5d-0ef384eac45c@oracle.com>
References: <b439eaf0-e026-7ff8-e832-3717368027e4@redhat.com>
<AM5PR0802MB2449400467C4E4042C3C6A6390B00@AM5PR0802MB2449.eurprd08.prod.outlook.com>
<57767253-4826-e5b4-d142-7990d7114704@redhat.com>
<4626be6e-7927-a8ad-dead-1c3a4fca3ec9@oracle.com>
<5147cd22-8c3c-d72f-bf5d-0ef384eac45c@oracle.com>
Message-ID: <VI1PR0802MB2445EFDDB61AD73E87B99AC08E890@VI1PR0802MB2445.eurprd08.prod.outlook.com>
Hi Andrew
I have tested the patches in my environment. AOT test cases in jtreg are passed, and there aren't new failed cases in hotspot jtreg on no matter aarch64 or x86 platform.
But when using jaotc to compile java.base with an option "--compile-for-tiered", there is an overflow error on aarch64 platform. There isn't such an error on x86 platform.
PS. Error log:
In function `sun.net.idn.StringPrep.prepare(Lsun/text/normalizer/UCharacterIterator;I)Ljava/lang/StringBuffer;':(.text+0x440c): relocation truncated to fit: R_AARCH64_CALL26 against `Stub<backedge_event(MethodCountersPointer,int,int)void>'libjava.base.o: In function `sun.net.idn.StringPrep.<init>(Ljava/io/InputStream;)V':(.text+0x6108): additional relocation overflows omitted from the output
at jdk.aot/jdk.tools.jaotc.Linker.link(Linker.java:131)
at jdk.aot/jdk.tools.jaotc.Main.run(Main.java:220)
at jdk.aot/jdk.tools.jaotc.Main.run(Main.java:101)
at jdk.aot/jdk.tools.jaotc.Main.main(Main.java:80)
Regards
Yang
-----Original Message-----
From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On Behalf Of Vladimir Kozlov
Sent: Wednesday, April 18, 2018 8:30 AM
To: Andrew Haley <aph at redhat.com>; Ningsheng Jian <Ningsheng.Jian at arm.com>; hotspot-dev at openjdk.java.net
Cc: nd <nd at arm.com>
Subject: Re: 8185505: AArch64: Port AOT
And I forgot to say that changes looks good to me.
Thanks,
Vladimir
On 4/17/18 9:53 AM, Vladimir Kozlov wrote:
> On 4/16/18 2:03 AM, Andrew Haley wrote:
>> On 04/16/2018 09:53 AM, Ningsheng Jian wrote:
>>> I can see both the jdk patch and Graal PR contain changes of
>>> AArch64Assembler.java and AArch64MacroAssembler.java, but the changes looks somewhat different. How will they be synced?
>>
>> The changes to Graal in JDK do no more than allow OpenJDK to build.?
>> They are not called by anything, and will disappear at the next Graal import.
>>
>>> I noticed that in make/hotspot/lib/JvmFeatures.gmk line ~144, there's:
>>>
>>> ?? JVM_EXCLUDE_FILES += \
>>> ?????? compiledIC_aot_x86_64.cpp
>>>
>>> Do you want to add compiledIC_aot_aarch64.cpp to that list?
>>
>> I don't really know what this does, so I have no idea.
>
> It was done when we did not support/build AOT on Win and MacOS. It
> also work when AOT is disabled in
> build: configure --disable-aot
> We have to exclude to AOT files to avoid build failure because they do not have #ifdef INCLUDE_AOT.
>
> I think compiledIC_aot_aarch64.cpp should be added to exclude list
> too. And you can test you code with --disable-aot
>
> Vladimir
>
>>
>>> I also found that _immutable_PIC and its getters/setters are in the
>>> INCLUDE_AOT block, but some of their uses are not:
>>>
>>> src/hotspot/cpu/aarch64/compiledIC_aarch64.cpp:
>>>
>>> 61?? if (cbuf.immutable_PIC()) {
>>>
>>> src/hotspot/share/jvmci/jvmciCodeInstaller.cpp:
>>>
>>> 594?? buffer.set_immutable_PIC(_immutable_pic_compilation);
>>> 628?? buffer.set_immutable_PIC(_immutable_pic_compilation);
>>
>> Thank you.? For the sake of consistency I will change it.
>>
From mvala at redhat.com Mon Apr 23 07:51:53 2018
From: mvala at redhat.com (Michal Vala)
Date: Mon, 23 Apr 2018 09:51:53 +0200
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
readdir_r(DIR*, dirent*, dirent**)' is deprecated
Message-ID: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
Hi,
following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm posting
updated patch replacing deprecated readdir_r with readdir. Bug ID is JDK-8179887
[2].
webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
I'm asking for the review and eventually sponsorship.
Thanks!
[1] - http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021236.html
[2] - https://bugs.openjdk.java.net/browse/JDK-8179887
--
Michal Vala
OpenJDK QE
Red Hat Czech
From shade at redhat.com Mon Apr 23 08:37:39 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 23 Apr 2018 10:37:39 +0200
Subject: RFR: 8202082: Remove explicit CMS checks in
CardTableBarrierSetAssembler
In-Reply-To: <5AD9FC94.70607@oracle.com>
References: <5AD9FC94.70607@oracle.com>
Message-ID: <6bd6de7f-2ab5-b729-264a-d09b91beea86@redhat.com>
On 04/20/2018 04:43 PM, Erik ?sterlund wrote:
> In CardTableBarrierSetAssembler, we sometimes need fencing due to the card table being scanned
> concurrently when using CMS with pre-cleaning. Rather than explicitly checking for those CMS flags
> in the generic CardTableBarrierSetAssembler class, it is preferrable to check the CardTable
> scanned_concurrently() property which already precisely reflects that.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8202082
>
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.00/
This makes sense. Except that I see that scanned_concurrently is enabled only when
CMSPrecleaningEnabled is true:
CMSCardTable::CMSCardTable(MemRegion whole_heap) :
CardTableRS(whole_heap, CMSPrecleaningEnabled /* scanned_concurrently */) {
}
...but old code inserts the barriers mostly with checking UseCMS only. I guess it does not matter
much for CMS that does not have G1-like concurrent refinement threads, and we really do care about
precleaning only?
Otherwise looks good!
-Aleksey
From david.holmes at oracle.com Mon Apr 23 08:41:10 2018
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 23 Apr 2018 18:41:10 +1000
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
readdir_r(DIR*, dirent*, dirent**)' is deprecated
In-Reply-To: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
Message-ID: <116a3b63-1b86-6b0e-16bf-376b1d1e8ea5@oracle.com>
Hi Michal,
This was discussed in a couple of different threads. Please also see:
http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021530.html
Thanks,
David
On 23/04/2018 5:51 PM, Michal Vala wrote:
> Hi,
>
> following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm
> posting updated patch replacing deprecated readdir_r with readdir. Bug
> ID is JDK-8179887 [2].
>
> webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
>
> I'm asking for the review and eventually sponsorship.
>
> Thanks!
>
> [1] -
> http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021236.html
> [2] - https://bugs.openjdk.java.net/browse/JDK-8179887
From shade at redhat.com Mon Apr 23 09:06:48 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 23 Apr 2018 11:06:48 +0200
Subject: RFR (XS) 8202134: Non-PCH build for arm32 fails
Message-ID: <4eed29e4-55f2-fd35-b9d8-661c74c3662c@redhat.com>
Current arm32 jdk/jdk fails to build without PCH.
Bug (with sample build failures):
https://bugs.openjdk.java.net/browse/JDK-8202134
Fix:
diff -r ac761df837c7 src/hotspot/cpu/arm/methodHandles_arm.cpp
--- a/src/hotspot/cpu/arm/methodHandles_arm.cpp Thu Apr 19 12:02:38 2018 +0200
+++ b/src/hotspot/cpu/arm/methodHandles_arm.cpp Mon Apr 23 10:55:07 2018 +0200
@@ -35,6 +35,7 @@
#include "memory/resourceArea.hpp"
#include "prims/methodHandles.hpp"
#include "runtime/frame.inline.hpp"
+#include "utilities/preserveException.hpp"
#define __ _masm->
diff -r ac761df837c7 src/hotspot/cpu/arm/nativeInst_arm_32.hpp
--- a/src/hotspot/cpu/arm/nativeInst_arm_32.hpp Thu Apr 19 12:02:38 2018 +0200
+++ b/src/hotspot/cpu/arm/nativeInst_arm_32.hpp Mon Apr 23 10:55:07 2018 +0200
@@ -28,6 +28,7 @@
#include "asm/macroAssembler.hpp"
#include "code/codeCache.hpp"
#include "runtime/icache.hpp"
+#include "runtime/orderAccess.inline.hpp"
#include "runtime/os.hpp"
#include "runtime/thread.hpp"
#include "register_arm.hpp"
Testing: arm32-hflt {fastdebug|release} cross-build
Thanks,
-Aleksey
From shade at redhat.com Mon Apr 23 09:13:41 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 23 Apr 2018 11:13:41 +0200
Subject: RFR (XS) 8202134: Non-PCH build for arm32 fails
In-Reply-To: <4eed29e4-55f2-fd35-b9d8-661c74c3662c@redhat.com>
References: <4eed29e4-55f2-fd35-b9d8-661c74c3662c@redhat.com>
Message-ID: <d80a72d3-e96d-0dda-2f21-2323dbf7791f@redhat.com>
On 04/23/2018 11:06 AM, Aleksey Shipilev wrote:
> Current arm32 jdk/jdk fails to build without PCH.
>
> Bug (with sample build failures):
> https://bugs.openjdk.java.net/browse/JDK-8202134
>
> Fix:
>
> diff -r ac761df837c7 src/hotspot/cpu/arm/methodHandles_arm.cpp
> --- a/src/hotspot/cpu/arm/methodHandles_arm.cpp Thu Apr 19 12:02:38 2018 +0200
> +++ b/src/hotspot/cpu/arm/methodHandles_arm.cpp Mon Apr 23 10:55:07 2018 +0200
> @@ -35,6 +35,7 @@
> #include "memory/resourceArea.hpp"
> #include "prims/methodHandles.hpp"
> #include "runtime/frame.inline.hpp"
> +#include "utilities/preserveException.hpp"
>
> #define __ _masm->
>
> diff -r ac761df837c7 src/hotspot/cpu/arm/nativeInst_arm_32.hpp
> --- a/src/hotspot/cpu/arm/nativeInst_arm_32.hpp Thu Apr 19 12:02:38 2018 +0200
> +++ b/src/hotspot/cpu/arm/nativeInst_arm_32.hpp Mon Apr 23 10:55:07 2018 +0200
> @@ -28,6 +28,7 @@
> #include "asm/macroAssembler.hpp"
> #include "code/codeCache.hpp"
> #include "runtime/icache.hpp"
> +#include "runtime/orderAccess.inline.hpp"
> #include "runtime/os.hpp"
> #include "runtime/thread.hpp"
> #include "register_arm.hpp"
Actually, .inline.hpp is better be in the .cpp that failed to build, not in the header itself:
diff -r fcd5df7aa235 src/hotspot/cpu/arm/methodHandles_arm.cpp
--- a/src/hotspot/cpu/arm/methodHandles_arm.cpp Wed Apr 18 11:19:32 2018 +0200
+++ b/src/hotspot/cpu/arm/methodHandles_arm.cpp Mon Apr 23 11:13:32 2018 +0200
@@ -35,6 +35,7 @@
#include "memory/resourceArea.hpp"
#include "prims/methodHandles.hpp"
#include "runtime/frame.inline.hpp"
+#include "utilities/preserveException.hpp"
#define __ _masm->
diff -r fcd5df7aa235 src/hotspot/cpu/arm/relocInfo_arm.cpp
--- a/src/hotspot/cpu/arm/relocInfo_arm.cpp Wed Apr 18 11:19:32 2018 +0200
+++ b/src/hotspot/cpu/arm/relocInfo_arm.cpp Mon Apr 23 11:13:32 2018 +0200
@@ -29,6 +29,7 @@
#include "nativeInst_arm.hpp"
#include "oops/compressedOops.inline.hpp"
#include "oops/oop.hpp"
+#include "runtime/orderAccess.inline.hpp"
#include "runtime/safepoint.hpp"
void Relocation::pd_set_data_value(address x, intptr_t o, bool verify_only) {
Thanks,
-Aleksey
From claes.redestad at oracle.com Mon Apr 23 09:18:23 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 23 Apr 2018 11:18:23 +0200
Subject: Large page use crashes the JVM on some Linux systems
In-Reply-To: <CAEgw74ApMVY2EiYwWN6UZcbCx6dQZMt2bCKMuMM_2rY4nCjGWA@mail.gmail.com>
References: <CAEgw74ApMVY2EiYwWN6UZcbCx6dQZMt2bCKMuMM_2rY4nCjGWA@mail.gmail.com>
Message-ID: <3bfbdf0a-7c9c-6b95-8c6a-a92c169dbf9b@oracle.com>
[ /bcc amber-dev, /cc hotspot-dev ]
Hi,
unconditionally mapping and unmapping a large page on startup seems
sub-optimal to me - could this be checked directly after
-XX:+UseLargePages flag has been parsed?
I'd also note that explicitly configured large pages are typically a
limited
resource: does this test distinguish between a failure due the system not
supporting the feature and a failure due not having any free pages left?
Printing a "UseLargePages is unsupported" message in the latter case
would be misleading.
I wonder if checking something like /proc/meminfo for HugePages_* is a
more robust way to probe capabilities, and also whether this is more
suited as a test harness feature, i.e., enhance jtreg and tag these tests
so that they're ignored on systems that doesn't have any/enough huge
pages.
Thanks!
/Claes
On 2018-04-22 23:18, B. Blaser wrote:
> [ I've trouble subscribing to hotspot-dev, please forward if necessary. ]
>
> Hi,
>
> After a clean build, some hotspot tests related to large page use are
> failing on my 64-bit Linux system, for example:
>
> gc/g1/TestLargePageUseForAuxMemory.java
> [...]
>
> Or simply:
>
> $ ./build/linux-x86_64-normal-server-release/images/jdk/bin/java
> -XX:+UseLargePages -version
>
> is crashing the JVM because the latter assumes that large pages are
> always supported on Linux, which appears to be wrong.
>
> I suggest to make sure that large pages are supported when parsing the
> arguments, as below.
>
> Does this look reasonable (tier1 looks better now)?
>
> Thanks,
> Bernard
>
> diff -r 8c85a1855e10 src/hotspot/share/runtime/arguments.cpp
> --- a/src/hotspot/share/runtime/arguments.cpp Fri Apr 13 11:14:49 2018 -0700
> +++ b/src/hotspot/share/runtime/arguments.cpp Sun Apr 22 20:29:21 2018 +0200
> @@ -60,6 +60,7 @@
> #include "utilities/defaultStream.hpp"
> #include "utilities/macros.hpp"
> #include "utilities/stringUtils.hpp"
> +#include "sys/mman.h"
> #if INCLUDE_JVMCI
> #include "jvmci/jvmciRuntime.hpp"
> #endif
> @@ -4107,6 +4108,18 @@
> UNSUPPORTED_OPTION(UseLargePages);
> #endif
>
> +#ifdef LINUX
> + void *p = mmap(NULL, os::large_page_size(), PROT_READ|PROT_WRITE,
> + MAP_ANONYMOUS|MAP_PRIVATE|MAP_HUGETLB,
> + -1, 0);
> + if (p != MAP_FAILED) {
> + munmap(p, os::large_page_size());
> + }
> + else {
> + UNSUPPORTED_OPTION(UseLargePages);
> + }
> +#endif
> +
> ArgumentsExt::report_unsupported_options();
>
> #ifndef PRODUCT
> diff -r 8c85a1855e10
> test/hotspot/jtreg/runtime/memory/LargePages/TestLargePagesFlags.java
> --- a/test/hotspot/jtreg/runtime/memory/LargePages/TestLargePagesFlags.java
> Fri Apr 13 11:14:49 2018 -0700
> +++ b/test/hotspot/jtreg/runtime/memory/LargePages/TestLargePagesFlags.java
> Sun Apr 22 20:29:21 2018 +0200
> @@ -37,7 +37,7 @@
> public class TestLargePagesFlags {
>
> public static void main(String [] args) throws Exception {
> - if (!Platform.isLinux()) {
> + if (!Platform.isLinux() || !canUse(UseLargePages(true))) {
> System.out.println("Skipping. TestLargePagesFlags has only been
> implemented for Linux.");
> return;
> }
From stefan.karlsson at oracle.com Mon Apr 23 09:15:50 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 23 Apr 2018 11:15:50 +0200
Subject: RFR (XS) 8202134: Non-PCH build for arm32 fails
In-Reply-To: <d80a72d3-e96d-0dda-2f21-2323dbf7791f@redhat.com>
References: <4eed29e4-55f2-fd35-b9d8-661c74c3662c@redhat.com>
<d80a72d3-e96d-0dda-2f21-2323dbf7791f@redhat.com>
Message-ID: <0aa77ee1-f14e-d541-3768-15df59642cfa@oracle.com>
Looks good.
StefanK
On 2018-04-23 11:13, Aleksey Shipilev wrote:
> On 04/23/2018 11:06 AM, Aleksey Shipilev wrote:
>> Current arm32 jdk/jdk fails to build without PCH.
>>
>> Bug (with sample build failures):
>> https://bugs.openjdk.java.net/browse/JDK-8202134
>>
>> Fix:
>>
>> diff -r ac761df837c7 src/hotspot/cpu/arm/methodHandles_arm.cpp
>> --- a/src/hotspot/cpu/arm/methodHandles_arm.cpp Thu Apr 19 12:02:38 2018 +0200
>> +++ b/src/hotspot/cpu/arm/methodHandles_arm.cpp Mon Apr 23 10:55:07 2018 +0200
>> @@ -35,6 +35,7 @@
>> #include "memory/resourceArea.hpp"
>> #include "prims/methodHandles.hpp"
>> #include "runtime/frame.inline.hpp"
>> +#include "utilities/preserveException.hpp"
>>
>> #define __ _masm->
>>
>> diff -r ac761df837c7 src/hotspot/cpu/arm/nativeInst_arm_32.hpp
>> --- a/src/hotspot/cpu/arm/nativeInst_arm_32.hpp Thu Apr 19 12:02:38 2018 +0200
>> +++ b/src/hotspot/cpu/arm/nativeInst_arm_32.hpp Mon Apr 23 10:55:07 2018 +0200
>> @@ -28,6 +28,7 @@
>> #include "asm/macroAssembler.hpp"
>> #include "code/codeCache.hpp"
>> #include "runtime/icache.hpp"
>> +#include "runtime/orderAccess.inline.hpp"
>> #include "runtime/os.hpp"
>> #include "runtime/thread.hpp"
>> #include "register_arm.hpp"
>
> Actually, .inline.hpp is better be in the .cpp that failed to build, not in the header itself:
>
>
> diff -r fcd5df7aa235 src/hotspot/cpu/arm/methodHandles_arm.cpp
> --- a/src/hotspot/cpu/arm/methodHandles_arm.cpp Wed Apr 18 11:19:32 2018 +0200
> +++ b/src/hotspot/cpu/arm/methodHandles_arm.cpp Mon Apr 23 11:13:32 2018 +0200
> @@ -35,6 +35,7 @@
> #include "memory/resourceArea.hpp"
> #include "prims/methodHandles.hpp"
> #include "runtime/frame.inline.hpp"
> +#include "utilities/preserveException.hpp"
>
> #define __ _masm->
>
> diff -r fcd5df7aa235 src/hotspot/cpu/arm/relocInfo_arm.cpp
> --- a/src/hotspot/cpu/arm/relocInfo_arm.cpp Wed Apr 18 11:19:32 2018 +0200
> +++ b/src/hotspot/cpu/arm/relocInfo_arm.cpp Mon Apr 23 11:13:32 2018 +0200
> @@ -29,6 +29,7 @@
> #include "nativeInst_arm.hpp"
> #include "oops/compressedOops.inline.hpp"
> #include "oops/oop.hpp"
> +#include "runtime/orderAccess.inline.hpp"
> #include "runtime/safepoint.hpp"
>
> void Relocation::pd_set_data_value(address x, intptr_t o, bool verify_only) {
>
>
> Thanks,
> -Aleksey
>
From erik.osterlund at oracle.com Mon Apr 23 10:00:39 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Mon, 23 Apr 2018 12:00:39 +0200
Subject: RFR: 8202082: Remove explicit CMS checks in
CardTableBarrierSetAssembler
In-Reply-To: <6bd6de7f-2ab5-b729-264a-d09b91beea86@redhat.com>
References: <5AD9FC94.70607@oracle.com>
<6bd6de7f-2ab5-b729-264a-d09b91beea86@redhat.com>
Message-ID: <5ADDAEC7.4050300@oracle.com>
Hi Aleksey,
Thanks for having a look at this patch.
You are right, the previous code has been inconsistent. Sometimes it
checked just for CMS, and sometimes CMS + pre-cleaning. The actual
property we are looking for is whether the card table is scanned
concurrently or not (which I want to determine at a single place instead
of all over the place). And for CMS, this is only when pre-cleaning is
enabled. The callsites that only checked for CMS (and not CMS +
pre-cleaning) are fencing despite there being no actual race to protect
against.
Thanks,
/Erik
On 2018-04-23 10:37, Aleksey Shipilev wrote:
> On 04/20/2018 04:43 PM, Erik ?sterlund wrote:
>> In CardTableBarrierSetAssembler, we sometimes need fencing due to the card table being scanned
>> concurrently when using CMS with pre-cleaning. Rather than explicitly checking for those CMS flags
>> in the generic CardTableBarrierSetAssembler class, it is preferrable to check the CardTable
>> scanned_concurrently() property which already precisely reflects that.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8202082
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.00/
> This makes sense. Except that I see that scanned_concurrently is enabled only when
> CMSPrecleaningEnabled is true:
>
> CMSCardTable::CMSCardTable(MemRegion whole_heap) :
> CardTableRS(whole_heap, CMSPrecleaningEnabled /* scanned_concurrently */) {
> }
>
> ...but old code inserts the barriers mostly with checking UseCMS only. I guess it does not matter
> much for CMS that does not have G1-like concurrent refinement threads, and we really do care about
> precleaning only?
>
> Otherwise looks good!
>
> -Aleksey
>
From shade at redhat.com Mon Apr 23 10:01:04 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 23 Apr 2018 12:01:04 +0200
Subject: RFR: 8202082: Remove explicit CMS checks in
CardTableBarrierSetAssembler
In-Reply-To: <5ADDAEC7.4050300@oracle.com>
References: <5AD9FC94.70607@oracle.com>
<6bd6de7f-2ab5-b729-264a-d09b91beea86@redhat.com>
<5ADDAEC7.4050300@oracle.com>
Message-ID: <80718567-5de5-9518-17f9-c8c1405b002c@redhat.com>
On 04/23/2018 12:00 PM, Erik ?sterlund wrote:
> You are right, the previous code has been inconsistent. Sometimes it checked just for CMS, and
> sometimes CMS + pre-cleaning. The actual property we are looking for is whether the card table is
> scanned concurrently or not (which I want to determine at a single place instead of all over the
> place). And for CMS, this is only when pre-cleaning is enabled. The callsites that only checked for
> CMS (and not CMS + pre-cleaning) are fencing despite there being no actual race to protect against.
Yup, that's what I wanted to be confirmed.
Looks good.
-Aleksey
From erik.osterlund at oracle.com Mon Apr 23 10:07:27 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Mon, 23 Apr 2018 12:07:27 +0200
Subject: RFR: 8202082: Remove explicit CMS checks in
CardTableBarrierSetAssembler
In-Reply-To: <80718567-5de5-9518-17f9-c8c1405b002c@redhat.com>
References: <5AD9FC94.70607@oracle.com>
<6bd6de7f-2ab5-b729-264a-d09b91beea86@redhat.com>
<5ADDAEC7.4050300@oracle.com>
<80718567-5de5-9518-17f9-c8c1405b002c@redhat.com>
Message-ID: <5ADDB05F.6010001@oracle.com>
Hi Aleksey,
Thanks for the review.
/Erik
On 2018-04-23 12:01, Aleksey Shipilev wrote:
> On 04/23/2018 12:00 PM, Erik ?sterlund wrote:
>> You are right, the previous code has been inconsistent. Sometimes it checked just for CMS, and
>> sometimes CMS + pre-cleaning. The actual property we are looking for is whether the card table is
>> scanned concurrently or not (which I want to determine at a single place instead of all over the
>> place). And for CMS, this is only when pre-cleaning is enabled. The callsites that only checked for
>> CMS (and not CMS + pre-cleaning) are fencing despite there being no actual race to protect against.
> Yup, that's what I wanted to be confirmed.
>
> Looks good.
>
> -Aleksey
>
From shade at redhat.com Mon Apr 23 10:05:44 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 23 Apr 2018 12:05:44 +0200
Subject: RFR (XS) 8202134: Non-PCH build for arm32 fails
In-Reply-To: <0aa77ee1-f14e-d541-3768-15df59642cfa@oracle.com>
References: <4eed29e4-55f2-fd35-b9d8-661c74c3662c@redhat.com>
<d80a72d3-e96d-0dda-2f21-2323dbf7791f@redhat.com>
<0aa77ee1-f14e-d541-3768-15df59642cfa@oracle.com>
Message-ID: <8de71e7d-af70-ad65-00ed-e0ac9257cf72@redhat.com>
Thanks Stefan.
I presume this is trivial, and not touching shared code, so one reviewer is enough?
-Aleksey
On 04/23/2018 11:15 AM, Stefan Karlsson wrote:
> Looks good.
>
> StefanK
>
> On 2018-04-23 11:13, Aleksey Shipilev wrote:
>> On 04/23/2018 11:06 AM, Aleksey Shipilev wrote:
>>> Current arm32 jdk/jdk fails to build without PCH.
>>>
>>> Bug (with sample build failures):
>>> ?? https://bugs.openjdk.java.net/browse/JDK-8202134
>>>
>>> Fix:
>>>
>>> diff -r ac761df837c7 src/hotspot/cpu/arm/methodHandles_arm.cpp
>>> --- a/src/hotspot/cpu/arm/methodHandles_arm.cpp??? Thu Apr 19 12:02:38 2018 +0200
>>> +++ b/src/hotspot/cpu/arm/methodHandles_arm.cpp??? Mon Apr 23 10:55:07 2018 +0200
>>> @@ -35,6 +35,7 @@
>>> ? #include "memory/resourceArea.hpp"
>>> ? #include "prims/methodHandles.hpp"
>>> ? #include "runtime/frame.inline.hpp"
>>> +#include "utilities/preserveException.hpp"
>>>
>>> ? #define __ _masm->
>>>
>>> diff -r ac761df837c7 src/hotspot/cpu/arm/nativeInst_arm_32.hpp
>>> --- a/src/hotspot/cpu/arm/nativeInst_arm_32.hpp??? Thu Apr 19 12:02:38 2018 +0200
>>> +++ b/src/hotspot/cpu/arm/nativeInst_arm_32.hpp??? Mon Apr 23 10:55:07 2018 +0200
>>> @@ -28,6 +28,7 @@
>>> ? #include "asm/macroAssembler.hpp"
>>> ? #include "code/codeCache.hpp"
>>> ? #include "runtime/icache.hpp"
>>> +#include "runtime/orderAccess.inline.hpp"
>>> ? #include "runtime/os.hpp"
>>> ? #include "runtime/thread.hpp"
>>> ? #include "register_arm.hpp"
>>
>> Actually, .inline.hpp is better be in the .cpp that failed to build, not in the header itself:
>>
>>
>> diff -r fcd5df7aa235 src/hotspot/cpu/arm/methodHandles_arm.cpp
>> --- a/src/hotspot/cpu/arm/methodHandles_arm.cpp??? Wed Apr 18 11:19:32 2018 +0200
>> +++ b/src/hotspot/cpu/arm/methodHandles_arm.cpp??? Mon Apr 23 11:13:32 2018 +0200
>> @@ -35,6 +35,7 @@
>> ? #include "memory/resourceArea.hpp"
>> ? #include "prims/methodHandles.hpp"
>> ? #include "runtime/frame.inline.hpp"
>> +#include "utilities/preserveException.hpp"
>>
>> ? #define __ _masm->
>>
>> diff -r fcd5df7aa235 src/hotspot/cpu/arm/relocInfo_arm.cpp
>> --- a/src/hotspot/cpu/arm/relocInfo_arm.cpp??? Wed Apr 18 11:19:32 2018 +0200
>> +++ b/src/hotspot/cpu/arm/relocInfo_arm.cpp??? Mon Apr 23 11:13:32 2018 +0200
>> @@ -29,6 +29,7 @@
>> ? #include "nativeInst_arm.hpp"
>> ? #include "oops/compressedOops.inline.hpp"
>> ? #include "oops/oop.hpp"
>> +#include "runtime/orderAccess.inline.hpp"
>> ? #include "runtime/safepoint.hpp"
>>
>> ? void Relocation::pd_set_data_value(address x, intptr_t o, bool verify_only) {
>>
>>
>> Thanks,
>> -Aleksey
>>
From stefan.karlsson at oracle.com Mon Apr 23 10:08:38 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 23 Apr 2018 12:08:38 +0200
Subject: RFR (XS) 8202134: Non-PCH build for arm32 fails
In-Reply-To: <8de71e7d-af70-ad65-00ed-e0ac9257cf72@redhat.com>
References: <4eed29e4-55f2-fd35-b9d8-661c74c3662c@redhat.com>
<d80a72d3-e96d-0dda-2f21-2323dbf7791f@redhat.com>
<0aa77ee1-f14e-d541-3768-15df59642cfa@oracle.com>
<8de71e7d-af70-ad65-00ed-e0ac9257cf72@redhat.com>
Message-ID: <365544b6-6683-8605-efcb-87f85dbaf084@oracle.com>
On 2018-04-23 12:05, Aleksey Shipilev wrote:
> Thanks Stefan.
>
> I presume this is trivial, and not touching shared code, so one reviewer is enough?
Yes, I think so.
StefanK
>
> -Aleksey
>
> On 04/23/2018 11:15 AM, Stefan Karlsson wrote:
>> Looks good.
>>
>> StefanK
>>
>> On 2018-04-23 11:13, Aleksey Shipilev wrote:
>>> On 04/23/2018 11:06 AM, Aleksey Shipilev wrote:
>>>> Current arm32 jdk/jdk fails to build without PCH.
>>>>
>>>> Bug (with sample build failures):
>>>> ?? https://bugs.openjdk.java.net/browse/JDK-8202134
>>>>
>>>> Fix:
>>>>
>>>> diff -r ac761df837c7 src/hotspot/cpu/arm/methodHandles_arm.cpp
>>>> --- a/src/hotspot/cpu/arm/methodHandles_arm.cpp??? Thu Apr 19 12:02:38 2018 +0200
>>>> +++ b/src/hotspot/cpu/arm/methodHandles_arm.cpp??? Mon Apr 23 10:55:07 2018 +0200
>>>> @@ -35,6 +35,7 @@
>>>> ? #include "memory/resourceArea.hpp"
>>>> ? #include "prims/methodHandles.hpp"
>>>> ? #include "runtime/frame.inline.hpp"
>>>> +#include "utilities/preserveException.hpp"
>>>>
>>>> ? #define __ _masm->
>>>>
>>>> diff -r ac761df837c7 src/hotspot/cpu/arm/nativeInst_arm_32.hpp
>>>> --- a/src/hotspot/cpu/arm/nativeInst_arm_32.hpp??? Thu Apr 19 12:02:38 2018 +0200
>>>> +++ b/src/hotspot/cpu/arm/nativeInst_arm_32.hpp??? Mon Apr 23 10:55:07 2018 +0200
>>>> @@ -28,6 +28,7 @@
>>>> ? #include "asm/macroAssembler.hpp"
>>>> ? #include "code/codeCache.hpp"
>>>> ? #include "runtime/icache.hpp"
>>>> +#include "runtime/orderAccess.inline.hpp"
>>>> ? #include "runtime/os.hpp"
>>>> ? #include "runtime/thread.hpp"
>>>> ? #include "register_arm.hpp"
>>>
>>> Actually, .inline.hpp is better be in the .cpp that failed to build, not in the header itself:
>>>
>>>
>>> diff -r fcd5df7aa235 src/hotspot/cpu/arm/methodHandles_arm.cpp
>>> --- a/src/hotspot/cpu/arm/methodHandles_arm.cpp??? Wed Apr 18 11:19:32 2018 +0200
>>> +++ b/src/hotspot/cpu/arm/methodHandles_arm.cpp??? Mon Apr 23 11:13:32 2018 +0200
>>> @@ -35,6 +35,7 @@
>>> ? #include "memory/resourceArea.hpp"
>>> ? #include "prims/methodHandles.hpp"
>>> ? #include "runtime/frame.inline.hpp"
>>> +#include "utilities/preserveException.hpp"
>>>
>>> ? #define __ _masm->
>>>
>>> diff -r fcd5df7aa235 src/hotspot/cpu/arm/relocInfo_arm.cpp
>>> --- a/src/hotspot/cpu/arm/relocInfo_arm.cpp??? Wed Apr 18 11:19:32 2018 +0200
>>> +++ b/src/hotspot/cpu/arm/relocInfo_arm.cpp??? Mon Apr 23 11:13:32 2018 +0200
>>> @@ -29,6 +29,7 @@
>>> ? #include "nativeInst_arm.hpp"
>>> ? #include "oops/compressedOops.inline.hpp"
>>> ? #include "oops/oop.hpp"
>>> +#include "runtime/orderAccess.inline.hpp"
>>> ? #include "runtime/safepoint.hpp"
>>>
>>> ? void Relocation::pd_set_data_value(address x, intptr_t o, bool verify_only) {
>>>
>>>
>>> Thanks,
>>> -Aleksey
>>>
>
>
From aph at redhat.com Mon Apr 23 10:20:39 2018
From: aph at redhat.com (Andrew Haley)
Date: Mon, 23 Apr 2018 11:20:39 +0100
Subject: RFR 8201799: Build failures after JDK-8195099 (Concurrent
safe-memory-reclamation mechanism)
In-Reply-To: <803cb23d4b754d2384d9681950f5297c@sap.com>
References: <150dc231-d81e-58da-fa46-fd2397bb7ca2@redhat.com>
<ee7c6a6c-7697-ca4b-dd3d-484ca24aeabd@oracle.com> <5AD73E53.90904@oracle.com>
<803cb23d4b754d2384d9681950f5297c@sap.com>
Message-ID: <661ce2cc-2ea7-9a99-e646-ac3fd8c3494e@redhat.com>
On 04/18/2018 05:37 PM, Doerr, Martin wrote:
> It'd be great if we could specify semantics for Atomic:add like we
> do for Atomic::cmpchgx.
> However, the double-fence is a very bad default from performance
> perspective. I wonder if PPC64 is the only platform which gets hit.
Probably not.
> Would it be acceptable to set the default to
> memory_order_acquire_release and specify memory_order_conservative
> for the new usage? I think this would fit perfectly for PPC64, but
> some people may not like it. One could say PPC64 is the problem, but
> one could also say the VM code is the problem ??
Indeed. In as much as we use stronger memory ordering than we need in
more than one place, the VM code is the problem.
> I don't really like the straight forward fix to insert a fence with
> #ifdef AIX.
I agree. It looks to me like it's sufficient if the increment of
global_counter and the load of thread->get_rcu_counter() are
sequentially consistent. On at least one platform, AArch64, we can
do that without additional fencing.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From HORIE at jp.ibm.com Mon Apr 23 10:33:59 2018
From: HORIE at jp.ibm.com (Michihiro Horie)
Date: Mon, 23 Apr 2018 19:33:59 +0900
Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64
Message-ID: <OF16DAB34F.17FD9ED8-ON00258278.002211BA-49258278.003A0AFD@notes.na.collabserv.com>
Dear all,
I would like to ask reviews on 8154736 ?enhancement of cmpxchg and
copy_to_survivor?. The change adds options to avoid expensive syncs with
compare-and-exchange. An experiment by using SPECjbb2015 showed 6%
improvement in critical-jOPS. This change focuses on ppc64 but would be
potentially beneficial for aarch64.
Although discussions stopped at
http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-October/002718.html
, I would like to restart the review by taking over Hiroshi's work if the
discussion is still open.
Bug: https://bugs.openjdk.java.net/browse/JDK-8154736
Webrev: http://cr.openjdk.java.net/~mhorie/8154736/webrev.08/
Previous review had discussions on improper log output (
http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-September/002672.html
). Logs can be generated properly with this change, but I would like to ask
if we should use ?if(log) OrderAccess:acquire()? as is in webrev or more
general approach with a call to OrderAccess:consume() with empty
implementation on all supported platforms.
Also, there were discussions on the problem of unawareness of copied obj (
http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-October/002696.html
). This change adds ?release? in cmpxchg_pre_membar. This was discussed in
http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-October/002698.html
.
I measured SPECjbb2015 with its multi JVMs mode on a POWER8 node (for JDK11
, I modified MANIFEST in specjbb2015.jar to specify locations of JAXB
related libraries). As a result, critical-jOPS improved by 6% due to this
change.
Best regards,
--
Michihiro,
IBM Research - Tokyo
From erik.osterlund at oracle.com Mon Apr 23 10:40:35 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Mon, 23 Apr 2018 12:40:35 +0200
Subject: RFR 8201799: Build failures after JDK-8195099 (Concurrent
safe-memory-reclamation mechanism)
In-Reply-To: <661ce2cc-2ea7-9a99-e646-ac3fd8c3494e@redhat.com>
References: <150dc231-d81e-58da-fa46-fd2397bb7ca2@redhat.com>
<ee7c6a6c-7697-ca4b-dd3d-484ca24aeabd@oracle.com> <5AD73E53.90904@oracle.com>
<803cb23d4b754d2384d9681950f5297c@sap.com>
<661ce2cc-2ea7-9a99-e646-ac3fd8c3494e@redhat.com>
Message-ID: <5ADDB823.5060002@oracle.com>
Hi Andrew,
On 2018-04-23 12:20, Andrew Haley wrote:
> On 04/18/2018 05:37 PM, Doerr, Martin wrote:
>
>> It'd be great if we could specify semantics for Atomic:add like we
>> do for Atomic::cmpchgx.
>> However, the double-fence is a very bad default from performance
>> perspective. I wonder if PPC64 is the only platform which gets hit.
> Probably not.
>
>> Would it be acceptable to set the default to
>> memory_order_acquire_release and specify memory_order_conservative
>> for the new usage? I think this would fit perfectly for PPC64, but
>> some people may not like it. One could say PPC64 is the problem, but
>> one could also say the VM code is the problem ??
> Indeed. In as much as we use stronger memory ordering than we need in
> more than one place, the VM code is the problem.
>
>> I don't really like the straight forward fix to insert a fence with
>> #ifdef AIX.
> I agree. It looks to me like it's sufficient if the increment of
> global_counter and the load of thread->get_rcu_counter() are
> sequentially consistent. On at least one platform, AArch64, we can
> do that without additional fencing.
I would also like to have seq_cst available. In the Access API, I need
MO_SEQ_CST for JMM volatile support. I would like the semantic
requirements to go straight into Atomic, instead of doing a "if
(support_IRIW_for_not_multiple_copy_atomic_cpu) { OrderAccess::fence();
}" dance in shared code, that may or may not make sense at a given
platform (among other reasons because it enforces whether leading or
trailing sync convention is used in shared code, rather than leave that
decision to the platform level). Plus I have a mouse pad that says I
love sequential consistency, although that might not be a valid argument
to introduce this to Atomic.
Thanks,
/Erik
From aph at redhat.com Mon Apr 23 10:38:27 2018
From: aph at redhat.com (Andrew Haley)
Date: Mon, 23 Apr 2018 11:38:27 +0100
Subject: 8185505: AArch64: Port AOT
In-Reply-To: <VI1PR0802MB2445EFDDB61AD73E87B99AC08E890@VI1PR0802MB2445.eurprd08.prod.outlook.com>
References: <b439eaf0-e026-7ff8-e832-3717368027e4@redhat.com>
<AM5PR0802MB2449400467C4E4042C3C6A6390B00@AM5PR0802MB2449.eurprd08.prod.outlook.com>
<57767253-4826-e5b4-d142-7990d7114704@redhat.com>
<4626be6e-7927-a8ad-dead-1c3a4fca3ec9@oracle.com>
<5147cd22-8c3c-d72f-bf5d-0ef384eac45c@oracle.com>
<VI1PR0802MB2445EFDDB61AD73E87B99AC08E890@VI1PR0802MB2445.eurprd08.prod.outlook.com>
Message-ID: <a7cdcca0-d2e4-7285-51f4-d12420dd0d0e@redhat.com>
On 04/23/2018 08:14 AM, Yang Zhang wrote:
> I have tested the patches in my environment. AOT test cases in jtreg
> are passed, and there aren't new failed cases in hotspot jtreg on no
> matter aarch64 or x86 platform.
> But when using jaotc to compile java.base with an option
> "--compile-for-tiered", there is an overflow error on aarch64
> platform. There isn't such an error on x86 platform.
Yep, I know that. It's because there is a 30-bit limit in the range
of a branch, and if we have a very large text section the offset to
the PLT stub may be out of range. There is some logic in the GNU
linker to handle this, and I'll haver a look at how it works.
I don't want to hold up this patch for the overflow issue for two
reasons. Firstly, if you use such a huge AOT-compiled binary your
performance will suffer greatly. It makes much more sense to compile
only what you need because otherwise your startup time will actually
be slower than not using AOT compilation at all. Secondly, I think it
will require some reworking of the way that the AOT compiler works to
fix this, and I'd rather do that in a later patch.
Thank you.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From Yang.Zhang at arm.com Mon Apr 23 10:52:16 2018
From: Yang.Zhang at arm.com (Yang Zhang)
Date: Mon, 23 Apr 2018 10:52:16 +0000
Subject: 8185505: AArch64: Port AOT
In-Reply-To: <a7cdcca0-d2e4-7285-51f4-d12420dd0d0e@redhat.com>
References: <b439eaf0-e026-7ff8-e832-3717368027e4@redhat.com>
<AM5PR0802MB2449400467C4E4042C3C6A6390B00@AM5PR0802MB2449.eurprd08.prod.outlook.com>
<57767253-4826-e5b4-d142-7990d7114704@redhat.com>
<4626be6e-7927-a8ad-dead-1c3a4fca3ec9@oracle.com>
<5147cd22-8c3c-d72f-bf5d-0ef384eac45c@oracle.com>
<VI1PR0802MB2445EFDDB61AD73E87B99AC08E890@VI1PR0802MB2445.eurprd08.prod.outlook.com>
<a7cdcca0-d2e4-7285-51f4-d12420dd0d0e@redhat.com>
Message-ID: <VI1PR0802MB2445382BFADDDC78C1C7123F8E890@VI1PR0802MB2445.eurprd08.prod.outlook.com>
Hi Andrew
Thanks for your explanation and your great work on AOT. Hoping your patches can be merged ASAP.
Regards
Yang
-----Original Message-----
From: Andrew Haley <aph at redhat.com>
Sent: Monday, April 23, 2018 6:38 PM
To: Yang Zhang <Yang.Zhang at arm.com>; Vladimir Kozlov <vladimir.kozlov at oracle.com>; Ningsheng Jian <Ningsheng.Jian at arm.com>; hotspot-dev at openjdk.java.net?
Cc: nd <nd at arm.com>
Subject: Re: 8185505: AArch64: Port AOT
On 04/23/2018 08:14 AM, Yang Zhang wrote:
> I have tested the patches in my environment. AOT test cases in jtreg
> are passed, and there aren't new failed cases in hotspot jtreg on no
> matter aarch64 or x86 platform.
> But when using jaotc to compile java.base with an option
> "--compile-for-tiered", there is an overflow error on aarch64
> platform. There isn't such an error on x86 platform.
Yep, I know that. It's because there is a 30-bit limit in the range of a branch, and if we have a very large text section the offset to the PLT stub may be out of range. There is some logic in the GNU linker to handle this, and I'll haver a look at how it works.
I don't want to hold up this patch for the overflow issue for two reasons. Firstly, if you use such a huge AOT-compiled binary your performance will suffer greatly. It makes much more sense to compile only what you need because otherwise your startup time will actually be slower than not using AOT compilation at all. Secondly, I think it will require some reworking of the way that the AOT compiler works to fix this, and I'd rather do that in a later patch.
Thank you.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From thomas.schatzl at oracle.com Mon Apr 23 11:12:50 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 23 Apr 2018 13:12:50 +0200
Subject: RFR: 8202082: Remove explicit CMS checks in
CardTableBarrierSetAssembler
In-Reply-To: <5AD9FC94.70607@oracle.com>
References: <5AD9FC94.70607@oracle.com>
Message-ID: <1524481970.2450.0.camel@oracle.com>
Hi,
On Fri, 2018-04-20 at 16:43 +0200, Erik ?sterlund wrote:
> Hi,
>
> In CardTableBarrierSetAssembler, we sometimes need fencing due to
> the
> card table being scanned concurrently when using CMS with pre-
> cleaning.
> Rather than explicitly checking for those CMS flags in the generic
> CardTableBarrierSetAssembler class, it is preferrable to check the
> CardTable scanned_concurrently() property which already precisely
> reflects that.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8202082
>
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.00/
looks good.
Thomas
From erik.osterlund at oracle.com Mon Apr 23 11:26:56 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Mon, 23 Apr 2018 13:26:56 +0200
Subject: RFR: 8202082: Remove explicit CMS checks in
CardTableBarrierSetAssembler
In-Reply-To: <1524481970.2450.0.camel@oracle.com>
References: <5AD9FC94.70607@oracle.com> <1524481970.2450.0.camel@oracle.com>
Message-ID: <5ADDC300.2@oracle.com>
Hi Thomas,
Thanks for the review.
/Erik
On 2018-04-23 13:12, Thomas Schatzl wrote:
> Hi,
>
> On Fri, 2018-04-20 at 16:43 +0200, Erik ?sterlund wrote:
>> Hi,
>>
>> In CardTableBarrierSetAssembler, we sometimes need fencing due to
>> the
>> card table being scanned concurrently when using CMS with pre-
>> cleaning.
>> Rather than explicitly checking for those CMS flags in the generic
>> CardTableBarrierSetAssembler class, it is preferrable to check the
>> CardTable scanned_concurrently() property which already precisely
>> reflects that.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8202082
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.00/
> looks good.
>
> Thomas
From gerard.ziemski at oracle.com Mon Apr 23 17:53:15 2018
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Mon, 23 Apr 2018 12:53:15 -0500
Subject: RFR: 8202151: [BACKOUT] Split globals.hpp to factor out the Flag class
Message-ID: <54C5C715-1015-4993-A4A9-EE40E60FA51D@oracle.com>
Please review this hg generated backout change, the original fix needs more work:
https://bugs.openjdk.java.net/browse/JDK-8202151
http://cr.openjdk.java.net/~gziemski/8202151_rev1/webrev/
cheers
From vladimir.kozlov at oracle.com Mon Apr 23 18:11:22 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 23 Apr 2018 11:11:22 -0700
Subject: 8185505: AArch64: Port AOT
In-Reply-To: <a7cdcca0-d2e4-7285-51f4-d12420dd0d0e@redhat.com>
References: <b439eaf0-e026-7ff8-e832-3717368027e4@redhat.com>
<AM5PR0802MB2449400467C4E4042C3C6A6390B00@AM5PR0802MB2449.eurprd08.prod.outlook.com>
<57767253-4826-e5b4-d142-7990d7114704@redhat.com>
<4626be6e-7927-a8ad-dead-1c3a4fca3ec9@oracle.com>
<5147cd22-8c3c-d72f-bf5d-0ef384eac45c@oracle.com>
<VI1PR0802MB2445EFDDB61AD73E87B99AC08E890@VI1PR0802MB2445.eurprd08.prod.outlook.com>
<a7cdcca0-d2e4-7285-51f4-d12420dd0d0e@redhat.com>
Message-ID: <14d2bee3-80fd-e614-d737-b44b87962447@oracle.com>
On 4/23/18 3:38 AM, Andrew Haley wrote:
> On 04/23/2018 08:14 AM, Yang Zhang wrote:
>
>> I have tested the patches in my environment. AOT test cases in jtreg
>> are passed, and there aren't new failed cases in hotspot jtreg on no
>> matter aarch64 or x86 platform.
>> But when using jaotc to compile java.base with an option
>> "--compile-for-tiered", there is an overflow error on aarch64
>> platform. There isn't such an error on x86 platform.
>
> Yep, I know that. It's because there is a 30-bit limit in the range
> of a branch, and if we have a very large text section the offset to
> the PLT stub may be out of range. There is some logic in the GNU
> linker to handle this, and I'll haver a look at how it works.
>
> I don't want to hold up this patch for the overflow issue for two
> reasons. Firstly, if you use such a huge AOT-compiled binary your
> performance will suffer greatly. It makes much more sense to compile
> only what you need because otherwise your startup time will actually
> be slower than not using AOT compilation at all. Secondly, I think it
> will require some reworking of the way that the AOT compiler works to
> fix this, and I'd rather do that in a later patch.
Yes, I agree with this.
Thanks,
Vladimir
>
> Thank you.
>
From vladimir.kozlov at oracle.com Mon Apr 23 18:17:11 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 23 Apr 2018 11:17:11 -0700
Subject: RFR: 8201543: Modularize C1 GC barriers
In-Reply-To: <5AD9EFE3.4020203@oracle.com>
References: <5AD0C89E.7050807@oracle.com> <5AD9EFE3.4020203@oracle.com>
Message-ID: <701a63b0-0270-992a-2602-6ee1f7082ab2@oracle.com>
Hi Erik,
I would suggest for Rickard and Nils become reviewers of these changes
since they more than anyone in our group know about them. The should do
review on this thread.
And CCing to Graal group because Graal may need to be changes too.
Thanks,
Vladimir
On 4/20/18 6:49 AM, Erik ?sterlund wrote:
> Hi everyone,
>
> I sat down with Rickard and Per at the office to have a look at this,
> and have built a new webrev based on their feedback.
> The main elements in the delta are the following:
>
> 1) Wrap various context information that is passed around in the
> BarrierSetC1 hierarchy in a wrapper object (to reduce boiler plate),
> that has been named LIRAccess. It contains the address elements (base
> and offset, as either LIRItem or LIROpr), as well as the decorators, and
> the CodeEmitInfo of the address (for patching), the CodeEmitInfo for the
> access (for things like implicit null checks), and the LIRGenerator
> instance, that would normally be passed around to every function.
> 2) Added #ifdef COMPILER1 in the G1BarrierSetC1 classes to be polite to
> people trying to build HotSpot with a generated interpreter but no C1
> compiler.
> 3) Added a decorator_fixup() method that applies various implicit
> decorator rules for sane defaults (for example, IN_HEAP_ARRAY implies
> IN_HEAP). This is a 1:1 mirror to the DecoratorFixup meta function used
> in the runtime backend. Both are now located in accessDecorator.hpp. One
> for use by templates (DecoratorFixup), and one for use by code
> generators that do not use templates (decorator_fixup()).
> 4) Removed some unnecessary includes and friend class declarations.
> 5) Made BarrierSetC1 a member of LIRGenerator to reduce boiler plate
> further.
> 6) Changed name of the lir_generator variable passed around to gen, to
> be consistent with what other code in C1 does when passing around the
> LIRGenerator instance.
>
> Incremental webrev:
> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.00_01/
>
> Full webrev:
> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.01/
>
> Big thanks to Rickard and Per for having a look at this.
>
> Thanks,
> /Erik
>
> On 2018-04-13 17:11, Erik ?sterlund wrote:
>> Hi,
>>
>> The GC barriers for C1 are not as modular as they could be. It
>> currently uses switch statements to check which GC barrier set is
>> being used, and calls one or another barrier based on that, in a way
>> that it can only be used for write barriers.
>>
>> The solution I propose is to add the same facilities that have been
>> added in runtime and the interpreter already: a barrier set backend
>> for C1. I call it BarrierSetC1, and it helps us generate decorated
>> accesses that give the GC control over the details how to generate
>> this access. It recognizes the same decorators (accessDecorators.hpp)
>> that the other parts of the VM recognize. Each concrete barrier set
>> has its own backend. For now, these are CardTableBarrierSetC1 and
>> G1BarrierSetC1, but this should pave way for upcoming concurrently
>> compacting GCs as well.
>>
>> Two decorators were added for C1 specifically (found in
>> c1_Decorators.hpp):
>> C1_NEEDS_PATCHING for accesses where the index is not yet load because
>> the class has yet to be loaded, and
>> C1_MASK_BOOLEAN for accesses that need to mask untrusted boolean values.
>>
>> LIRGenerator calls a wrapper called access_store_at, access_load_at,
>> etc (there are variants for cpmxchg, xchg and atomic add as well).
>> The access call calls straight into the BarrierSetC1 hierarchy using
>> virtual calls. It is structured in a way very similar to
>> BarrierSetAssembler.
>>
>> BarrierSetC1 can also be called during initialization to generate
>> stubs and runtime methods required by C1. For G1BarrierSetC1, this
>> results in calling the BarrierSetAssembler for the platform specific
>> code. This way, the BarrierSetC1 hierarchy has been carefully kept in
>> shared code, and the switch statements for generating G1 code have
>> been removed. Some code that used to be platform specific (like unsafe
>> get/set and array store) have been broken out to shared code, with the
>> actual platform specific details (some register allocation for store
>> check and atomics) broken out to platform specific methods. This way,
>> calls to access are kept in platform specific code.
>>
>> As usual, big thanks go to Martin Doerr for helping out with S390 and
>> PPC, and Roman for taking care of AArch64.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8201543
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.00/
>>
>> Thanks,
>> /Erik
>
From vladimir.kozlov at oracle.com Mon Apr 23 18:22:34 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 23 Apr 2018 11:22:34 -0700
Subject: RFR: 8202151: [BACKOUT] Split globals.hpp to factor out the Flag
class
In-Reply-To: <54C5C715-1015-4993-A4A9-EE40E60FA51D@oracle.com>
References: <54C5C715-1015-4993-A4A9-EE40E60FA51D@oracle.com>
Message-ID: <12511ebc-3b33-a417-b4d9-c03d9478ca9d@oracle.com>
Looks good.
Can you say what happened?
Thanks,
Vladimir
On 4/23/18 10:53 AM, Gerard Ziemski wrote:
> Please review this hg generated backout change, the original fix needs more work:
>
> https://bugs.openjdk.java.net/browse/JDK-8202151
> http://cr.openjdk.java.net/~gziemski/8202151_rev1/webrev/
>
>
> cheers
>
From gerard.ziemski at oracle.com Mon Apr 23 18:27:29 2018
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Mon, 23 Apr 2018 13:27:29 -0500
Subject: RFR: 8202151: [BACKOUT] Split globals.hpp to factor out the Flag
class
In-Reply-To: <12511ebc-3b33-a417-b4d9-c03d9478ca9d@oracle.com>
References: <54C5C715-1015-4993-A4A9-EE40E60FA51D@oracle.com>
<12511ebc-3b33-a417-b4d9-c03d9478ca9d@oracle.com>
Message-ID: <31198199-0E0E-47B1-8B60-507B1FE4068F@oracle.com>
Thank you!
I merged from jdk/hs to jdk/jdk and forgot to test against ?open? part again, and something broke in there.
cheers
> On Apr 23, 2018, at 1:22 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
> Looks good.
>
> Can you say what happened?
>
> Thanks,
> Vladimir
>
> On 4/23/18 10:53 AM, Gerard Ziemski wrote:
>> Please review this hg generated backout change, the original fix needs more work:
>> https://bugs.openjdk.java.net/browse/JDK-8202151
>> http://cr.openjdk.java.net/~gziemski/8202151_rev1/webrev/
>> cheers
From vladimir.kozlov at oracle.com Mon Apr 23 19:03:32 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 23 Apr 2018 12:03:32 -0700
Subject: RFC: C2 Object Initialization - Using XMM/YMM registers
In-Reply-To: <CAPVMLfUfCOhRYH0XiY+jx6VewqFYFmKuOZPq8xrUBVGt7RqeVg@mail.gmail.com>
References: <CAPVMLfVcpTXpaTeMwo0Gg=NgDpkz+Z2cD+FP7mw6iHJH5R-+nw@mail.gmail.com>
<f21029be-c4a7-8104-6d4b-e6bbd13525b9@oracle.com>
<CAPVMLfUfCOhRYH0XiY+jx6VewqFYFmKuOZPq8xrUBVGt7RqeVg@mail.gmail.com>
Message-ID: <6ddfaac5-a5ad-dc27-8185-d2237a5b1695@oracle.com>
Sorry for delay.
In general you can't use arbitrary registers without letting know JIT
compilers that you use it. It will definitely cause problems.
You need to pass it as additional XMMRegister argument and described it
as TEMP in .ad files.
See byte_array_inflate() as example.
On 4/11/18 7:25 PM, Rohit Arul Raj wrote:
>>> When I use XMM0 as a temporary register, the micro-benchmark crashes.
>>> Saving and Restoring the XMM0 register before and after use works
>>> fine.
>>>
>>> Looking at the "hotspot/src/cpu/x86/vm/x86.ad" file, XMM0 as with
>>> other XMM registers has been mentioned as Save-On-Call registers and
>>> on Linux ABI, no register is preserved across function calls though
>>> XMM0-XMM7 might hold parameters. So I assumed using XMM0 without
>>> saving/restoring should be fine.
>>>
>>> Is it incorrect use XMM* registers without saving/restoring them?
>>> Using XMM10 register as temporary register works fine without having
>>> to save and restore it.
>
> Any comments/suggestions on the usage of XMM* registers?
>
> Thanks,
> Rohit
>
> On Thu, Apr 5, 2018 at 11:38 PM, Vladimir Kozlov
> <vladimir.kozlov at oracle.com> wrote:
>> Good suggestion, Rohit
>>
>> I created new RFE. Please add you suggestion and performance data there:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8201193
>>
>> Thanks,
>> Vladimir
>>
>>
>> On 4/5/18 12:19 AM, Rohit Arul Raj wrote:
>>>
>>> Hi All,
>>>
>>> I was going through the C2 object initialization (zeroing) code based
>>> on the below bug entry:
>>> https://bugs.openjdk.java.net/browse/JDK-8146801
>>>
>>> Right now, for longer lengths we use "rep stos" instructions on x86. I
>>> was experimenting with using XMM/YMM registers (on AMD EPYC processor)
>>> and found that they do improve performance for certain lengths:
>>>
>>> For lengths > 64 bytes - 512 bytes : improvement is in the range of 8% to
>>> 44%
>>> For lengths > 512bytes : some lengths show slight
>>> improvement in the range of 2% to 7%, others almost same as "rep stos"
>>> numbers.
>>>
>>> I have attached the complete performance data (data.txt) for reference .
>>> Can we add this as an user option similar to UseXMMForArrayCopy?
>>>
>>> I have used the same test case as in
>>> (http://cr.openjdk.java.net/~shade/8146801/benchmarks.jar) with
>>> additional sizes.
>>>
>>> Initial Patch:
>>> I haven't added the check for 32-bit mode as I need some help with the
>>> code (description given below the patch).
>>> The code is similar to the one used in array copy stubs
>>> (copy_bytes_forward).
>>>
>>> diff --git a/src/hotspot/cpu/x86/globals_x86.hpp
>>> b/src/hotspot/cpu/x86/globals_x86.hpp
>>> --- a/src/hotspot/cpu/x86/globals_x86.hpp
>>> +++ b/src/hotspot/cpu/x86/globals_x86.hpp
>>> @@ -150,6 +150,9 @@
>>> product(bool, UseUnalignedLoadStores, false,
>>> \
>>> "Use SSE2 MOVDQU instruction for Arraycopy")
>>> \
>>>
>>> \
>>> + product(bool, UseXMMForObjInit, false,
>>> \
>>> + "Use XMM/YMM MOVDQU instruction for Object Initialization")
>>> \
>>> +
>>> \
>>> product(bool, UseFastStosb, false,
>>> \
>>> "Use fast-string operation for zeroing: rep stosb")
>>> \
>>>
>>> \
>>> diff --git a/src/hotspot/cpu/x86/macroAssembler_x86.cpp
>>> b/src/hotspot/cpu/x86/macroAssembler_x86.cpp
>>> --- a/src/hotspot/cpu/x86/macroAssembler_x86.cpp
>>> +++ b/src/hotspot/cpu/x86/macroAssembler_x86.cpp
>>> @@ -7106,6 +7106,56 @@
>>> if (UseFastStosb) {
>>> shlptr(cnt, 3); // convert to number of bytes
>>> rep_stosb();
>>> + } else if (UseXMMForObjInit && UseUnalignedLoadStores) {
>>> + Label L_loop, L_sloop, L_check, L_tail, L_end;
>>> + push(base);
>>> + if (UseAVX >= 2)
>>> + vpxor(xmm10, xmm10, xmm10, AVX_256bit);
>>> + else
>>> + vpxor(xmm10, xmm10, xmm10, AVX_128bit);
>>> +
>>> + jmp(L_check);
>>> +
>>> + BIND(L_loop);
>>> + if (UseAVX >= 2) {
>>> + vmovdqu(Address(base, 0), xmm10);
>>> + vmovdqu(Address(base, 32), xmm10);
>>> + } else {
>>> + movdqu(Address(base, 0), xmm10);
>>> + movdqu(Address(base, 16), xmm10);
>>> + movdqu(Address(base, 32), xmm10);
>>> + movdqu(Address(base, 48), xmm10);
>>> + }
>>> + addptr(base, 64);
>>> +
>>> + BIND(L_check);
>>> + subptr(cnt, 8);
>>> + jccb(Assembler::greaterEqual, L_loop);
>>> + addptr(cnt, 4);
>>> + jccb(Assembler::less, L_tail);
>>> + // Copy trailing 32 bytes
>>> + if (UseAVX >= 2) {
>>> + vmovdqu(Address(base, 0), xmm10);
>>> + } else {
>>> + movdqu(Address(base, 0), xmm10);
>>> + movdqu(Address(base, 16), xmm10);
>>> + }
>>> + addptr(base, 32);
>>> + subptr(cnt, 4);
>>> +
>>> + BIND(L_tail);
>>> + addptr(cnt, 4);
>>> + jccb(Assembler::lessEqual, L_end);
>>> + decrement(cnt);
>>> +
>>> + BIND(L_sloop);
>>> + movptr(Address(base, 0), tmp);
>>> + addptr(base, 8);
>>> + decrement(cnt);
>>> + jccb(Assembler::greaterEqual, L_sloop);
>>> +
>>> + BIND(L_end);
>>> + pop(base);
>>> } else {
>>> NOT_LP64(shlptr(cnt, 1);) // convert to number of 32-bit words
>>> for 32-bit VM
>>> rep_stos();
>>>
>>>
>>> When I use XMM0 as a temporary register, the micro-benchmark crashes.
>>> Saving and Restoring the XMM0 register before and after use works
>>> fine.
>>>
>>> Looking at the "hotspot/src/cpu/x86/vm/x86.ad" file, XMM0 as with
>>> other XMM registers has been mentioned as Save-On-Call registers and
>>> on Linux ABI, no register is preserved across function calls though
>>> XMM0-XMM7 might hold parameters. So I assumed using XMM0 without
>>> saving/restoring should be fine.
>>>
>>> Is it incorrect use XMM* registers without saving/restoring them?
>>> Using XMM10 register as temporary register works fine without having
>>> to save and restore it.
>>>
>>> Please let me know your comments.
>>>
>>> Regards,
>>> Rohit
>>>
>>
From kim.barrett at oracle.com Mon Apr 23 19:19:44 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 23 Apr 2018 15:19:44 -0400
Subject: RFR: build pragma error with gcc 4.4.7
In-Reply-To: <CABi63P5FPbfdw9jynsKHa+i7=T1kaSJsyEC7tZ6eW0pZZx8Tbg@mail.gmail.com>
References: <3196d61c-9b7c-b795-a68d-6e50a3416f41@redhat.com>
<01173273-2A13-4FE0-81EE-3C50954D7A90@oracle.com>
<CABi63P5FPbfdw9jynsKHa+i7=T1kaSJsyEC7tZ6eW0pZZx8Tbg@mail.gmail.com>
Message-ID: <6E53C24C-D579-4247-BE27-79BE59EF3678@oracle.com>
> On Apr 21, 2018, at 11:18 AM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>
> On 19 March 2018 at 23:23, Kim Barrett <kim.barrett at oracle.com> wrote:
>> There are also problems with the patch as provided.
>>
>> (1) Since PRAGMA_DIAG_PUSH/POP do nothing in the version of gcc this
>> change is being made in support of, the warning would be disabled for
>> all following code in any translation unit that includes this file.
>> That doesn't seem good.
>
> No, but it's really the only solution on those compilers. We have such
> usage already elsewhere e.g.
>
> // Silence -Wformat-security warning for fatal()
> PRAGMA_DIAG_PUSH
> PRAGMA_FORMAT_NONLITERAL_IGNORED
> fatal(buf);
> PRAGMA_DIAG_POP
> return true; // silence compiler warnings
> }
> in src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp
>
> If there are other warnings, then they will picked up on newer compilers,
> especially when building with -Werror. I don't think it's likely people are
> doing development on older compilers, but rather that we have to use
> them to build for older platforms.
I would be a lot more comfortable if the possibly do-nothing push/pop and
the associated code were in a .cpp file, rather than in a .hpp file where it
could affect some open-ended and unexpected set of code.
But I think this is moot if os::readdir can be changed to call ::readdir rather
than ::readdir_r, as appears to be the case, possibly with some documentation
about not sharing the DIR* among multiple threads, at least not without locking.
That seemed to be what Michal was planning to do, but hasn?t gotten back to
it yet.
From vladimir.kozlov at oracle.com Mon Apr 23 19:20:52 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 23 Apr 2018 12:20:52 -0700
Subject: [11] RFR(XS) 8202152:
test/hotspot/jtreg/runtime/whitebox/WBStackSize.java fails
Message-ID: <074d0bb7-4d1e-91a2-541f-50ecd9eb4cb6@oracle.com>
http://cr.openjdk.java.net/~kvn/8202152/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8202152
After 8198756 changes compiler threads could be released and other Java
threads can re-use the same HW threads for which stack size was
determined during start. The test WBStackSize.java may fail in such
cases because Java thread stack size is set and checked in test.
For 8198756 changes we added thread name check to workaround the problem
[1]. But it seems is not enough.
To avoid this issue I added -XX:CompilerThreadStackSize=512 flag to
match Java thread stack size (note, size is in Kb for this flag).
I also reverted changes in test code and instead added thread name print
to know in case we still have problem in a future.
Tier1 testing (which run the test) passed.
--
Thanks,
Vladimir
[1] http://hg.openjdk.java.net/jdk/jdk/rev/fcd5df7aa235#l6.1
From vicente.romero at oracle.com Mon Apr 23 19:37:21 2018
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 23 Apr 2018 15:37:21 -0400
Subject: Fwd: Large page use crashes the JVM on some Linux systems
In-Reply-To: <CAEgw74ApMVY2EiYwWN6UZcbCx6dQZMt2bCKMuMM_2rY4nCjGWA@mail.gmail.com>
References: <CAEgw74ApMVY2EiYwWN6UZcbCx6dQZMt2bCKMuMM_2rY4nCjGWA@mail.gmail.com>
Message-ID: <18e41612-42c5-02b4-b9ae-898e546fe214@oracle.com>
forwarding to hotspot-dev
-------- Forwarded Message --------
Subject: Large page use crashes the JVM on some Linux systems
Date: Sun, 22 Apr 2018 23:18:50 +0200
From: B. Blaser <bsrbnd at gmail.com>
To: amber-dev at openjdk.java.net
[ I've trouble subscribing to hotspot-dev, please forward if necessary. ]
Hi,
After a clean build, some hotspot tests related to large page use are
failing on my 64-bit Linux system, for example:
gc/g1/TestLargePageUseForAuxMemory.java
[...]
Or simply:
$ ./build/linux-x86_64-normal-server-release/images/jdk/bin/java
-XX:+UseLargePages -version
is crashing the JVM because the latter assumes that large pages are
always supported on Linux, which appears to be wrong.
I suggest to make sure that large pages are supported when parsing the
arguments, as below.
Does this look reasonable (tier1 looks better now)?
Thanks,
Bernard
diff -r 8c85a1855e10 src/hotspot/share/runtime/arguments.cpp
--- a/src/hotspot/share/runtime/arguments.cpp Fri Apr 13 11:14:49 2018 -0700
+++ b/src/hotspot/share/runtime/arguments.cpp Sun Apr 22 20:29:21 2018 +0200
@@ -60,6 +60,7 @@
#include "utilities/defaultStream.hpp"
#include "utilities/macros.hpp"
#include "utilities/stringUtils.hpp"
+#include "sys/mman.h"
#if INCLUDE_JVMCI
#include "jvmci/jvmciRuntime.hpp"
#endif
@@ -4107,6 +4108,18 @@
UNSUPPORTED_OPTION(UseLargePages);
#endif
+#ifdef LINUX
+ void *p = mmap(NULL, os::large_page_size(), PROT_READ|PROT_WRITE,
+ MAP_ANONYMOUS|MAP_PRIVATE|MAP_HUGETLB,
+ -1, 0);
+ if (p != MAP_FAILED) {
+ munmap(p, os::large_page_size());
+ }
+ else {
+ UNSUPPORTED_OPTION(UseLargePages);
+ }
+#endif
+
ArgumentsExt::report_unsupported_options();
#ifndef PRODUCT
diff -r 8c85a1855e10
test/hotspot/jtreg/runtime/memory/LargePages/TestLargePagesFlags.java
--- a/test/hotspot/jtreg/runtime/memory/LargePages/TestLargePagesFlags.java
Fri Apr 13 11:14:49 2018 -0700
+++ b/test/hotspot/jtreg/runtime/memory/LargePages/TestLargePagesFlags.java
Sun Apr 22 20:29:21 2018 +0200
@@ -37,7 +37,7 @@
public class TestLargePagesFlags {
public static void main(String [] args) throws Exception {
- if (!Platform.isLinux()) {
+ if (!Platform.isLinux() || !canUse(UseLargePages(true))) {
System.out.println("Skipping. TestLargePagesFlags has only been
implemented for Linux.");
return;
}
From doug.simon at oracle.com Mon Apr 23 19:40:07 2018
From: doug.simon at oracle.com (Doug Simon)
Date: Mon, 23 Apr 2018 21:40:07 +0200
Subject: RFR: 8201543: Modularize C1 GC barriers
In-Reply-To: <701a63b0-0270-992a-2602-6ee1f7082ab2@oracle.com>
References: <5AD0C89E.7050807@oracle.com> <5AD9EFE3.4020203@oracle.com>
<701a63b0-0270-992a-2602-6ee1f7082ab2@oracle.com>
Message-ID: <4D2A4EB2-6FBD-4893-BFFA-E1F081D1490A@oracle.com>
Since I don't see any C2 changes, I assume this is a pure interface change at the C++ level and no change to GC barrier semantics or layout. In that case, I don't believe any Graal changes should be necessary.
-Doug
> On 23 Apr 2018, at 20:17, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
> Hi Erik,
>
> I would suggest for Rickard and Nils become reviewers of these changes since they more than anyone in our group know about them. The should do review on this thread.
>
> And CCing to Graal group because Graal may need to be changes too.
>
> Thanks,
> Vladimir
>
> On 4/20/18 6:49 AM, Erik ?sterlund wrote:
>> Hi everyone,
>> I sat down with Rickard and Per at the office to have a look at this, and have built a new webrev based on their feedback.
>> The main elements in the delta are the following:
>> 1) Wrap various context information that is passed around in the BarrierSetC1 hierarchy in a wrapper object (to reduce boiler plate), that has been named LIRAccess. It contains the address elements (base and offset, as either LIRItem or LIROpr), as well as the decorators, and the CodeEmitInfo of the address (for patching), the CodeEmitInfo for the access (for things like implicit null checks), and the LIRGenerator instance, that would normally be passed around to every function.
>> 2) Added #ifdef COMPILER1 in the G1BarrierSetC1 classes to be polite to people trying to build HotSpot with a generated interpreter but no C1 compiler.
>> 3) Added a decorator_fixup() method that applies various implicit decorator rules for sane defaults (for example, IN_HEAP_ARRAY implies IN_HEAP). This is a 1:1 mirror to the DecoratorFixup meta function used in the runtime backend. Both are now located in accessDecorator.hpp. One for use by templates (DecoratorFixup), and one for use by code generators that do not use templates (decorator_fixup()).
>> 4) Removed some unnecessary includes and friend class declarations.
>> 5) Made BarrierSetC1 a member of LIRGenerator to reduce boiler plate further.
>> 6) Changed name of the lir_generator variable passed around to gen, to be consistent with what other code in C1 does when passing around the LIRGenerator instance.
>> Incremental webrev:
>> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.00_01/
>> Full webrev:
>> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.01/
>> Big thanks to Rickard and Per for having a look at this.
>> Thanks,
>> /Erik
>> On 2018-04-13 17:11, Erik ?sterlund wrote:
>>> Hi,
>>>
>>> The GC barriers for C1 are not as modular as they could be. It currently uses switch statements to check which GC barrier set is being used, and calls one or another barrier based on that, in a way that it can only be used for write barriers.
>>>
>>> The solution I propose is to add the same facilities that have been added in runtime and the interpreter already: a barrier set backend for C1. I call it BarrierSetC1, and it helps us generate decorated accesses that give the GC control over the details how to generate this access. It recognizes the same decorators (accessDecorators.hpp) that the other parts of the VM recognize. Each concrete barrier set has its own backend. For now, these are CardTableBarrierSetC1 and G1BarrierSetC1, but this should pave way for upcoming concurrently compacting GCs as well.
>>>
>>> Two decorators were added for C1 specifically (found in c1_Decorators.hpp):
>>> C1_NEEDS_PATCHING for accesses where the index is not yet load because the class has yet to be loaded, and
>>> C1_MASK_BOOLEAN for accesses that need to mask untrusted boolean values.
>>>
>>> LIRGenerator calls a wrapper called access_store_at, access_load_at, etc (there are variants for cpmxchg, xchg and atomic add as well).
>>> The access call calls straight into the BarrierSetC1 hierarchy using virtual calls. It is structured in a way very similar to BarrierSetAssembler.
>>>
>>> BarrierSetC1 can also be called during initialization to generate stubs and runtime methods required by C1. For G1BarrierSetC1, this results in calling the BarrierSetAssembler for the platform specific code. This way, the BarrierSetC1 hierarchy has been carefully kept in shared code, and the switch statements for generating G1 code have been removed. Some code that used to be platform specific (like unsafe get/set and array store) have been broken out to shared code, with the actual platform specific details (some register allocation for store check and atomics) broken out to platform specific methods. This way, calls to access are kept in platform specific code.
>>>
>>> As usual, big thanks go to Martin Doerr for helping out with S390 and PPC, and Roman for taking care of AArch64.
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8201543
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.00/
>>>
>>> Thanks,
>>> /Erik
From rkennke at redhat.com Mon Apr 23 20:32:27 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Mon, 23 Apr 2018 22:32:27 +0200
Subject: RFR: 8201543: Modularize C1 GC barriers
In-Reply-To: <5AD9EFE3.4020203@oracle.com>
References: <5AD0C89E.7050807@oracle.com> <5AD9EFE3.4020203@oracle.com>
Message-ID: <ca47d015-a9a6-55c4-267c-50a674619fb4@redhat.com>
I've taken a cursory look at it. I like the way it looks :-) Thank so
*SO MUCH* for this work!
- At first I was confused about the additional indirection of LIRAccess.
But it looks like this is mostly/completely hidden from the actual
consumer of the API, which would call, e.g. access_load_at() ?
- At the same time, do you think the resolve_address() provides a place
for GC like Shenandoah that needs to resolve the base object and insert
a read/write-barrier and *then* resolve the barrier(base)+offset? If
this is the intention, may I request to somehow carry over the
information whether or not the address is intended for read or write?
Because we need insert different barriers on reads vs writes. Maybe this
can be added in the decorators?
- Or is the intention to resolve the base object on the actual
load_at_resolved() etc entry points? As far as I can tell this would be
difficult because we don't get to see the base object anymore?
- Thinking forward a little bit... Shenandoah is going to need some
resolve-hooks in a couple of places that are not practical to handle via
load/store style access calls. For example in monitorenter/exit code we
need to insert a write-barrier on the object to be synchronized on. Will
this be possible/practical to do via resolve_address()?
- Does it already handle primitive accesses? From the looks of it, I'd
say yes. That'd be nice.
The rest of it looks nice from afar, but I haven't really looked deeper
yet. I will poke around some more and probably will have more questions...
Thanks again!
Cheers, Roman
> Hi everyone,
>
> I sat down with Rickard and Per at the office to have a look at this,
> and have built a new webrev based on their feedback.
> The main elements in the delta are the following:
>
> 1) Wrap various context information that is passed around in the
> BarrierSetC1 hierarchy in a wrapper object (to reduce boiler plate),
> that has been named LIRAccess. It contains the address elements (base
> and offset, as either LIRItem or LIROpr), as well as the decorators, and
> the CodeEmitInfo of the address (for patching), the CodeEmitInfo for the
> access (for things like implicit null checks), and the LIRGenerator
> instance, that would normally be passed around to every function.
> 2) Added #ifdef COMPILER1 in the G1BarrierSetC1 classes to be polite to
> people trying to build HotSpot with a generated interpreter but no C1
> compiler.
> 3) Added a decorator_fixup() method that applies various implicit
> decorator rules for sane defaults (for example, IN_HEAP_ARRAY implies
> IN_HEAP). This is a 1:1 mirror to the DecoratorFixup meta function used
> in the runtime backend. Both are now located in accessDecorator.hpp. One
> for use by templates (DecoratorFixup), and one for use by code
> generators that do not use templates (decorator_fixup()).
> 4) Removed some unnecessary includes and friend class declarations.
> 5) Made BarrierSetC1 a member of LIRGenerator to reduce boiler plate
> further.
> 6) Changed name of the lir_generator variable passed around to gen, to
> be consistent with what other code in C1 does when passing around the
> LIRGenerator instance.
>
> Incremental webrev:
> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.00_01/
>
> Full webrev:
> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.01/
>
> Big thanks to Rickard and Per for having a look at this.
>
> Thanks,
> /Erik
>
> On 2018-04-13 17:11, Erik ?sterlund wrote:
>> Hi,
>>
>> The GC barriers for C1 are not as modular as they could be. It
>> currently uses switch statements to check which GC barrier set is
>> being used, and calls one or another barrier based on that, in a way
>> that it can only be used for write barriers.
>>
>> The solution I propose is to add the same facilities that have been
>> added in runtime and the interpreter already: a barrier set backend
>> for C1. I call it BarrierSetC1, and it helps us generate decorated
>> accesses that give the GC control over the details how to generate
>> this access. It recognizes the same decorators (accessDecorators.hpp)
>> that the other parts of the VM recognize. Each concrete barrier set
>> has its own backend. For now, these are CardTableBarrierSetC1 and
>> G1BarrierSetC1, but this should pave way for upcoming concurrently
>> compacting GCs as well.
>>
>> Two decorators were added for C1 specifically (found in
>> c1_Decorators.hpp):
>> C1_NEEDS_PATCHING for accesses where the index is not yet load because
>> the class has yet to be loaded, and
>> C1_MASK_BOOLEAN for accesses that need to mask untrusted boolean values.
>>
>> LIRGenerator calls a wrapper called access_store_at, access_load_at,
>> etc (there are variants for cpmxchg, xchg and atomic add as well).
>> The access call calls straight into the BarrierSetC1 hierarchy using
>> virtual calls. It is structured in a way very similar to
>> BarrierSetAssembler.
>>
>> BarrierSetC1 can also be called during initialization to generate
>> stubs and runtime methods required by C1. For G1BarrierSetC1, this
>> results in calling the BarrierSetAssembler for the platform specific
>> code. This way, the BarrierSetC1 hierarchy has been carefully kept in
>> shared code, and the switch statements for generating G1 code have
>> been removed. Some code that used to be platform specific (like unsafe
>> get/set and array store) have been broken out to shared code, with the
>> actual platform specific details (some register allocation for store
>> check and atomics) broken out to platform specific methods. This way,
>> calls to access are kept in platform specific code.
>>
>> As usual, big thanks go to Martin Doerr for helping out with S390 and
>> PPC, and Roman for taking care of AArch64.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8201543
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.00/
>>
>> Thanks,
>> /Erik
>
From david.holmes at oracle.com Mon Apr 23 21:24:27 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Apr 2018 07:24:27 +1000
Subject: [11] RFR(XS) 8202152:
test/hotspot/jtreg/runtime/whitebox/WBStackSize.java fails
In-Reply-To: <074d0bb7-4d1e-91a2-541f-50ecd9eb4cb6@oracle.com>
References: <074d0bb7-4d1e-91a2-541f-50ecd9eb4cb6@oracle.com>
Message-ID: <df053f49-ff6a-0c9e-1589-95b6a1dc5abb@oracle.com>
Hi Vladimir,
On 24/04/2018 5:20 AM, Vladimir Kozlov wrote:
> http://cr.openjdk.java.net/~kvn/8202152/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8202152
>
> After 8198756 changes compiler threads could be released and other Java
> threads can re-use the same HW threads for which stack size was
> determined during start. The test WBStackSize.java may fail in such
> cases because Java thread stack size is set and checked in test.
That does not make sense to me. We don't "re-use HW threads" - I'm not
even sure what that means. Compiler threads have a different stacksize
to other Java threads - that seems simple enough.
> For 8198756 changes we added thread name check to workaround the problem
> [1]. But it seems is not enough.
Why would this test be run in a compiler thread ????
> To avoid this issue I added -XX:CompilerThreadStackSize=512 flag to
> match Java thread stack size (note, size is in Kb for this flag).
That seems like a workaround of the real problem.
David
-----
> I also reverted changes in test code and instead added thread name print
> to know in case we still have problem in a future.
>
> Tier1 testing (which run the test) passed.
>
From erik.osterlund at oracle.com Mon Apr 23 21:34:08 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Mon, 23 Apr 2018 23:34:08 +0200
Subject: RFR: 8201543: Modularize C1 GC barriers
In-Reply-To: <ca47d015-a9a6-55c4-267c-50a674619fb4@redhat.com>
References: <5AD0C89E.7050807@oracle.com> <5AD9EFE3.4020203@oracle.com>
<ca47d015-a9a6-55c4-267c-50a674619fb4@redhat.com>
Message-ID: <fee256d2-c693-c9fc-23ac-d47b6cb38c2a@oracle.com>
Hi Roman,
On 2018-04-23 22:32, Roman Kennke wrote:
> I've taken a cursory look at it. I like the way it looks :-) Thank so
> *SO MUCH* for this work!
I'm glad you like it.
> - At first I was confused about the additional indirection of LIRAccess.
> But it looks like this is mostly/completely hidden from the actual
> consumer of the API, which would call, e.g. access_load_at() ?
Yes indeed. This is only a wrapper object for the shared state of all
accesses, to reduce boiler plate code when passing around the same
famous suspects all over the backends. But the caller does not need to
know about them.
> - At the same time, do you think the resolve_address() provides a place
> for GC like Shenandoah that needs to resolve the base object and insert
> a read/write-barrier and *then* resolve the barrier(base)+offset? If
> this is the intention, may I request to somehow carry over the
> information whether or not the address is intended for read or write?
> Because we need insert different barriers on reads vs writes. Maybe this
> can be added in the decorators?
Yes that was my intention indeed. I added in a C1_WRITE_ACCESS and
C1_READ_ACCESS decorator for your convenience. Loads have
C1_READ_ACCESS, stores have C1_WRITE_ACCESS, and atomics have both.
Full webrev:
http://cr.openjdk.java.net/~eosterlund/8201543/webrev.02/
Incremental webrev:
http://cr.openjdk.java.net/~eosterlund/8201543/webrev.01_02/
It's a good place for ModRef to check whether resolving to a register is
needed or not too (only required for accesses with write barriers).
> - Or is the intention to resolve the base object on the actual
> load_at_resolved() etc entry points? As far as I can tell this would be
> difficult because we don't get to see the base object anymore?
I think it's best done in resolve. But note that you get the access
wrapper in the resolved paths, and it retains the base pointer if you
need it.
> - Thinking forward a little bit... Shenandoah is going to need some
> resolve-hooks in a couple of places that are not practical to handle via
> load/store style access calls. For example in monitorenter/exit code we
> need to insert a write-barrier on the object to be synchronized on. Will
> this be possible/practical to do via resolve_address()?
I think we should probably add a public resolve barrier for that purpose.
> - Does it already handle primitive accesses? From the looks of it, I'd
> say yes. That'd be nice.
The backends should be ready for it. But I think I will leave the
exercise of finding the callsites to you, as you have spent more time
finding where they are needed.
> The rest of it looks nice from afar, but I haven't really looked deeper
> yet. I will poke around some more and probably will have more questions...
Okay!
Thanks for having a look at these changes.
/Erik
> Thanks again!
> Cheers, Roman
>
>
>> Hi everyone,
>>
>> I sat down with Rickard and Per at the office to have a look at this,
>> and have built a new webrev based on their feedback.
>> The main elements in the delta are the following:
>>
>> 1) Wrap various context information that is passed around in the
>> BarrierSetC1 hierarchy in a wrapper object (to reduce boiler plate),
>> that has been named LIRAccess. It contains the address elements (base
>> and offset, as either LIRItem or LIROpr), as well as the decorators, and
>> the CodeEmitInfo of the address (for patching), the CodeEmitInfo for the
>> access (for things like implicit null checks), and the LIRGenerator
>> instance, that would normally be passed around to every function.
>> 2) Added #ifdef COMPILER1 in the G1BarrierSetC1 classes to be polite to
>> people trying to build HotSpot with a generated interpreter but no C1
>> compiler.
>> 3) Added a decorator_fixup() method that applies various implicit
>> decorator rules for sane defaults (for example, IN_HEAP_ARRAY implies
>> IN_HEAP). This is a 1:1 mirror to the DecoratorFixup meta function used
>> in the runtime backend. Both are now located in accessDecorator.hpp. One
>> for use by templates (DecoratorFixup), and one for use by code
>> generators that do not use templates (decorator_fixup()).
>> 4) Removed some unnecessary includes and friend class declarations.
>> 5) Made BarrierSetC1 a member of LIRGenerator to reduce boiler plate
>> further.
>> 6) Changed name of the lir_generator variable passed around to gen, to
>> be consistent with what other code in C1 does when passing around the
>> LIRGenerator instance.
>>
>> Incremental webrev:
>> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.00_01/
>>
>> Full webrev:
>> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.01/
>>
>> Big thanks to Rickard and Per for having a look at this.
>>
>> Thanks,
>> /Erik
>>
>> On 2018-04-13 17:11, Erik ?sterlund wrote:
>>> Hi,
>>>
>>> The GC barriers for C1 are not as modular as they could be. It
>>> currently uses switch statements to check which GC barrier set is
>>> being used, and calls one or another barrier based on that, in a way
>>> that it can only be used for write barriers.
>>>
>>> The solution I propose is to add the same facilities that have been
>>> added in runtime and the interpreter already: a barrier set backend
>>> for C1. I call it BarrierSetC1, and it helps us generate decorated
>>> accesses that give the GC control over the details how to generate
>>> this access. It recognizes the same decorators (accessDecorators.hpp)
>>> that the other parts of the VM recognize. Each concrete barrier set
>>> has its own backend. For now, these are CardTableBarrierSetC1 and
>>> G1BarrierSetC1, but this should pave way for upcoming concurrently
>>> compacting GCs as well.
>>>
>>> Two decorators were added for C1 specifically (found in
>>> c1_Decorators.hpp):
>>> C1_NEEDS_PATCHING for accesses where the index is not yet load because
>>> the class has yet to be loaded, and
>>> C1_MASK_BOOLEAN for accesses that need to mask untrusted boolean values.
>>>
>>> LIRGenerator calls a wrapper called access_store_at, access_load_at,
>>> etc (there are variants for cpmxchg, xchg and atomic add as well).
>>> The access call calls straight into the BarrierSetC1 hierarchy using
>>> virtual calls. It is structured in a way very similar to
>>> BarrierSetAssembler.
>>>
>>> BarrierSetC1 can also be called during initialization to generate
>>> stubs and runtime methods required by C1. For G1BarrierSetC1, this
>>> results in calling the BarrierSetAssembler for the platform specific
>>> code. This way, the BarrierSetC1 hierarchy has been carefully kept in
>>> shared code, and the switch statements for generating G1 code have
>>> been removed. Some code that used to be platform specific (like unsafe
>>> get/set and array store) have been broken out to shared code, with the
>>> actual platform specific details (some register allocation for store
>>> check and atomics) broken out to platform specific methods. This way,
>>> calls to access are kept in platform specific code.
>>>
>>> As usual, big thanks go to Martin Doerr for helping out with S390 and
>>> PPC, and Roman for taking care of AArch64.
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8201543
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.00/
>>>
>>> Thanks,
>>> /Erik
>
From vladimir.kozlov at oracle.com Mon Apr 23 22:53:02 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 23 Apr 2018 15:53:02 -0700
Subject: [11] RFR(XS) 8202075: Crash when running
compiler/codecache/OverflowCodeCacheTest.java
Message-ID: <1d85111f-98dc-888e-d135-e5b1b3622c98@oracle.com>
https://bugs.openjdk.java.net/browse/JDK-8202075
Note, bug is closed because it has some confidential information, but I
put all important information here in RFR:
[1.144s][warning][codecache] CodeCache is full. Compiler has been disabled.
[1.144s][warning][codecache] Try increasing the code cache size using
-XX:ReservedCodeCacheSize=
CodeCache: size=245760Kb used=243996Kb max_used=243996Kb free=1763Kb
bounds [0x000000b100000000, 0x000000b10f000000, 0x000000b10f000000]
total_blobs=1173 nmethods=77 adapters=840
compilation: disabled (not enough contiguous free space left)
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffb0bdfadf3,
pid=4624, tid=1984
#
# JRE version: Java(TM) SE Runtime Environment (11.0) (fastdebug build
11-internal+0)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug
11-internal+0-2018-04-20-0015354, mixed mode, tiered, compressed oops,
g1 gc, windows-amd64)
# Problematic frame:
# V [jvm.dll+0x4eadf3] CodeBlob::CodeBlob+0x23
Native frames: (J=compiled Java code, A=aot compiled Java code,
j=interpreted, Vv=VM code, C=native code)
V [libjvm.dylib+0x3babda] RuntimeBlob::RuntimeBlob(char const*, int,
int, int, int)+0x28
V [libjvm.dylib+0x3bb09e] BufferBlob::BufferBlob(char const*, int)+0x20
V [libjvm.dylib+0xc4a779] WhiteBox::allocate_code_blob(int, int)+0x9b
V [libjvm.dylib+0xc4a9d7] WB_AllocateCodeBlob+0x23c
j sun.hotspot.WhiteBox.allocateCodeBlob(II)J+0
We start testing new C++ compilers (VS and Xcode/clang) and this test
crashed in CodeBlob() constructor because, it seems, new compilers don't
generate NULL check anymore. We have to add missing check:
diff -r af4b57a556be src/hotspot/share/prims/whitebox.cpp
--- a/src/hotspot/share/prims/whitebox.cpp
+++ b/src/hotspot/share/prims/whitebox.cpp
@@ -1359,7 +1359,9 @@
{
MutexLockerEx mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);
blob = (BufferBlob*) CodeCache::allocate(full_size, blob_type);
- ::new (blob) BufferBlob("WB::DummyBlob", full_size);
+ if (blob != NULL) {
+ ::new (blob) BufferBlob("WB::DummyBlob", full_size);
+ }
}
// Track memory usage statistic after releasing CodeCache_lock
MemoryService::track_code_cache_memory_usage();
Normal testing and testing with new C++ compilers.
--
Thanks,
Vladimir
From coleen.phillimore at oracle.com Mon Apr 23 23:12:44 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 23 Apr 2018 19:12:44 -0400
Subject: RFR (XXS) 8202164: Remove some unneeded BoolObjectClosure* is_alive
parameters
Message-ID: <60fb0500-7b14-6fa7-624c-60af670d3d13@oracle.com>
See bug for details.
open webrev at http://cr.openjdk.java.net/~coleenp/8202164.01/webrev
bug link https://bugs.openjdk.java.net/browse/JDK-8202164
Tested with runThese (lots of class unloading) for all the GCs and with
mach5 hs-tier1 and 2.
Thanks,
Coleen
From kim.barrett at oracle.com Tue Apr 24 01:28:09 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 23 Apr 2018 21:28:09 -0400
Subject: RFR (XXS) 8202164: Remove some unneeded BoolObjectClosure*
is_alive parameters
In-Reply-To: <60fb0500-7b14-6fa7-624c-60af670d3d13@oracle.com>
References: <60fb0500-7b14-6fa7-624c-60af670d3d13@oracle.com>
Message-ID: <B0FE2EF5-DA0E-45BC-B557-3075B7D60380@oracle.com>
> On Apr 23, 2018, at 7:12 PM, coleen.phillimore at oracle.com wrote:
>
> See bug for details.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8202164.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8202164
>
> Tested with runThese (lots of class unloading) for all the GCs and with mach5 hs-tier1 and 2.
> Thanks,
> Coleen
I don?t think I?d call this XXS.
Looks good.
Needs a couple comment updates; I don't need a new webrev for these.
------------------------------------------------------------------------------
src/hotspot/share/code/nmethod.cpp
1039 flush_dependencies(/*delete_immediately*/false);
The preceding comment needs to be updated; there's no longer a closure
involved.
------------------------------------------------------------------------------
src/hotspot/share/code/nmethod.cpp
1364 // During GC delete_immediately is false, and is used to
1365 // determine liveness of dependees that need to be updated.
1366 if (delete_immediately || klass->is_loader_alive()) {
The comment needs to be updated; delete_immediately doesn't determine
liveness.
------------------------------------------------------------------------------
From kim.barrett at oracle.com Tue Apr 24 02:15:13 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 23 Apr 2018 22:15:13 -0400
Subject: RFR: 8202082: Remove explicit CMS checks in
CardTableBarrierSetAssembler
In-Reply-To: <5AD9FC94.70607@oracle.com>
References: <5AD9FC94.70607@oracle.com>
Message-ID: <6A476A6A-47BB-4141-980E-DB98D9BAD405@oracle.com>
> On Apr 20, 2018, at 10:43 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>
> Hi,
>
> In CardTableBarrierSetAssembler, we sometimes need fencing due to the card table being scanned concurrently when using CMS with pre-cleaning. Rather than explicitly checking for those CMS flags in the generic CardTableBarrierSetAssembler class, it is preferrable to check the CardTable scanned_concurrently() property which already precisely reflects that.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8202082
>
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.00/
>
> Thanks,
> /Erik
------------------------------------------------------------------------------
src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
121 if (ct->scanned_concurrently()) {
I think the correct test here is card_mark_must_follow_store. See
my review of 8202083 for more details.
Similarly for the other platforms.
------------------------------------------------------------------------------
src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
113 AddressLiteral cardtable((address)ctbs->card_table()->byte_map_base(), relocInfo::none);
[pre-existing]
Why isn't this using (address)disp rather than refetching the value.
------------------------------------------------------------------------------
From gnu.andrew at redhat.com Tue Apr 24 03:27:16 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 24 Apr 2018 04:27:16 +0100
Subject: RFR: build pragma error with gcc 4.4.7
In-Reply-To: <6E53C24C-D579-4247-BE27-79BE59EF3678@oracle.com>
References: <3196d61c-9b7c-b795-a68d-6e50a3416f41@redhat.com>
<01173273-2A13-4FE0-81EE-3C50954D7A90@oracle.com>
<CABi63P5FPbfdw9jynsKHa+i7=T1kaSJsyEC7tZ6eW0pZZx8Tbg@mail.gmail.com>
<6E53C24C-D579-4247-BE27-79BE59EF3678@oracle.com>
Message-ID: <CABi63P7kQh4bBkGTdOQcZeatgnbv3MkiDGUEwSonuDa2f81acQ@mail.gmail.com>
On 23 April 2018 at 20:19, Kim Barrett <kim.barrett at oracle.com> wrote:
>> On Apr 21, 2018, at 11:18 AM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>>
>> On 19 March 2018 at 23:23, Kim Barrett <kim.barrett at oracle.com> wrote:
>>> There are also problems with the patch as provided.
>>>
>>> (1) Since PRAGMA_DIAG_PUSH/POP do nothing in the version of gcc this
>>> change is being made in support of, the warning would be disabled for
>>> all following code in any translation unit that includes this file.
>>> That doesn't seem good.
>>
>> No, but it's really the only solution on those compilers. We have such
>> usage already elsewhere e.g.
>>
>> // Silence -Wformat-security warning for fatal()
>> PRAGMA_DIAG_PUSH
>> PRAGMA_FORMAT_NONLITERAL_IGNORED
>> fatal(buf);
>> PRAGMA_DIAG_POP
>> return true; // silence compiler warnings
>> }
>> in src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp
>>
>> If there are other warnings, then they will picked up on newer compilers,
>> especially when building with -Werror. I don't think it's likely people are
>> doing development on older compilers, but rather that we have to use
>> them to build for older platforms.
>
> I would be a lot more comfortable if the possibly do-nothing push/pop and
> the associated code were in a .cpp file, rather than in a .hpp file where it
> could affect some open-ended and unexpected set of code.
>
Ah yes, sorry, I missed that this was a .hpp, while the others were .cpp.
> But I think this is moot if os::readdir can be changed to call ::readdir rather
> than ::readdir_r, as appears to be the case, possibly with some documentation
> about not sharing the DIR* among multiple threads, at least not without locking.
>
I think so too for OpenJDK 11, but I'm reluctant to backport such a change
to older JDKs.
I guess if we want to continue to workaround the warning there, we'll need
to move the function into the .cpp file.
> That seemed to be what Michal was planning to do, but hasn?t gotten back to
> it yet.
Indeed. He has a patch that does that, that I've already reviewed. Just waiting
for him to post it publicly :)
>
--
Andrew :)
Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
From david.holmes at oracle.com Tue Apr 24 04:11:57 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Apr 2018 14:11:57 +1000
Subject: RFR: build pragma error with gcc 4.4.7
In-Reply-To: <CABi63P7kQh4bBkGTdOQcZeatgnbv3MkiDGUEwSonuDa2f81acQ@mail.gmail.com>
References: <3196d61c-9b7c-b795-a68d-6e50a3416f41@redhat.com>
<01173273-2A13-4FE0-81EE-3C50954D7A90@oracle.com>
<CABi63P5FPbfdw9jynsKHa+i7=T1kaSJsyEC7tZ6eW0pZZx8Tbg@mail.gmail.com>
<6E53C24C-D579-4247-BE27-79BE59EF3678@oracle.com>
<CABi63P7kQh4bBkGTdOQcZeatgnbv3MkiDGUEwSonuDa2f81acQ@mail.gmail.com>
Message-ID: <629b25e0-fbdf-7093-1d22-e10d87e0324d@oracle.com>
On 24/04/2018 1:27 PM, Andrew Hughes wrote:
> On 23 April 2018 at 20:19, Kim Barrett <kim.barrett at oracle.com> wrote:
>>> On Apr 21, 2018, at 11:18 AM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>>>
>>> On 19 March 2018 at 23:23, Kim Barrett <kim.barrett at oracle.com> wrote:
>>>> There are also problems with the patch as provided.
>>>>
>>>> (1) Since PRAGMA_DIAG_PUSH/POP do nothing in the version of gcc this
>>>> change is being made in support of, the warning would be disabled for
>>>> all following code in any translation unit that includes this file.
>>>> That doesn't seem good.
>>>
>>> No, but it's really the only solution on those compilers. We have such
>>> usage already elsewhere e.g.
>>>
>>> // Silence -Wformat-security warning for fatal()
>>> PRAGMA_DIAG_PUSH
>>> PRAGMA_FORMAT_NONLITERAL_IGNORED
>>> fatal(buf);
>>> PRAGMA_DIAG_POP
>>> return true; // silence compiler warnings
>>> }
>>> in src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp
>>>
>>> If there are other warnings, then they will picked up on newer compilers,
>>> especially when building with -Werror. I don't think it's likely people are
>>> doing development on older compilers, but rather that we have to use
>>> them to build for older platforms.
>>
>> I would be a lot more comfortable if the possibly do-nothing push/pop and
>> the associated code were in a .cpp file, rather than in a .hpp file where it
>> could affect some open-ended and unexpected set of code.
>>
>
> Ah yes, sorry, I missed that this was a .hpp, while the others were .cpp.
>
>> But I think this is moot if os::readdir can be changed to call ::readdir rather
>> than ::readdir_r, as appears to be the case, possibly with some documentation
>> about not sharing the DIR* among multiple threads, at least not without locking.
>>
>
> I think so too for OpenJDK 11, but I'm reluctant to backport such a change
> to older JDKs.
> I guess if we want to continue to workaround the warning there, we'll need
> to move the function into the .cpp file.
>
>> That seemed to be what Michal was planning to do, but hasn?t gotten back to
>> it yet.
>
> Indeed. He has a patch that does that, that I've already reviewed. Just waiting
> for him to post it publicly :)
He already has:
RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
readdir_r(DIR*, dirent*, dirent**)' is deprecated
on both the mailing lists this email has gone to.
David
-----
>>
>
>
>
From stefan.karlsson at oracle.com Tue Apr 24 05:39:48 2018
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Tue, 24 Apr 2018 07:39:48 +0200
Subject: RFR (XXS) 8202164: Remove some unneeded BoolObjectClosure*
is_alive parameters
In-Reply-To: <B0FE2EF5-DA0E-45BC-B557-3075B7D60380@oracle.com>
References: <60fb0500-7b14-6fa7-624c-60af670d3d13@oracle.com>
<B0FE2EF5-DA0E-45BC-B557-3075B7D60380@oracle.com>
Message-ID: <2bf6869c-2801-c31a-2665-286d43989c91@oracle.com>
Looks good (with Kim's suggestions)
StefanK
On 2018-04-24 03:28, Kim Barrett wrote:
>> On Apr 23, 2018, at 7:12 PM, coleen.phillimore at oracle.com wrote:
>>
>> See bug for details.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8202164.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8202164
>>
>> Tested with runThese (lots of class unloading) for all the GCs and with mach5 hs-tier1 and 2.
>> Thanks,
>> Coleen
> I don?t think I?d call this XXS.
>
> Looks good.
>
> Needs a couple comment updates; I don't need a new webrev for these.
>
> ------------------------------------------------------------------------------
> src/hotspot/share/code/nmethod.cpp
> 1039 flush_dependencies(/*delete_immediately*/false);
>
> The preceding comment needs to be updated; there's no longer a closure
> involved.
>
> ------------------------------------------------------------------------------
> src/hotspot/share/code/nmethod.cpp
> 1364 // During GC delete_immediately is false, and is used to
> 1365 // determine liveness of dependees that need to be updated.
> 1366 if (delete_immediately || klass->is_loader_alive()) {
>
> The comment needs to be updated; delete_immediately doesn't determine
> liveness.
>
> ------------------------------------------------------------------------------
>
From Ningsheng.Jian at arm.com Tue Apr 24 05:45:53 2018
From: Ningsheng.Jian at arm.com (Ningsheng Jian)
Date: Tue, 24 Apr 2018 05:45:53 +0000
Subject: 8185505: AArch64: Port AOT
In-Reply-To: <a7cdcca0-d2e4-7285-51f4-d12420dd0d0e@redhat.com>
References: <b439eaf0-e026-7ff8-e832-3717368027e4@redhat.com>
<AM5PR0802MB2449400467C4E4042C3C6A6390B00@AM5PR0802MB2449.eurprd08.prod.outlook.com>
<57767253-4826-e5b4-d142-7990d7114704@redhat.com>
<4626be6e-7927-a8ad-dead-1c3a4fca3ec9@oracle.com>
<5147cd22-8c3c-d72f-bf5d-0ef384eac45c@oracle.com>
<VI1PR0802MB2445EFDDB61AD73E87B99AC08E890@VI1PR0802MB2445.eurprd08.prod.outlook.com>
<a7cdcca0-d2e4-7285-51f4-d12420dd0d0e@redhat.com>
Message-ID: <AM5PR0802MB244964AA47218120992920A090880@AM5PR0802MB2449.eurprd08.prod.outlook.com>
> -----Original Message-----
> From: Andrew Haley <aph at redhat.com>
> Sent: Monday, April 23, 2018 6:38 PM
> To: Yang Zhang <Yang.Zhang at arm.com>; Vladimir Kozlov
> <vladimir.kozlov at oracle.com>; Ningsheng Jian <Ningsheng.Jian at arm.com>;
> hotspot-dev at openjdk.java.net
> Cc: nd <nd at arm.com>
> Subject: Re: 8185505: AArch64: Port AOT
>
> On 04/23/2018 08:14 AM, Yang Zhang wrote:
>
> > I have tested the patches in my environment. AOT test cases in jtreg
> > are passed, and there aren't new failed cases in hotspot jtreg on no
> > matter aarch64 or x86 platform.
> > But when using jaotc to compile java.base with an option
> > "--compile-for-tiered", there is an overflow error on aarch64
> > platform. There isn't such an error on x86 platform.
>
> Yep, I know that. It's because there is a 30-bit limit in the range of a branch,
> and if we have a very large text section the offset to the PLT stub may be out
> of range. There is some logic in the GNU linker to handle this, and I'll haver
> a look at how it works.
>
> I don't want to hold up this patch for the overflow issue for two reasons.
> Firstly, if you use such a huge AOT-compiled binary your performance will
> suffer greatly. It makes much more sense to compile only what you need
> because otherwise your startup time will actually be slower than not using
> AOT compilation at all. Secondly, I think it will require some reworking of
> the way that the AOT compiler works to fix this, and I'd rather do that in a
> later patch.
>
Yes, I agree to leave it as it is for now.
Specifically for the link error Yang met, since the stub code (not the GOT cases) and the call site are both in .text section, I think it might be helpful to issue warning/error when generating the relocation entry (before the long time linking phase). But since a later patch will fix this, it's OK to leave it as it is in this patch.
Two more nits:
My Eclipse has some warnings that there are some imports never used in these files:
- AArch64JELFRelocObject.java
- AMD64JELFRelocObject.java
Maybe remove those unused imports in these two files?
In file AArch64JELFRelocObject.java, line 110:
case Elf64_Ehdr.EM_AARCH64:
// Return R_X86_64_* entries based on relocType
Should the comment be R_AARCH64_* ?
Otherwise, looks good to me ( not a reviewer :-) )
Thanks,
Ningsheng
From david.holmes at oracle.com Tue Apr 24 05:54:13 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Apr 2018 15:54:13 +1000
Subject: [11] RFR(XS) 8202152:
test/hotspot/jtreg/runtime/whitebox/WBStackSize.java fails
In-Reply-To: <df053f49-ff6a-0c9e-1589-95b6a1dc5abb@oracle.com>
References: <074d0bb7-4d1e-91a2-541f-50ecd9eb4cb6@oracle.com>
<df053f49-ff6a-0c9e-1589-95b6a1dc5abb@oracle.com>
Message-ID: <84dc4c3c-6e00-189d-755a-aa0a257d5f93@oracle.com>
To follow up ... Vladimir and I have had an interesting back and forth
in the bug report. It seems that at least in some cases terminated
threads are getting recycled - not just their pthread_t identities but
the actual allocated stack region as well. We seem to end up with a new
regular Java thread acquiring the id and stack of a just terminated
compiler thread - hence the regular Java thread gets the wrong size stack!
This is quite bizarre and seems quite broken.
David
On 24/04/2018 7:24 AM, David Holmes wrote:
> Hi Vladimir,
>
> On 24/04/2018 5:20 AM, Vladimir Kozlov wrote:
>> http://cr.openjdk.java.net/~kvn/8202152/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8202152
>>
>> After 8198756 changes compiler threads could be released and other
>> Java threads can re-use the same HW threads for which stack size was
>> determined during start. The test WBStackSize.java may fail in such
>> cases because Java thread stack size is set and checked in test.
>
> That does not make sense to me. We don't "re-use HW threads" - I'm not
> even sure what that means. Compiler threads have a different stacksize
> to other Java threads - that seems simple enough.
>
>> For 8198756 changes we added thread name check to workaround the
>> problem [1]. But it seems is not enough.
>
> Why would this test be run in a compiler thread ????
>
>> To avoid this issue I added -XX:CompilerThreadStackSize=512 flag to
>> match Java thread stack size (note, size is in Kb for this flag).
>
> That seems like a workaround of the real problem.
>
> David
> -----
>
>> I also reverted changes in test code and instead added thread name
>> print to know in case we still have problem in a future.
>>
>> Tier1 testing (which run the test) passed.
>>
From david.holmes at oracle.com Tue Apr 24 06:12:28 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Apr 2018 16:12:28 +1000
Subject: [11] RFR(XS) 8202152:
test/hotspot/jtreg/runtime/whitebox/WBStackSize.java fails
In-Reply-To: <84dc4c3c-6e00-189d-755a-aa0a257d5f93@oracle.com>
References: <074d0bb7-4d1e-91a2-541f-50ecd9eb4cb6@oracle.com>
<df053f49-ff6a-0c9e-1589-95b6a1dc5abb@oracle.com>
<84dc4c3c-6e00-189d-755a-aa0a257d5f93@oracle.com>
Message-ID: <31ee2175-349e-8f0c-4bc7-0bd58faabfe0@oracle.com>
On 24/04/2018 3:54 PM, David Holmes wrote:
> To follow up ... Vladimir and I have had an interesting back and forth
> in the bug report. It seems that at least in some cases terminated
> threads are getting recycled - not just their pthread_t identities but
> the actual allocated stack region as well. We seem to end up with a new
> regular Java thread acquiring the id and stack of a just terminated
> compiler thread - hence the regular Java thread gets the wrong size stack!
>
> This is quite bizarre and seems quite broken.
No it's not broken. The stacksize attribute is just a minimum size, so
the OS can reuse a terminated thread with a larger stack - and that's
what we are seeing.
So the fix is fine, I would just add before @run:
@comment Must use the same stacksize for Java threads and compiler
threads in case of thread recycling
Or something to that affect.
Thanks,
David
> David
>
> On 24/04/2018 7:24 AM, David Holmes wrote:
>> Hi Vladimir,
>>
>> On 24/04/2018 5:20 AM, Vladimir Kozlov wrote:
>>> http://cr.openjdk.java.net/~kvn/8202152/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8202152
>>>
>>> After 8198756 changes compiler threads could be released and other
>>> Java threads can re-use the same HW threads for which stack size was
>>> determined during start. The test WBStackSize.java may fail in such
>>> cases because Java thread stack size is set and checked in test.
>>
>> That does not make sense to me. We don't "re-use HW threads" - I'm not
>> even sure what that means. Compiler threads have a different stacksize
>> to other Java threads - that seems simple enough.
>>
>>> For 8198756 changes we added thread name check to workaround the
>>> problem [1]. But it seems is not enough.
>>
>> Why would this test be run in a compiler thread ????
>>
>>> To avoid this issue I added -XX:CompilerThreadStackSize=512 flag to
>>> match Java thread stack size (note, size is in Kb for this flag).
>>
>> That seems like a workaround of the real problem.
>>
>> David
>> -----
>>
>>> I also reverted changes in test code and instead added thread name
>>> print to know in case we still have problem in a future.
>>>
>>> Tier1 testing (which run the test) passed.
>>>
From erik.osterlund at oracle.com Tue Apr 24 06:57:48 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Tue, 24 Apr 2018 08:57:48 +0200
Subject: RFR: 8202082: Remove explicit CMS checks in
CardTableBarrierSetAssembler
In-Reply-To: <6A476A6A-47BB-4141-980E-DB98D9BAD405@oracle.com>
References: <5AD9FC94.70607@oracle.com>
<6A476A6A-47BB-4141-980E-DB98D9BAD405@oracle.com>
Message-ID: <67ac1742-640e-f011-f371-cf53b782e969@oracle.com>
Hi Kim,
On 2018-04-24 04:15, Kim Barrett wrote:
>> On Apr 20, 2018, at 10:43 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>>
>> Hi,
>>
>> In CardTableBarrierSetAssembler, we sometimes need fencing due to the card table being scanned concurrently when using CMS with pre-cleaning. Rather than explicitly checking for those CMS flags in the generic CardTableBarrierSetAssembler class, it is preferrable to check the CardTable scanned_concurrently() property which already precisely reflects that.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8202082
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.00/
>>
>> Thanks,
>> /Erik
> ------------------------------------------------------------------------------
> src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
> 121 if (ct->scanned_concurrently()) {
>
> I think the correct test here is card_mark_must_follow_store. See
> my review of 8202083 for more details.
>
> Similarly for the other platforms.
I disagree. Let me explain why, and where I am trying to get with this.
We used to have a whole bunch of different ways of making decisions
based on whether the card table is scanned concurrently or not, queried
in various ways, depending on whether we were talking to the
CollectedHeap interface, the CardTableModRefBS interface, or whether we
were inside of the CardTableModRefBS class. I am trying to remove those
one by one, until only one is left, the configuration point in CardTable
which describes precisely that: that the card table is scanned
concurrently. Here are a few examples:
* The ReduceInitialCardMarks optimization either defers card marks or
issues them immediately on slowpath allocations, depending on whether
the card table is scanned concurrently or not (this used to ask
CollectedHeap about these queries).
* Inside of the post barriers, StoreStore fencing between the reference
store and card mark depends on whether the card table is scanned
concurrently or not. (checked with explicit CMS + precleaning and
sometimes conservatively just CMS checks)
* When using UseCondCardMark, there is a StoreLoad fence to make sure
the store of the reference happens-before the *load* of the card value
(not the store of the card value) for filtering. Again, this is only an
issue when the card table is scanned concurrently, and not very well
described by whether the card mark must follow the store IMO.
The reason there is not yet a single property is that some code has
previously asked CollectedHeap about these questions from outside of GC
code (ReduceInitialCardMarks), while other code lived in the card table
barrier set (CMS + pre-cleaning checks). Where I want to go is that no
code outside of the CardTableBarrierSet classes should need to ask these
questions. And code inside of the CardTableBarrierSet classes should ask
its CardTable, which acts as a configuration, whether it is scanned
concurrently or not.
So basically, I would prefer to now remove the
card_mark_must_follow_store() method, and replace it with direct calls
to whether the card table is scanned concurrently.
Do you agree?
> ------------------------------------------------------------------------------
> src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
> 113 AddressLiteral cardtable((address)ctbs->card_table()->byte_map_base(), relocInfo::none);
>
> [pre-existing]
>
> Why isn't this using (address)disp rather than refetching the value.
>
> ------------------------------------------------------------------------------
That seems unrelated to my changes.
Thanks,
/Erik
From martin.doerr at sap.com Tue Apr 24 08:22:41 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 24 Apr 2018 08:22:41 +0000
Subject: [11] RFR(XS) 8202152:
test/hotspot/jtreg/runtime/whitebox/WBStackSize.java fails
In-Reply-To: <31ee2175-349e-8f0c-4bc7-0bd58faabfe0@oracle.com>
References: <074d0bb7-4d1e-91a2-541f-50ecd9eb4cb6@oracle.com>
<df053f49-ff6a-0c9e-1589-95b6a1dc5abb@oracle.com>
<84dc4c3c-6e00-189d-755a-aa0a257d5f93@oracle.com>
<31ee2175-349e-8f0c-4bc7-0bd58faabfe0@oracle.com>
Message-ID: <441f80793c224b448502710fe8aa806b@sap.com>
Hi Vladimir,
looks good. Thanks for fixing.
The comment proposed by David would be nice, but I don't need to see a new webrev for that.
Best regards,
Martin
-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Holmes
Sent: Dienstag, 24. April 2018 08:12
To: Vladimir Kozlov <vladimir.kozlov at oracle.com>; hotspot-dev Source Developers <hotspot-dev at openjdk.java.net>
Subject: Re: [11] RFR(XS) 8202152: test/hotspot/jtreg/runtime/whitebox/WBStackSize.java fails
On 24/04/2018 3:54 PM, David Holmes wrote:
> To follow up ... Vladimir and I have had an interesting back and forth
> in the bug report. It seems that at least in some cases terminated
> threads are getting recycled - not just their pthread_t identities but
> the actual allocated stack region as well. We seem to end up with a new
> regular Java thread acquiring the id and stack of a just terminated
> compiler thread - hence the regular Java thread gets the wrong size stack!
>
> This is quite bizarre and seems quite broken.
No it's not broken. The stacksize attribute is just a minimum size, so
the OS can reuse a terminated thread with a larger stack - and that's
what we are seeing.
So the fix is fine, I would just add before @run:
@comment Must use the same stacksize for Java threads and compiler
threads in case of thread recycling
Or something to that affect.
Thanks,
David
> David
>
> On 24/04/2018 7:24 AM, David Holmes wrote:
>> Hi Vladimir,
>>
>> On 24/04/2018 5:20 AM, Vladimir Kozlov wrote:
>>> http://cr.openjdk.java.net/~kvn/8202152/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8202152
>>>
>>> After 8198756 changes compiler threads could be released and other
>>> Java threads can re-use the same HW threads for which stack size was
>>> determined during start. The test WBStackSize.java may fail in such
>>> cases because Java thread stack size is set and checked in test.
>>
>> That does not make sense to me. We don't "re-use HW threads" - I'm not
>> even sure what that means. Compiler threads have a different stacksize
>> to other Java threads - that seems simple enough.
>>
>>> For 8198756 changes we added thread name check to workaround the
>>> problem [1]. But it seems is not enough.
>>
>> Why would this test be run in a compiler thread ????
>>
>>> To avoid this issue I added -XX:CompilerThreadStackSize=512 flag to
>>> match Java thread stack size (note, size is in Kb for this flag).
>>
>> That seems like a workaround of the real problem.
>>
>> David
>> -----
>>
>>> I also reverted changes in test code and instead added thread name
>>> print to know in case we still have problem in a future.
>>>
>>> Tier1 testing (which run the test) passed.
>>>
From tobias.hartmann at oracle.com Tue Apr 24 13:19:39 2018
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 24 Apr 2018 15:19:39 +0200
Subject: [11] RFR(XS) 8202075: Crash when running
compiler/codecache/OverflowCodeCacheTest.java
In-Reply-To: <1d85111f-98dc-888e-d135-e5b1b3622c98@oracle.com>
References: <1d85111f-98dc-888e-d135-e5b1b3622c98@oracle.com>
Message-ID: <c1422f84-7b6b-b00b-fed9-cc5b88257d6e@oracle.com>
Hi Vladimir,
looks good to me!
Best regards,
Tobias
On 24.04.2018 00:53, Vladimir Kozlov wrote:
> https://bugs.openjdk.java.net/browse/JDK-8202075
> Note, bug is closed because it has some confidential information, but I put all important
> information here in RFR:
>
> [1.144s][warning][codecache] CodeCache is full. Compiler has been disabled.
> [1.144s][warning][codecache] Try increasing the code cache size using -XX:ReservedCodeCacheSize=
> CodeCache: size=245760Kb used=243996Kb max_used=243996Kb free=1763Kb
> ?bounds [0x000000b100000000, 0x000000b10f000000, 0x000000b10f000000]
> ?total_blobs=1173 nmethods=77 adapters=840
> ?compilation: disabled (not enough contiguous free space left)
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffb0bdfadf3, pid=4624, tid=1984
> #
> # JRE version: Java(TM) SE Runtime Environment (11.0) (fastdebug build 11-internal+0)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 11-internal+0-2018-04-20-0015354, mixed
> mode, tiered, compressed oops, g1 gc, windows-amd64)
> # Problematic frame:
> # V? [jvm.dll+0x4eadf3]? CodeBlob::CodeBlob+0x23
>
> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> V? [libjvm.dylib+0x3babda]? RuntimeBlob::RuntimeBlob(char const*, int, int, int, int)+0x28
> V? [libjvm.dylib+0x3bb09e]? BufferBlob::BufferBlob(char const*, int)+0x20
> V? [libjvm.dylib+0xc4a779]? WhiteBox::allocate_code_blob(int, int)+0x9b
> V? [libjvm.dylib+0xc4a9d7]? WB_AllocateCodeBlob+0x23c
> j? sun.hotspot.WhiteBox.allocateCodeBlob(II)J+0
>
>
> We start testing new C++ compilers (VS and Xcode/clang) and this test crashed in CodeBlob()
> constructor because, it seems, new compilers don't generate NULL check anymore. We have to add
> missing check:
>
> diff -r af4b57a556be src/hotspot/share/prims/whitebox.cpp
> --- a/src/hotspot/share/prims/whitebox.cpp
> +++ b/src/hotspot/share/prims/whitebox.cpp
> @@ -1359,7 +1359,9 @@
> ?? {
> ???? MutexLockerEx mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);
> ???? blob = (BufferBlob*) CodeCache::allocate(full_size, blob_type);
> -??? ::new (blob) BufferBlob("WB::DummyBlob", full_size);
> +??? if (blob != NULL) {
> +????? ::new (blob) BufferBlob("WB::DummyBlob", full_size);
> +??? }
> ?? }
> ?? // Track memory usage statistic after releasing CodeCache_lock
> ?? MemoryService::track_code_cache_memory_usage();
>
>
> Normal testing and testing with new C++ compilers.
>
From aph at redhat.com Tue Apr 24 13:26:54 2018
From: aph at redhat.com (Andrew Haley)
Date: Tue, 24 Apr 2018 14:26:54 +0100
Subject: 8185505: AArch64: Port AOT
In-Reply-To: <AM5PR0802MB244964AA47218120992920A090880@AM5PR0802MB2449.eurprd08.prod.outlook.com>
References: <b439eaf0-e026-7ff8-e832-3717368027e4@redhat.com>
<AM5PR0802MB2449400467C4E4042C3C6A6390B00@AM5PR0802MB2449.eurprd08.prod.outlook.com>
<57767253-4826-e5b4-d142-7990d7114704@redhat.com>
<4626be6e-7927-a8ad-dead-1c3a4fca3ec9@oracle.com>
<5147cd22-8c3c-d72f-bf5d-0ef384eac45c@oracle.com>
<VI1PR0802MB2445EFDDB61AD73E87B99AC08E890@VI1PR0802MB2445.eurprd08.prod.outlook.com>
<a7cdcca0-d2e4-7285-51f4-d12420dd0d0e@redhat.com>
<AM5PR0802MB244964AA47218120992920A090880@AM5PR0802MB2449.eurprd08.prod.outlook.com>
Message-ID: <42c8b22b-a96d-a598-6ded-96bef4835a21@redhat.com>
On 04/24/2018 06:45 AM, Ningsheng Jian wrote:
> Specifically for the link error Yang met, since the stub code (not
> the GOT cases) and the call site are both in .text section, I think
> it might be helpful to issue warning/error when generating the
> relocation entry (before the long time linking phase).
We don't know that the overflow will happen until ink time.
> Two more nits:
>
> My Eclipse has some warnings that there are some imports never used in these files:
> - AArch64JELFRelocObject.java
> - AMD64JELFRelocObject.java
> Maybe remove those unused imports in these two files?
>
> In file AArch64JELFRelocObject.java, line 110:
> case Elf64_Ehdr.EM_AARCH64:
> // Return R_X86_64_* entries based on relocType
> Should the comment be R_AARCH64_* ?
Yes, thanks.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From martin.doerr at sap.com Tue Apr 24 13:43:42 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 24 Apr 2018 13:43:42 +0000
Subject: RFR 8201799: Build failures after JDK-8195099 (Concurrent
safe-memory-reclamation mechanism)
In-Reply-To: <5ADDB823.5060002@oracle.com>
References: <150dc231-d81e-58da-fa46-fd2397bb7ca2@redhat.com>
<ee7c6a6c-7697-ca4b-dd3d-484ca24aeabd@oracle.com> <5AD73E53.90904@oracle.com>
<803cb23d4b754d2384d9681950f5297c@sap.com>
<661ce2cc-2ea7-9a99-e646-ac3fd8c3494e@redhat.com>
<5ADDB823.5060002@oracle.com>
Message-ID: <8d27cc92babd424e878ca6312000db3d@sap.com>
Hi Erik,
I highly appreciate if we can get the VM code to work correctly with C++ 2011 semantics on PPC64.
But I think this needs to be done very carefully in order to avoid missing sync instructions between CAS and Load.
E.g. the new global counter implementation uses (after fix):
Atomic::add(memory_order_conservative) + OrderAccess::load_acquire
In C++2011 this should become:
Cmpxchg SeqCst + Load Seq Cst
Cmpxchg SeqCst + any other Load would be incorrect on PPC64. So we will need to double-check all corresponding loads.
I've seen that you have moved the support_IRIW_for_not_multiple_copy_atomic_cpu fence into RawAccessBarrier<decorators>::load_internal. Ideally, RawAccessBarrier<decorators>::store_internal should use OrderAccess::release_store without fence in case of support_IRIW_for_not_multiple_copy_atomic_cpu, but I'm not requesting to change this now. We'd get this by moving to C++ 2011 semantics (which assumes support_IRIW_for_not_multiple_copy_atomic_cpu), right?
Best regards,
Martin
-----Original Message-----
From: Erik ?sterlund [mailto:erik.osterlund at oracle.com]
Sent: Montag, 23. April 2018 12:41
To: Andrew Haley <aph at redhat.com>; Doerr, Martin <martin.doerr at sap.com>; David Holmes <david.holmes at oracle.com>; Aleksey Shipilev <shade at redhat.com>; hotspot-dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Subject: Re: RFR 8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism)
Hi Andrew,
On 2018-04-23 12:20, Andrew Haley wrote:
> On 04/18/2018 05:37 PM, Doerr, Martin wrote:
>
>> It'd be great if we could specify semantics for Atomic:add like we
>> do for Atomic::cmpchgx.
>> However, the double-fence is a very bad default from performance
>> perspective. I wonder if PPC64 is the only platform which gets hit.
> Probably not.
>
>> Would it be acceptable to set the default to
>> memory_order_acquire_release and specify memory_order_conservative
>> for the new usage? I think this would fit perfectly for PPC64, but
>> some people may not like it. One could say PPC64 is the problem, but
>> one could also say the VM code is the problem ??
> Indeed. In as much as we use stronger memory ordering than we need in
> more than one place, the VM code is the problem.
>
>> I don't really like the straight forward fix to insert a fence with
>> #ifdef AIX.
> I agree. It looks to me like it's sufficient if the increment of
> global_counter and the load of thread->get_rcu_counter() are
> sequentially consistent. On at least one platform, AArch64, we can
> do that without additional fencing.
I would also like to have seq_cst available. In the Access API, I need
MO_SEQ_CST for JMM volatile support. I would like the semantic
requirements to go straight into Atomic, instead of doing a "if
(support_IRIW_for_not_multiple_copy_atomic_cpu) { OrderAccess::fence();
}" dance in shared code, that may or may not make sense at a given
platform (among other reasons because it enforces whether leading or
trailing sync convention is used in shared code, rather than leave that
decision to the platform level). Plus I have a mouse pad that says I
love sequential consistency, although that might not be a valid argument
to introduce this to Atomic.
Thanks,
/Erik
From martin.doerr at sap.com Tue Apr 24 14:01:49 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 24 Apr 2018 14:01:49 +0000
Subject: RFR 8201799: Build failures after JDK-8195099 (Concurrent
safe-memory-reclamation mechanism)
In-Reply-To: <8d27cc92babd424e878ca6312000db3d@sap.com>
References: <150dc231-d81e-58da-fa46-fd2397bb7ca2@redhat.com>
<ee7c6a6c-7697-ca4b-dd3d-484ca24aeabd@oracle.com> <5AD73E53.90904@oracle.com>
<803cb23d4b754d2384d9681950f5297c@sap.com>
<661ce2cc-2ea7-9a99-e646-ac3fd8c3494e@redhat.com>
<5ADDB823.5060002@oracle.com> <8d27cc92babd424e878ca6312000db3d@sap.com>
Message-ID: <a5b2cd7ee8ec4c77a8258cf0d40687fb@sap.com>
Hi again,
another issue with C++ 2011 on PPC64 is that Cmpxchg Acquire/AcqRel/SeqCst don't acquire in case of failing Cmpxchg while our Atomic::PlatformCmpxchg does that. I believe that there are places in hotspot which rely on that. So I guess that all "else" cases will need to get double-checked and possibly get enhanced by leading OrderAccess:acquire().
Best regards,
Martin
-----Original Message-----
From: Doerr, Martin
Sent: Dienstag, 24. April 2018 15:44
To: 'Erik ?sterlund' <erik.osterlund at oracle.com>; Andrew Haley <aph at redhat.com>; David Holmes <david.holmes at oracle.com>; Aleksey Shipilev <shade at redhat.com>; hotspot-dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Subject: RE: RFR 8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism)
Hi Erik,
I highly appreciate if we can get the VM code to work correctly with C++ 2011 semantics on PPC64.
But I think this needs to be done very carefully in order to avoid missing sync instructions between CAS and Load.
E.g. the new global counter implementation uses (after fix):
Atomic::add(memory_order_conservative) + OrderAccess::load_acquire
In C++2011 this should become:
Cmpxchg SeqCst + Load Seq Cst
Cmpxchg SeqCst + any other Load would be incorrect on PPC64. So we will need to double-check all corresponding loads.
I've seen that you have moved the support_IRIW_for_not_multiple_copy_atomic_cpu fence into RawAccessBarrier<decorators>::load_internal. Ideally, RawAccessBarrier<decorators>::store_internal should use OrderAccess::release_store without fence in case of support_IRIW_for_not_multiple_copy_atomic_cpu, but I'm not requesting to change this now. We'd get this by moving to C++ 2011 semantics (which assumes support_IRIW_for_not_multiple_copy_atomic_cpu), right?
Best regards,
Martin
-----Original Message-----
From: Erik ?sterlund [mailto:erik.osterlund at oracle.com]
Sent: Montag, 23. April 2018 12:41
To: Andrew Haley <aph at redhat.com>; Doerr, Martin <martin.doerr at sap.com>; David Holmes <david.holmes at oracle.com>; Aleksey Shipilev <shade at redhat.com>; hotspot-dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Subject: Re: RFR 8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism)
Hi Andrew,
On 2018-04-23 12:20, Andrew Haley wrote:
> On 04/18/2018 05:37 PM, Doerr, Martin wrote:
>
>> It'd be great if we could specify semantics for Atomic:add like we
>> do for Atomic::cmpchgx.
>> However, the double-fence is a very bad default from performance
>> perspective. I wonder if PPC64 is the only platform which gets hit.
> Probably not.
>
>> Would it be acceptable to set the default to
>> memory_order_acquire_release and specify memory_order_conservative
>> for the new usage? I think this would fit perfectly for PPC64, but
>> some people may not like it. One could say PPC64 is the problem, but
>> one could also say the VM code is the problem ??
> Indeed. In as much as we use stronger memory ordering than we need in
> more than one place, the VM code is the problem.
>
>> I don't really like the straight forward fix to insert a fence with
>> #ifdef AIX.
> I agree. It looks to me like it's sufficient if the increment of
> global_counter and the load of thread->get_rcu_counter() are
> sequentially consistent. On at least one platform, AArch64, we can
> do that without additional fencing.
I would also like to have seq_cst available. In the Access API, I need
MO_SEQ_CST for JMM volatile support. I would like the semantic
requirements to go straight into Atomic, instead of doing a "if
(support_IRIW_for_not_multiple_copy_atomic_cpu) { OrderAccess::fence();
}" dance in shared code, that may or may not make sense at a given
platform (among other reasons because it enforces whether leading or
trailing sync convention is used in shared code, rather than leave that
decision to the platform level). Plus I have a mouse pad that says I
love sequential consistency, although that might not be a valid argument
to introduce this to Atomic.
Thanks,
/Erik
From martin.doerr at sap.com Tue Apr 24 14:20:06 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 24 Apr 2018 14:20:06 +0000
Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for
ppc64
In-Reply-To: <OF16DAB34F.17FD9ED8-ON00258278.002211BA-49258278.003A0AFD@notes.na.collabserv.com>
References: <OF16DAB34F.17FD9ED8-ON00258278.002211BA-49258278.003A0AFD@notes.na.collabserv.com>
Message-ID: <63793e9f7b0e4989a9716cf87be3c7fe@sap.com>
Hi Michihiro,
thanks for posting the new webrev. I think this looks much better, now.
I don't like the "if log_is_enabled() acquire()" code so much, but it looks correct to me. I'd prefer your OrderAccess:consume() proposal, but I can live with it if other reviewers prefer it.
I couldn't find any store-load pattern which may miss ordering, but I'd highly appreciate if another reviewer double-checked that the barriers are right this time.
If needed, we could use memory_order_acq_rel which I'm planning to add with JDK-8202080. I guess this wouldn't really impact performance.
I think 6% performance gain is really worth doing this change.
Best regards,
Martin
From: Michihiro Horie [mailto:HORIE at jp.ibm.com]
Sent: Montag, 23. April 2018 12:34
To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
Cc: Hiroshi H Horii <HORII at jp.ibm.com>; Gustavo Romero <gromero at linux.vnet.ibm.com>; Kazunori Ogata <OGATAK at jp.ibm.com>; shade at redhat.com; aph at redhat.com; Doerr, Martin <martin.doerr at sap.com>
Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64
Dear all,
I would like to ask reviews on 8154736 "enhancement of cmpxchg and copy_to_survivor". The change adds options to avoid expensive syncs with compare-and-exchange. An experiment by using SPECjbb2015 showed 6% improvement in critical-jOPS. This change focuses on ppc64 but would be potentially beneficial for aarch64.
Although discussions stopped at http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-October/002718.html, I would like to restart the review by taking over Hiroshi's work if the discussion is still open.
Bug: https://bugs.openjdk.java.net/browse/JDK-8154736
Webrev: http://cr.openjdk.java.net/~mhorie/8154736/webrev.08/
Previous review had discussions on improper log output (http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-September/002672.html). Logs can be generated properly with this change, but I would like to ask if we should use "if(log) OrderAccess:acquire()" as is in webrev or more general approach with a call to OrderAccess:consume() with empty implementation on all supported platforms.
Also, there were discussions on the problem of unawareness of copied obj (http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-October/002696.html). This change adds "release" in cmpxchg_pre_membar. This was discussed in http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-October/002698.html.
I measured SPECjbb2015 with its multi JVMs mode on a POWER8 node (for JDK11, I modified MANIFEST in specjbb2015.jar to specify locations of JAXB related libraries). As a result, critical-jOPS improved by 6% due to this change.
Best regards,
--
Michihiro,
IBM Research - Tokyo
From glaubitz at physik.fu-berlin.de Tue Apr 24 14:42:26 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 24 Apr 2018 16:42:26 +0200
Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for
ppc64
In-Reply-To: <63793e9f7b0e4989a9716cf87be3c7fe@sap.com>
References: <OF16DAB34F.17FD9ED8-ON00258278.002211BA-49258278.003A0AFD@notes.na.collabserv.com>
<63793e9f7b0e4989a9716cf87be3c7fe@sap.com>
Message-ID: <e1718644-9a70-2636-bdfc-a9508e4cda78@physik.fu-berlin.de>
Hi!
On 04/24/2018 04:20 PM, Doerr, Martin wrote:
> I think 6% performance gain is really worth doing this change.
Quick question: Does this pose any assumptions on the instruction set baseline
on ppc64? I haven't build-tested this yet, but I want to avoid it doesn't break
on POWER5, for example, which is used in Debian's big-endian ppc64 port.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From coleen.phillimore at oracle.com Tue Apr 24 15:01:31 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 24 Apr 2018 11:01:31 -0400
Subject: RFR (XXS) 8202164: Remove some unneeded BoolObjectClosure*
is_alive parameters
In-Reply-To: <B0FE2EF5-DA0E-45BC-B557-3075B7D60380@oracle.com>
References: <60fb0500-7b14-6fa7-624c-60af670d3d13@oracle.com>
<B0FE2EF5-DA0E-45BC-B557-3075B7D60380@oracle.com>
Message-ID: <5ec5a26b-4b52-2f95-0b54-3476f43c1ffe@oracle.com>
On 4/23/18 9:28 PM, Kim Barrett wrote:
>> On Apr 23, 2018, at 7:12 PM, coleen.phillimore at oracle.com wrote:
>>
>> See bug for details.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8202164.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8202164
>>
>> Tested with runThese (lots of class unloading) for all the GCs and with mach5 hs-tier1 and 2.
>> Thanks,
>> Coleen
> I don?t think I?d call this XXS.
>
> Looks good.
>
> Needs a couple comment updates; I don't need a new webrev for these.
>
> ------------------------------------------------------------------------------
> src/hotspot/share/code/nmethod.cpp
> 1039 flush_dependencies(/*delete_immediately*/false);
>
> The preceding comment needs to be updated; there's no longer a closure
> involved.
I thought I'd gotten them all.?? I changed the comment to this. There's
a more thorough comment in flush_dependencies that explains why.
? // If this work is being done during a GC, defer deleting
dependencies from the
? // InstanceKlass.
>
> ------------------------------------------------------------------------------
> src/hotspot/share/code/nmethod.cpp
> 1364 // During GC delete_immediately is false, and is used to
> 1365 // determine liveness of dependees that need to be updated.
> 1366 if (delete_immediately || klass->is_loader_alive()) {
>
> The comment needs to be updated; delete_immediately doesn't determine
> liveness.
Some rewording hopefully makes more sense:
??????? // During GC delete_immediately is false, and liveness
??????? // of dependee determines class that needs to be updated.
??????? if (delete_immediately || klass->is_loader_alive()) {
Thanks,
Coleen
> ------------------------------------------------------------------------------
>
From jonathan.gibbons at oracle.com Tue Apr 24 15:13:45 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 24 Apr 2018 08:13:45 -0700
Subject: Bug Report: ConstantPool vs constantPool
In-Reply-To: <OF194127C5.2275AA06-ON00258273.0045BB96-80258273.00464239@notes.na.collabserv.com>
References: <OF194127C5.2275AA06-ON00258273.0045BB96-80258273.00464239@notes.na.collabserv.com>
Message-ID: <796afbd5-1832-0493-b4c5-0da8c12194ef@oracle.com>
Adam,
While it would be good for jtreg to detect this,? the real fix is that
the directories need to be renamed, which is a matter for the hotspot
team. (cc:-ed)
-- Jon
On 4/18/18 5:47 AM, Adam Farley8 wrote:
> Hi All,
>
> Windows is having trouble with the constantPool and ConstantPool
> directories because they use the same name.
>
> Parent folder: test/hotspot/jtreg/runtime
>
> Is it a trivial matter to solve this?
>
> E.g. get the files from one copied into the other, followed by the
> deletion of the redundant constantPool?
>
> Best Regards
>
> Adam Farley
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
From gromero at linux.vnet.ibm.com Tue Apr 24 15:54:29 2018
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Tue, 24 Apr 2018 12:54:29 -0300
Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for
ppc64
In-Reply-To: <e1718644-9a70-2636-bdfc-a9508e4cda78@physik.fu-berlin.de>
References: <OF16DAB34F.17FD9ED8-ON00258278.002211BA-49258278.003A0AFD@notes.na.collabserv.com>
<63793e9f7b0e4989a9716cf87be3c7fe@sap.com>
<e1718644-9a70-2636-bdfc-a9508e4cda78@physik.fu-berlin.de>
Message-ID: <cbc8950b-4f42-a550-4550-5dcb9ac29fd4@linux.vnet.ibm.com>
Hi John,
On 04/24/2018 11:42 AM, John Paul Adrian Glaubitz wrote:
> On 04/24/2018 04:20 PM, Doerr, Martin wrote:
>> I think 6% performance gain is really worth doing this change.
>
> Quick question: Does this pose any assumptions on the instruction set baseline
> on ppc64? I haven't build-tested this yet, but I want to avoid it doesn't break
> on POWER5, for example, which is used in Debian's big-endian ppc64 port.
Yes, it does. But POWER5 and above are ok. Lightweight sync (lwsync) was
introduced with Power ISA v2.03 which, by its turn, maps to POWER5.
Thanks for taking care of Power + Debian :-)
Regards,
Gustavo
From coleen.phillimore at oracle.com Tue Apr 24 16:01:46 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 24 Apr 2018 12:01:46 -0400
Subject: Bug Report: ConstantPool vs constantPool
In-Reply-To: <796afbd5-1832-0493-b4c5-0da8c12194ef@oracle.com>
References: <OF194127C5.2275AA06-ON00258273.0045BB96-80258273.00464239@notes.na.collabserv.com>
<796afbd5-1832-0493-b4c5-0da8c12194ef@oracle.com>
Message-ID: <8fc3c700-fd0a-7ddc-435a-5b862aa679b8@oracle.com>
Filed bug report:
https://bugs.openjdk.java.net/browse/JDK-8202204
thanks,
Coleen
On 4/24/18 11:13 AM, Jonathan Gibbons wrote:
> Adam,
>
> While it would be good for jtreg to detect this,? the real fix is that
> the directories need to be renamed, which is a matter for the hotspot
> team. (cc:-ed)
>
> -- Jon
>
>
>
> On 4/18/18 5:47 AM, Adam Farley8 wrote:
>> Hi All,
>>
>> Windows is having trouble with the constantPool and ConstantPool
>> directories because they use the same name.
>>
>> Parent folder: test/hotspot/jtreg/runtime
>>
>> Is it a trivial matter to solve this?
>>
>> E.g. get the files from one copied into the other, followed by the
>> deletion of the redundant constantPool?
>>
>> Best Regards
>>
>> Adam Farley
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>> PO6 3AU
>
From vladimir.kozlov at oracle.com Tue Apr 24 16:06:09 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 24 Apr 2018 09:06:09 -0700
Subject: [11] RFR(XS) 8202075: Crash when running
compiler/codecache/OverflowCodeCacheTest.java
In-Reply-To: <c1422f84-7b6b-b00b-fed9-cc5b88257d6e@oracle.com>
References: <1d85111f-98dc-888e-d135-e5b1b3622c98@oracle.com>
<c1422f84-7b6b-b00b-fed9-cc5b88257d6e@oracle.com>
Message-ID: <f0eb767b-0e28-8ff8-2075-2440a4aefb3f@oracle.com>
Thank you, Tobias
Vladimir
On 4/24/18 6:19 AM, Tobias Hartmann wrote:
> Hi Vladimir,
>
> looks good to me!
>
> Best regards,
> Tobias
>
> On 24.04.2018 00:53, Vladimir Kozlov wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8202075
>> Note, bug is closed because it has some confidential information, but I put all important
>> information here in RFR:
>>
>> [1.144s][warning][codecache] CodeCache is full. Compiler has been disabled.
>> [1.144s][warning][codecache] Try increasing the code cache size using -XX:ReservedCodeCacheSize=
>> CodeCache: size=245760Kb used=243996Kb max_used=243996Kb free=1763Kb
>> ?bounds [0x000000b100000000, 0x000000b10f000000, 0x000000b10f000000]
>> ?total_blobs=1173 nmethods=77 adapters=840
>> ?compilation: disabled (not enough contiguous free space left)
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #? EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffb0bdfadf3, pid=4624, tid=1984
>> #
>> # JRE version: Java(TM) SE Runtime Environment (11.0) (fastdebug build 11-internal+0)
>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 11-internal+0-2018-04-20-0015354, mixed
>> mode, tiered, compressed oops, g1 gc, windows-amd64)
>> # Problematic frame:
>> # V? [jvm.dll+0x4eadf3]? CodeBlob::CodeBlob+0x23
>>
>> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native
>> code)
>> V? [libjvm.dylib+0x3babda]? RuntimeBlob::RuntimeBlob(char const*, int, int, int, int)+0x28
>> V? [libjvm.dylib+0x3bb09e]? BufferBlob::BufferBlob(char const*, int)+0x20
>> V? [libjvm.dylib+0xc4a779]? WhiteBox::allocate_code_blob(int, int)+0x9b
>> V? [libjvm.dylib+0xc4a9d7]? WB_AllocateCodeBlob+0x23c
>> j? sun.hotspot.WhiteBox.allocateCodeBlob(II)J+0
>>
>>
>> We start testing new C++ compilers (VS and Xcode/clang) and this test crashed in CodeBlob()
>> constructor because, it seems, new compilers don't generate NULL check anymore. We have to add
>> missing check:
>>
>> diff -r af4b57a556be src/hotspot/share/prims/whitebox.cpp
>> --- a/src/hotspot/share/prims/whitebox.cpp
>> +++ b/src/hotspot/share/prims/whitebox.cpp
>> @@ -1359,7 +1359,9 @@
>> ?? {
>> ???? MutexLockerEx mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);
>> ???? blob = (BufferBlob*) CodeCache::allocate(full_size, blob_type);
>> -??? ::new (blob) BufferBlob("WB::DummyBlob", full_size);
>> +??? if (blob != NULL) {
>> +????? ::new (blob) BufferBlob("WB::DummyBlob", full_size);
>> +??? }
>> ?? }
>> ?? // Track memory usage statistic after releasing CodeCache_lock
>> ?? MemoryService::track_code_cache_memory_usage();
>>
>>
>> Normal testing and testing with new C++ compilers.
>>
From matthias.baesken at sap.com Tue Apr 24 16:09:29 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 24 Apr 2018 16:09:29 +0000
Subject: RFR: JDK-8202200: set INCLUDE_SA to false on s390x by default -was :
RE: INCLUDE_SA/serviceability agent - support on s390x
Message-ID: <6a3fba0f7abd4ac38de4a13fd8ec33ef@sap.com>
Hi Jini, the removal of the mentioned headers leads to build errors so we better keep it .
Error is when the headers are removed :
/nb/linuxs390x/nightly/jdk/src/hotspot/share/runtime/vmStructs.cpp:100:31: fatal error: vmStructs_s390.hpp: No such file or directory
#include CPU_HEADER(vmStructs)
I uploaded a webrev for review :
http://cr.openjdk.java.net/~mbaesken/webrevs/8202200/
bug :
https://bugs.openjdk.java.net/browse/JDK-8202200
Best regards, Matthias
> -----Original Message-----
> From: Jini George [mailto:jini.george at oracle.com]
> Sent: Dienstag, 24. April 2018 08:58
> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
> dev at openjdk.java.net' <build-dev at openjdk.java.net>
> Cc: serviceability-dev at openjdk.java.net; Schmidt, Lutz
> <lutz.schmidt at sap.com>
> Subject: Re: INCLUDE_SA/serviceability agent - support on s390x
>
> Hi Matthias,
>
> Your change looks good to me. It might make sense to also remove the
> following lines from:
>
> src/jdk.hotspot.agent/linux/native/libsaproc/libproc.h
>
> 78 #if defined(s390x)
> 79 #include <asm/ptrace.h>
> 80 #endif
>
> I am not sure if the following files are required either:
> src/hotspot/cpu/s390/vmStructs_s390.hpp
> src/hotspot/os_cpu/linux_s390/vmStructs_linux_s390.hpp
>
> Thanks,
> Jini (Not a Reviewer).
>
>
> On 4/23/2018 5:31 PM, Baesken, Matthias wrote:
> > Hello,?? as far as I know? the serviceability agent?? is not? supported
> > on? linux s390x .
> >
> > However? (unlike? on aix where it is not supported as well) ,
> > ?INCLUDE_SA=false??? is not set? in the central configure? m4 files .
> >
> > Should we set it? ( suggested diff below)? ?
> >
> > Best regards, Matthias
> >
> > hg diff
> >
> > diff -r fcd5df7aa235 make/autoconf/jdk-options.m4
> >
> > --- a/make/autoconf/jdk-options.m4????? Wed Apr 18 11:19:32 2018 +0200
> >
> > +++ b/make/autoconf/jdk-options.m4????? Mon Apr 23 13:46:17 2018 +0200
> >
> > @@ -238,6 +238,9 @@
> >
> > ?? if test "x$OPENJDK_TARGET_OS" = xaix ; then
> >
> > ???? INCLUDE_SA=false
> >
> > ?? fi
> >
> > +? if test "x$OPENJDK_TARGET_CPU" = xs390x ; then
> >
> > +??? INCLUDE_SA=false
> >
> > +? fi
> >
> > ?? AC_SUBST(INCLUDE_SA)
> >
> > # Compress jars
> >
> > Best regards, Matthias
> >
From erik.osterlund at oracle.com Tue Apr 24 16:24:43 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Tue, 24 Apr 2018 18:24:43 +0200
Subject: RFR 8201799: Build failures after JDK-8195099 (Concurrent
safe-memory-reclamation mechanism)
In-Reply-To: <8d27cc92babd424e878ca6312000db3d@sap.com>
References: <150dc231-d81e-58da-fa46-fd2397bb7ca2@redhat.com>
<ee7c6a6c-7697-ca4b-dd3d-484ca24aeabd@oracle.com> <5AD73E53.90904@oracle.com>
<803cb23d4b754d2384d9681950f5297c@sap.com>
<661ce2cc-2ea7-9a99-e646-ac3fd8c3494e@redhat.com>
<5ADDB823.5060002@oracle.com> <8d27cc92babd424e878ca6312000db3d@sap.com>
Message-ID: <0d76e23a-a61a-c77f-a41d-fa6099ecdc51@oracle.com>
Hi Martin,
On 2018-04-24 15:43, Doerr, Martin wrote:
> Hi Erik,
>
> I highly appreciate if we can get the VM code to work correctly with C++ 2011 semantics on PPC64.
> But I think this needs to be done very carefully in order to avoid missing sync instructions between CAS and Load.
I was not suggesting removing the more conservative ordering property,
only allowing using seq_cst, when you know that is the correct semantics.
> E.g. the new global counter implementation uses (after fix):
> Atomic::add(memory_order_conservative) + OrderAccess::load_acquire
>
> In C++2011 this should become:
> Cmpxchg SeqCst + Load Seq Cst
>
> Cmpxchg SeqCst + any other Load would be incorrect on PPC64. So we will need to double-check all corresponding loads.
This might be getting out of topic, but here goes...
There are both leading sync and trailing sync conventions for
implementing C++11 seq_cst on PPC. What you are saying is true for the
leading sync convention, but not for the trailing sync convention. In
HotSpot, I think it is probably more desirable to bind the expectations
for *all* seq_cst accesses to have trailing sync convention to avoid
this issue of seq_cst store followed by load_acquire being reordered. I
don't think we want a situation where PPC implements leading sync
(despite being able to choose trailing sync), when AArch64 uses trailing
sync. But perhaps this is derailing a bit...
> I've seen that you have moved the support_IRIW_for_not_multiple_copy_atomic_cpu fence into RawAccessBarrier<decorators>::load_internal. Ideally, RawAccessBarrier<decorators>::store_internal should use OrderAccess::release_store without fence in case of support_IRIW_for_not_multiple_copy_atomic_cpu, but I'm not requesting to change this now. We'd get this by moving to C++ 2011 semantics (which assumes support_IRIW_for_not_multiple_copy_atomic_cpu), right?
That code should really call into Atomic/OrderAccess with seq_cst, and
let the platform layer do what it needs to do.
Thanks,
/Erik
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: Erik ?sterlund [mailto:erik.osterlund at oracle.com]
> Sent: Montag, 23. April 2018 12:41
> To: Andrew Haley <aph at redhat.com>; Doerr, Martin <martin.doerr at sap.com>; David Holmes <david.holmes at oracle.com>; Aleksey Shipilev <shade at redhat.com>; hotspot-dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Subject: Re: RFR 8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism)
>
> Hi Andrew,
>
> On 2018-04-23 12:20, Andrew Haley wrote:
>> On 04/18/2018 05:37 PM, Doerr, Martin wrote:
>>
>>> It'd be great if we could specify semantics for Atomic:add like we
>>> do for Atomic::cmpchgx.
>>> However, the double-fence is a very bad default from performance
>>> perspective. I wonder if PPC64 is the only platform which gets hit.
>> Probably not.
>>
>>> Would it be acceptable to set the default to
>>> memory_order_acquire_release and specify memory_order_conservative
>>> for the new usage? I think this would fit perfectly for PPC64, but
>>> some people may not like it. One could say PPC64 is the problem, but
>>> one could also say the VM code is the problem ??
>> Indeed. In as much as we use stronger memory ordering than we need in
>> more than one place, the VM code is the problem.
>>
>>> I don't really like the straight forward fix to insert a fence with
>>> #ifdef AIX.
>> I agree. It looks to me like it's sufficient if the increment of
>> global_counter and the load of thread->get_rcu_counter() are
>> sequentially consistent. On at least one platform, AArch64, we can
>> do that without additional fencing.
> I would also like to have seq_cst available. In the Access API, I need
> MO_SEQ_CST for JMM volatile support. I would like the semantic
> requirements to go straight into Atomic, instead of doing a "if
> (support_IRIW_for_not_multiple_copy_atomic_cpu) { OrderAccess::fence();
> }" dance in shared code, that may or may not make sense at a given
> platform (among other reasons because it enforces whether leading or
> trailing sync convention is used in shared code, rather than leave that
> decision to the platform level). Plus I have a mouse pad that says I
> love sequential consistency, although that might not be a valid argument
> to introduce this to Atomic.
>
> Thanks,
> /Erik
From erik.osterlund at oracle.com Tue Apr 24 16:27:53 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Tue, 24 Apr 2018 18:27:53 +0200
Subject: RFR 8201799: Build failures after JDK-8195099 (Concurrent
safe-memory-reclamation mechanism)
In-Reply-To: <a5b2cd7ee8ec4c77a8258cf0d40687fb@sap.com>
References: <150dc231-d81e-58da-fa46-fd2397bb7ca2@redhat.com>
<ee7c6a6c-7697-ca4b-dd3d-484ca24aeabd@oracle.com> <5AD73E53.90904@oracle.com>
<803cb23d4b754d2384d9681950f5297c@sap.com>
<661ce2cc-2ea7-9a99-e646-ac3fd8c3494e@redhat.com>
<5ADDB823.5060002@oracle.com> <8d27cc92babd424e878ca6312000db3d@sap.com>
<a5b2cd7ee8ec4c77a8258cf0d40687fb@sap.com>
Message-ID: <3f11a24d-002d-8b54-0363-be9f1ff19198@oracle.com>
Hi Martin,
That is incorrect. With C++11, you can choose both what memory ordering
semantics successful CAS and failing CAS should have.
Thanks,
/Erik
On 2018-04-24 16:01, Doerr, Martin wrote:
> Hi again,
>
> another issue with C++ 2011 on PPC64 is that Cmpxchg Acquire/AcqRel/SeqCst don't acquire in case of failing Cmpxchg while our Atomic::PlatformCmpxchg does that. I believe that there are places in hotspot which rely on that. So I guess that all "else" cases will need to get double-checked and possibly get enhanced by leading OrderAccess:acquire().
>
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: Doerr, Martin
> Sent: Dienstag, 24. April 2018 15:44
> To: 'Erik ?sterlund' <erik.osterlund at oracle.com>; Andrew Haley <aph at redhat.com>; David Holmes <david.holmes at oracle.com>; Aleksey Shipilev <shade at redhat.com>; hotspot-dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Subject: RE: RFR 8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism)
>
> Hi Erik,
>
> I highly appreciate if we can get the VM code to work correctly with C++ 2011 semantics on PPC64.
> But I think this needs to be done very carefully in order to avoid missing sync instructions between CAS and Load.
>
> E.g. the new global counter implementation uses (after fix):
> Atomic::add(memory_order_conservative) + OrderAccess::load_acquire
>
> In C++2011 this should become:
> Cmpxchg SeqCst + Load Seq Cst
>
> Cmpxchg SeqCst + any other Load would be incorrect on PPC64. So we will need to double-check all corresponding loads.
>
> I've seen that you have moved the support_IRIW_for_not_multiple_copy_atomic_cpu fence into RawAccessBarrier<decorators>::load_internal. Ideally, RawAccessBarrier<decorators>::store_internal should use OrderAccess::release_store without fence in case of support_IRIW_for_not_multiple_copy_atomic_cpu, but I'm not requesting to change this now. We'd get this by moving to C++ 2011 semantics (which assumes support_IRIW_for_not_multiple_copy_atomic_cpu), right?
>
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: Erik ?sterlund [mailto:erik.osterlund at oracle.com]
> Sent: Montag, 23. April 2018 12:41
> To: Andrew Haley <aph at redhat.com>; Doerr, Martin <martin.doerr at sap.com>; David Holmes <david.holmes at oracle.com>; Aleksey Shipilev <shade at redhat.com>; hotspot-dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Subject: Re: RFR 8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism)
>
> Hi Andrew,
>
> On 2018-04-23 12:20, Andrew Haley wrote:
>> On 04/18/2018 05:37 PM, Doerr, Martin wrote:
>>
>>> It'd be great if we could specify semantics for Atomic:add like we
>>> do for Atomic::cmpchgx.
>>> However, the double-fence is a very bad default from performance
>>> perspective. I wonder if PPC64 is the only platform which gets hit.
>> Probably not.
>>
>>> Would it be acceptable to set the default to
>>> memory_order_acquire_release and specify memory_order_conservative
>>> for the new usage? I think this would fit perfectly for PPC64, but
>>> some people may not like it. One could say PPC64 is the problem, but
>>> one could also say the VM code is the problem ??
>> Indeed. In as much as we use stronger memory ordering than we need in
>> more than one place, the VM code is the problem.
>>
>>> I don't really like the straight forward fix to insert a fence with
>>> #ifdef AIX.
>> I agree. It looks to me like it's sufficient if the increment of
>> global_counter and the load of thread->get_rcu_counter() are
>> sequentially consistent. On at least one platform, AArch64, we can
>> do that without additional fencing.
> I would also like to have seq_cst available. In the Access API, I need
> MO_SEQ_CST for JMM volatile support. I would like the semantic
> requirements to go straight into Atomic, instead of doing a "if
> (support_IRIW_for_not_multiple_copy_atomic_cpu) { OrderAccess::fence();
> }" dance in shared code, that may or may not make sense at a given
> platform (among other reasons because it enforces whether leading or
> trailing sync convention is used in shared code, rather than leave that
> decision to the platform level). Plus I have a mouse pad that says I
> love sequential consistency, although that might not be a valid argument
> to introduce this to Atomic.
>
> Thanks,
> /Erik
From rkennke at redhat.com Tue Apr 24 16:46:09 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 24 Apr 2018 18:46:09 +0200
Subject: RFR: 8201543: Modularize C1 GC barriers
In-Reply-To: <fee256d2-c693-c9fc-23ac-d47b6cb38c2a@oracle.com>
References: <5AD0C89E.7050807@oracle.com> <5AD9EFE3.4020203@oracle.com>
<ca47d015-a9a6-55c4-267c-50a674619fb4@redhat.com>
<fee256d2-c693-c9fc-23ac-d47b6cb38c2a@oracle.com>
Message-ID: <28ab14d0-9081-a9d2-cbd5-951ed8b7c720@redhat.com>
Hi Erik,
>> - At the same time, do you think the resolve_address() provides a place
>> for GC like Shenandoah that needs to resolve the base object and insert
>> a read/write-barrier and *then* resolve the barrier(base)+offset? If
>> this is the intention, may I request to somehow carry over the
>> information whether or not the address is intended for read or write?
>> Because we need insert different barriers on reads vs writes. Maybe this
>> can be added in the decorators?
>
> Yes that was my intention indeed. I added in a C1_WRITE_ACCESS and
> C1_READ_ACCESS decorator for your convenience. Loads have
> C1_READ_ACCESS, stores have C1_WRITE_ACCESS, and atomics have both.
Perfect! I think that is good enough for my purposes.
> Full webrev:
> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.02/
>
> Incremental webrev:
> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.01_02/
>
> It's a good place for ModRef to check whether resolving to a register is
> needed or not too (only required for accesses with write barriers).
Ok, seems fine to me.
>> - Or is the intention to resolve the base object on the actual
>> load_at_resolved() etc entry points? As far as I can tell this would be
>> difficult because we don't get to see the base object anymore?
>
> I think it's best done in resolve. But note that you get the access
> wrapper in the resolved paths, and it retains the base pointer if you
> need it.
>
>> - Thinking forward a little bit... Shenandoah is going to need some
>> resolve-hooks in a couple of places that are not practical to handle via
>> load/store style access calls. For example in monitorenter/exit code we
>> need to insert a write-barrier on the object to be synchronized on. Will
>> this be possible/practical to do via resolve_address()?
>
> I think we should probably add a public resolve barrier for that purpose.
Ok. I will take care of it as soon as this change is pushed.
>> - Does it already handle primitive accesses? From the looks of it, I'd
>> say yes. That'd be nice.
>
> The backends should be ready for it. But I think I will leave the
> exercise of finding the callsites to you, as you have spent more time
> finding where they are needed.
Yup, absolutely.
Thanks again for doing this!
Roman
From vladimir.kozlov at oracle.com Tue Apr 24 16:50:53 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 24 Apr 2018 09:50:53 -0700
Subject: [11] RFR(XS) 8202152:
test/hotspot/jtreg/runtime/whitebox/WBStackSize.java fails
In-Reply-To: <441f80793c224b448502710fe8aa806b@sap.com>
References: <074d0bb7-4d1e-91a2-541f-50ecd9eb4cb6@oracle.com>
<df053f49-ff6a-0c9e-1589-95b6a1dc5abb@oracle.com>
<84dc4c3c-6e00-189d-755a-aa0a257d5f93@oracle.com>
<31ee2175-349e-8f0c-4bc7-0bd58faabfe0@oracle.com>
<441f80793c224b448502710fe8aa806b@sap.com>
Message-ID: <236696b2-17c1-3b42-6e97-2073101a06b3@oracle.com>
Thank you, David and Martin
I added comment as David suggested and fixed incorrect exception
messages (because HotSpotDiagnosticMXBean is not used in test):
http://cr.openjdk.java.net/~kvn/8202152/webrev.01/
Thanks,
Vladimir
On 4/24/18 1:22 AM, Doerr, Martin wrote:
> Hi Vladimir,
>
> looks good. Thanks for fixing.
> The comment proposed by David would be nice, but I don't need to see a new webrev for that.
>
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Holmes
> Sent: Dienstag, 24. April 2018 08:12
> To: Vladimir Kozlov <vladimir.kozlov at oracle.com>; hotspot-dev Source Developers <hotspot-dev at openjdk.java.net>
> Subject: Re: [11] RFR(XS) 8202152: test/hotspot/jtreg/runtime/whitebox/WBStackSize.java fails
>
> On 24/04/2018 3:54 PM, David Holmes wrote:
>> To follow up ... Vladimir and I have had an interesting back and forth
>> in the bug report. It seems that at least in some cases terminated
>> threads are getting recycled - not just their pthread_t identities but
>> the actual allocated stack region as well. We seem to end up with a new
>> regular Java thread acquiring the id and stack of a just terminated
>> compiler thread - hence the regular Java thread gets the wrong size stack!
>>
>> This is quite bizarre and seems quite broken.
>
> No it's not broken. The stacksize attribute is just a minimum size, so
> the OS can reuse a terminated thread with a larger stack - and that's
> what we are seeing.
>
> So the fix is fine, I would just add before @run:
>
> @comment Must use the same stacksize for Java threads and compiler
> threads in case of thread recycling
>
> Or something to that affect.
>
> Thanks,
> David
>
>> David
>>
>> On 24/04/2018 7:24 AM, David Holmes wrote:
>>> Hi Vladimir,
>>>
>>> On 24/04/2018 5:20 AM, Vladimir Kozlov wrote:
>>>> http://cr.openjdk.java.net/~kvn/8202152/webrev.00/
>>>> https://bugs.openjdk.java.net/browse/JDK-8202152
>>>>
>>>> After 8198756 changes compiler threads could be released and other
>>>> Java threads can re-use the same HW threads for which stack size was
>>>> determined during start. The test WBStackSize.java may fail in such
>>>> cases because Java thread stack size is set and checked in test.
>>>
>>> That does not make sense to me. We don't "re-use HW threads" - I'm not
>>> even sure what that means. Compiler threads have a different stacksize
>>> to other Java threads - that seems simple enough.
>>>
>>>> For 8198756 changes we added thread name check to workaround the
>>>> problem [1]. But it seems is not enough.
>>>
>>> Why would this test be run in a compiler thread ????
>>>
>>>> To avoid this issue I added -XX:CompilerThreadStackSize=512 flag to
>>>> match Java thread stack size (note, size is in Kb for this flag).
>>>
>>> That seems like a workaround of the real problem.
>>>
>>> David
>>> -----
>>>
>>>> I also reverted changes in test code and instead added thread name
>>>> print to know in case we still have problem in a future.
>>>>
>>>> Tier1 testing (which run the test) passed.
>>>>
From coleen.phillimore at oracle.com Tue Apr 24 16:59:07 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 24 Apr 2018 12:59:07 -0400
Subject: RFR (XXS) 8202164: Remove some unneeded BoolObjectClosure*
is_alive parameters
In-Reply-To: <2bf6869c-2801-c31a-2665-286d43989c91@oracle.com>
References: <60fb0500-7b14-6fa7-624c-60af670d3d13@oracle.com>
<B0FE2EF5-DA0E-45BC-B557-3075B7D60380@oracle.com>
<2bf6869c-2801-c31a-2665-286d43989c91@oracle.com>
Message-ID: <aa1a7f9c-bea5-1edb-0f5a-280c561ff076@oracle.com>
Thanks for the code review.
Coleen
On 4/24/18 1:39 AM, Stefan Karlsson wrote:
> Looks good (with Kim's suggestions)
>
> StefanK
>
> On 2018-04-24 03:28, Kim Barrett wrote:
>>> On Apr 23, 2018, at 7:12 PM, coleen.phillimore at oracle.com wrote:
>>>
>>> See bug for details.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8202164.01/webrev
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8202164
>>>
>>> Tested with runThese (lots of class unloading) for all the GCs and
>>> with mach5 hs-tier1 and 2.
>>> Thanks,
>>> Coleen
>> I don?t think I?d call this XXS.
>>
>> Looks good.
>>
>> Needs a couple comment updates; I don't need a new webrev for these.
>>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/share/code/nmethod.cpp
>> 1039?? flush_dependencies(/*delete_immediately*/false);
>>
>> The preceding comment needs to be updated; there's no longer a closure
>> involved.
>>
>> ------------------------------------------------------------------------------
>>
>> src/hotspot/share/code/nmethod.cpp
>> 1364???????? // During GC delete_immediately is false, and is used to
>> 1365???????? // determine liveness of dependees that need to be updated.
>> 1366???????? if (delete_immediately || klass->is_loader_alive()) {
>>
>> The comment needs to be updated; delete_immediately doesn't determine
>> liveness.
>>
>> ------------------------------------------------------------------------------
>>
>>
>
From martin.doerr at sap.com Tue Apr 24 17:02:21 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 24 Apr 2018 17:02:21 +0000
Subject: RFR 8201799: Build failures after JDK-8195099 (Concurrent
safe-memory-reclamation mechanism)
In-Reply-To: <0d76e23a-a61a-c77f-a41d-fa6099ecdc51@oracle.com>
References: <150dc231-d81e-58da-fa46-fd2397bb7ca2@redhat.com>
<ee7c6a6c-7697-ca4b-dd3d-484ca24aeabd@oracle.com> <5AD73E53.90904@oracle.com>
<803cb23d4b754d2384d9681950f5297c@sap.com>
<661ce2cc-2ea7-9a99-e646-ac3fd8c3494e@redhat.com>
<5ADDB823.5060002@oracle.com> <8d27cc92babd424e878ca6312000db3d@sap.com>
<0d76e23a-a61a-c77f-a41d-fa6099ecdc51@oracle.com>
Message-ID: <233865c337b14531acd0dd9fceb9c01d@sap.com>
Hi Erik,
> I was not suggesting removing the more conservative ordering property,
> only allowing using seq_cst, when you know that is the correct semantics.
Ok, thanks for clarifying.
> There are both leading sync and trailing sync conventions for
> implementing C++11 seq_cst on PPC
I'm not convinced that this can be freely selected.
Is there a GCC switch? What about xlC on AIX?
The trailing sync convention would have a different weakness: Store + Cmpxchg
The store will have to be SeqCst in order to generate correct code on PPC64.
Even if we can select it in C++, it would be unfortunate if it differs from JMM.
JMM should not be changed for the sake of C++ implementation cleanup.
We have "JEP 188: Java Memory Model Update" for that.
From the other mail:
> With C++11, you can choose both what memory ordering
> semantics successful CAS and failing CAS should have
You're right. We just need to use it correctly.
Thanks and best regards,
Martin
-----Original Message-----
From: Erik ?sterlund [mailto:erik.osterlund at oracle.com]
Sent: Dienstag, 24. April 2018 18:25
To: Doerr, Martin <martin.doerr at sap.com>; Andrew Haley <aph at redhat.com>; David Holmes <david.holmes at oracle.com>; Aleksey Shipilev <shade at redhat.com>; hotspot-dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Subject: Re: RFR 8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism)
Hi Martin,
On 2018-04-24 15:43, Doerr, Martin wrote:
> Hi Erik,
>
> I highly appreciate if we can get the VM code to work correctly with C++ 2011 semantics on PPC64.
> But I think this needs to be done very carefully in order to avoid missing sync instructions between CAS and Load.
I was not suggesting removing the more conservative ordering property,
only allowing using seq_cst, when you know that is the correct semantics.
> E.g. the new global counter implementation uses (after fix):
> Atomic::add(memory_order_conservative) + OrderAccess::load_acquire
>
> In C++2011 this should become:
> Cmpxchg SeqCst + Load Seq Cst
>
> Cmpxchg SeqCst + any other Load would be incorrect on PPC64. So we will need to double-check all corresponding loads.
This might be getting out of topic, but here goes...
There are both leading sync and trailing sync conventions for
implementing C++11 seq_cst on PPC. What you are saying is true for the
leading sync convention, but not for the trailing sync convention. In
HotSpot, I think it is probably more desirable to bind the expectations
for *all* seq_cst accesses to have trailing sync convention to avoid
this issue of seq_cst store followed by load_acquire being reordered. I
don't think we want a situation where PPC implements leading sync
(despite being able to choose trailing sync), when AArch64 uses trailing
sync. But perhaps this is derailing a bit...
> I've seen that you have moved the support_IRIW_for_not_multiple_copy_atomic_cpu fence into RawAccessBarrier<decorators>::load_internal. Ideally, RawAccessBarrier<decorators>::store_internal should use OrderAccess::release_store without fence in case of support_IRIW_for_not_multiple_copy_atomic_cpu, but I'm not requesting to change this now. We'd get this by moving to C++ 2011 semantics (which assumes support_IRIW_for_not_multiple_copy_atomic_cpu), right?
That code should really call into Atomic/OrderAccess with seq_cst, and
let the platform layer do what it needs to do.
Thanks,
/Erik
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: Erik ?sterlund [mailto:erik.osterlund at oracle.com]
> Sent: Montag, 23. April 2018 12:41
> To: Andrew Haley <aph at redhat.com>; Doerr, Martin <martin.doerr at sap.com>; David Holmes <david.holmes at oracle.com>; Aleksey Shipilev <shade at redhat.com>; hotspot-dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Subject: Re: RFR 8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism)
>
> Hi Andrew,
>
> On 2018-04-23 12:20, Andrew Haley wrote:
>> On 04/18/2018 05:37 PM, Doerr, Martin wrote:
>>
>>> It'd be great if we could specify semantics for Atomic:add like we
>>> do for Atomic::cmpchgx.
>>> However, the double-fence is a very bad default from performance
>>> perspective. I wonder if PPC64 is the only platform which gets hit.
>> Probably not.
>>
>>> Would it be acceptable to set the default to
>>> memory_order_acquire_release and specify memory_order_conservative
>>> for the new usage? I think this would fit perfectly for PPC64, but
>>> some people may not like it. One could say PPC64 is the problem, but
>>> one could also say the VM code is the problem ??
>> Indeed. In as much as we use stronger memory ordering than we need in
>> more than one place, the VM code is the problem.
>>
>>> I don't really like the straight forward fix to insert a fence with
>>> #ifdef AIX.
>> I agree. It looks to me like it's sufficient if the increment of
>> global_counter and the load of thread->get_rcu_counter() are
>> sequentially consistent. On at least one platform, AArch64, we can
>> do that without additional fencing.
> I would also like to have seq_cst available. In the Access API, I need
> MO_SEQ_CST for JMM volatile support. I would like the semantic
> requirements to go straight into Atomic, instead of doing a "if
> (support_IRIW_for_not_multiple_copy_atomic_cpu) { OrderAccess::fence();
> }" dance in shared code, that may or may not make sense at a given
> platform (among other reasons because it enforces whether leading or
> trailing sync convention is used in shared code, rather than leave that
> decision to the platform level). Plus I have a mouse pad that says I
> love sequential consistency, although that might not be a valid argument
> to introduce this to Atomic.
>
> Thanks,
> /Erik
From jini.george at oracle.com Tue Apr 24 17:03:03 2018
From: jini.george at oracle.com (Jini George)
Date: Tue, 24 Apr 2018 22:33:03 +0530
Subject: RFR: JDK-8202200: set INCLUDE_SA to false on s390x by default
-was : RE: INCLUDE_SA/serviceability agent - support on s390x
In-Reply-To: <6a3fba0f7abd4ac38de4a13fd8ec33ef@sap.com>
References: <6a3fba0f7abd4ac38de4a13fd8ec33ef@sap.com>
Message-ID: <8f19239b-fc06-1712-a297-5148b0df6a67@oracle.com>
Looks good to me, Matthias.
Thank you,
Jini.
On 4/24/2018 9:39 PM, Baesken, Matthias wrote:
> Hi Jini, the removal of the mentioned headers leads to build errors so we better keep it .
> Error is when the headers are removed :
>
> /nb/linuxs390x/nightly/jdk/src/hotspot/share/runtime/vmStructs.cpp:100:31: fatal error: vmStructs_s390.hpp: No such file or directory
> #include CPU_HEADER(vmStructs)
>
>
> I uploaded a webrev for review :
>
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8202200/
>
> bug :
>
> https://bugs.openjdk.java.net/browse/JDK-8202200
>
>
>
> Best regards, Matthias
>
>
>> -----Original Message-----
>> From: Jini George [mailto:jini.george at oracle.com]
>> Sent: Dienstag, 24. April 2018 08:58
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
>> dev at openjdk.java.net' <build-dev at openjdk.java.net>
>> Cc: serviceability-dev at openjdk.java.net; Schmidt, Lutz
>> <lutz.schmidt at sap.com>
>> Subject: Re: INCLUDE_SA/serviceability agent - support on s390x
>>
>> Hi Matthias,
>>
>> Your change looks good to me. It might make sense to also remove the
>> following lines from:
>>
>> src/jdk.hotspot.agent/linux/native/libsaproc/libproc.h
>>
>> 78 #if defined(s390x)
>> 79 #include <asm/ptrace.h>
>> 80 #endif
>>
>> I am not sure if the following files are required either:
>> src/hotspot/cpu/s390/vmStructs_s390.hpp
>> src/hotspot/os_cpu/linux_s390/vmStructs_linux_s390.hpp
>>
>> Thanks,
>> Jini (Not a Reviewer).
>>
>>
>> On 4/23/2018 5:31 PM, Baesken, Matthias wrote:
>>> Hello,?? as far as I know? the serviceability agent?? is not? supported
>>> on? linux s390x .
>>>
>>> However? (unlike? on aix where it is not supported as well) ,
>>> ?INCLUDE_SA=false??? is not set? in the central configure? m4 files .
>>>
>>> Should we set it? ( suggested diff below)? ?
>>>
>>> Best regards, Matthias
>>>
>>> hg diff
>>>
>>> diff -r fcd5df7aa235 make/autoconf/jdk-options.m4
>>>
>>> --- a/make/autoconf/jdk-options.m4????? Wed Apr 18 11:19:32 2018 +0200
>>>
>>> +++ b/make/autoconf/jdk-options.m4????? Mon Apr 23 13:46:17 2018 +0200
>>>
>>> @@ -238,6 +238,9 @@
>>>
>>> ?? if test "x$OPENJDK_TARGET_OS" = xaix ; then
>>>
>>> ???? INCLUDE_SA=false
>>>
>>> ?? fi
>>>
>>> +? if test "x$OPENJDK_TARGET_CPU" = xs390x ; then
>>>
>>> +??? INCLUDE_SA=false
>>>
>>> +? fi
>>>
>>> ?? AC_SUBST(INCLUDE_SA)
>>>
>>> # Compress jars
>>>
>>> Best regards, Matthias
>>>
From kim.barrett at oracle.com Tue Apr 24 18:23:51 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 24 Apr 2018 14:23:51 -0400
Subject: RFR: 8202082: Remove explicit CMS checks in
CardTableBarrierSetAssembler
In-Reply-To: <67ac1742-640e-f011-f371-cf53b782e969@oracle.com>
References: <5AD9FC94.70607@oracle.com>
<6A476A6A-47BB-4141-980E-DB98D9BAD405@oracle.com>
<67ac1742-640e-f011-f371-cf53b782e969@oracle.com>
Message-ID: <60EA410E-E1FE-4A54-95CA-E3F11CC9B168@oracle.com>
> On Apr 24, 2018, at 2:57 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>
> Hi Kim,
>
> On 2018-04-24 04:15, Kim Barrett wrote:
>>> On Apr 20, 2018, at 10:43 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> In CardTableBarrierSetAssembler, we sometimes need fencing due to the card table being scanned concurrently when using CMS with pre-cleaning. Rather than explicitly checking for those CMS flags in the generic CardTableBarrierSetAssembler class, it is preferrable to check the CardTable scanned_concurrently() property which already precisely reflects that.
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8202082
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.00/
>>>
>>> Thanks,
>>> /Erik
>> ------------------------------------------------------------------------------
>> src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
>> 121 if (ct->scanned_concurrently()) {
>>
>> I think the correct test here is card_mark_must_follow_store. See
>> my review of 8202083 for more details.
>>
>> Similarly for the other platforms.
>
> I disagree. Let me explain why, and where I am trying to get with this.
>
> We used to have a whole bunch of different ways of making decisions based on whether the card table is scanned concurrently or not, queried in various ways, depending on whether we were talking to the CollectedHeap interface, the CardTableModRefBS interface, or whether we were inside of the CardTableModRefBS class. I am trying to remove those one by one, until only one is left, the configuration point in CardTable which describes precisely that: that the card table is scanned concurrently. Here are a few examples:
>
> * The ReduceInitialCardMarks optimization either defers card marks or issues them immediately on slowpath allocations, depending on whether the card table is scanned concurrently or not (this used to ask CollectedHeap about these queries).
> * Inside of the post barriers, StoreStore fencing between the reference store and card mark depends on whether the card table is scanned concurrently or not. (checked with explicit CMS + precleaning and sometimes conservatively just CMS checks)
> * When using UseCondCardMark, there is a StoreLoad fence to make sure the store of the reference happens-before the *load* of the card value (not the store of the card value) for filtering. Again, this is only an issue when the card table is scanned concurrently, and not very well described by whether the card mark must follow the store IMO.
>
> The reason there is not yet a single property is that some code has previously asked CollectedHeap about these questions from outside of GC code (ReduceInitialCardMarks), while other code lived in the card table barrier set (CMS + pre-cleaning checks). Where I want to go is that no code outside of the CardTableBarrierSet classes should need to ask these questions. And code inside of the CardTableBarrierSet classes should ask its CardTable, which acts as a configuration, whether it is scanned concurrently or not.
>
> So basically, I would prefer to now remove the card_mark_must_follow_store() method, and replace it with direct calls to whether the card table is scanned concurrently.
>
> Do you agree?
I agree that fewer sources for what is effectively the same
information would be good. I just don't think CardTable is the right
place for this piece of information. CardTable is (largely) a
"simple" data structure (*), and doesn't care whether it's scanned
concurrently or not. I think it belongs in the CTBS.
(*) I think CardTable could be simpler. It presently contains a fair
amount of stuff that seems only needed by CMS or only needed by G1,
and should perhaps be placed elsewhere.
>> ------------------------------------------------------------------------------
>> src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
>> 113 AddressLiteral cardtable((address)ctbs->card_table()->byte_map_base(), relocInfo::none);
>>
>> [pre-existing]
>>
>> Why isn't this using (address)disp rather than refetching the value.
>>
>> ------------------------------------------------------------------------------
>
> That seems unrelated to my changes.
Sort of; I did note it as pre-existing, but this line is being
changed. And you've added a variable early in the method for the card
table, yet it isn't being used in the initializer for disp or in the
argument for cardtable construction. Why not
intptr_t disp = (intptr_t) ct->byte_map_base();
...
AddressLiteral cardtable((address)disp, relocInfo::none);
That would have saved me some staring at these expressions to figure
out that there weren't any differences.
Although the ct variable was added for a later use that I've disagreed
with above...
From glaubitz at physik.fu-berlin.de Tue Apr 24 18:42:15 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 24 Apr 2018 20:42:15 +0200
Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for
ppc64
In-Reply-To: <cbc8950b-4f42-a550-4550-5dcb9ac29fd4@linux.vnet.ibm.com>
References: <OF16DAB34F.17FD9ED8-ON00258278.002211BA-49258278.003A0AFD@notes.na.collabserv.com>
<63793e9f7b0e4989a9716cf87be3c7fe@sap.com>
<e1718644-9a70-2636-bdfc-a9508e4cda78@physik.fu-berlin.de>
<cbc8950b-4f42-a550-4550-5dcb9ac29fd4@linux.vnet.ibm.com>
Message-ID: <95f13bd2-c173-fa2b-4454-cd101b79126d@physik.fu-berlin.de>
Hi Gustavo!
On 04/24/2018 05:54 PM, Gustavo Romero wrote:
>> Quick question: Does this pose any assumptions on the instruction set baseline
>> on ppc64? I haven't build-tested this yet, but I want to avoid it doesn't break
>> on POWER5, for example, which is used in Debian's big-endian ppc64 port.
>
> Yes, it does. But POWER5 and above are ok. Lightweight sync (lwsync) was
> introduced with Power ISA v2.03 which, by its turn, maps to POWER5.
We are primarily interested in PPC970 and compatible which - according
to Wikipedia - is compliant with POWER ISA 2.03:
> https://en.wikipedia.org/wiki/Power_Architecture#Power_ISA_v.2.03
It's sometimes a bit confusing to differentiate all the different
POWER ISAs because there are so many. That's why I usually ask
in such cases.
> Thanks for taking care of Power + Debian :-)
You're welcome. Debian has both a big-endian (POWER5/970) and little-endian
(POWER8) ppc64 port as well as powerpc (32-bit) and powerpcspe (e500v2)
ports, so PowerPC is quite popular within Debian ;).
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From erik.osterlund at oracle.com Tue Apr 24 19:17:08 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Tue, 24 Apr 2018 21:17:08 +0200
Subject: RFR: 8202082: Remove explicit CMS checks in
CardTableBarrierSetAssembler
In-Reply-To: <60EA410E-E1FE-4A54-95CA-E3F11CC9B168@oracle.com>
References: <5AD9FC94.70607@oracle.com>
<6A476A6A-47BB-4141-980E-DB98D9BAD405@oracle.com>
<67ac1742-640e-f011-f371-cf53b782e969@oracle.com>
<60EA410E-E1FE-4A54-95CA-E3F11CC9B168@oracle.com>
Message-ID: <9c283f66-326a-d640-432d-b6c573802b5e@oracle.com>
Hi Kim,
On 2018-04-24 20:23, Kim Barrett wrote:
>> On Apr 24, 2018, at 2:57 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>>
>> Hi Kim,
>>
>> On 2018-04-24 04:15, Kim Barrett wrote:
>>>> On Apr 20, 2018, at 10:43 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> In CardTableBarrierSetAssembler, we sometimes need fencing due to the card table being scanned concurrently when using CMS with pre-cleaning. Rather than explicitly checking for those CMS flags in the generic CardTableBarrierSetAssembler class, it is preferrable to check the CardTable scanned_concurrently() property which already precisely reflects that.
>>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8202082
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.00/
>>>>
>>>> Thanks,
>>>> /Erik
>>> ------------------------------------------------------------------------------
>>> src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
>>> 121 if (ct->scanned_concurrently()) {
>>>
>>> I think the correct test here is card_mark_must_follow_store. See
>>> my review of 8202083 for more details.
>>>
>>> Similarly for the other platforms.
>> I disagree. Let me explain why, and where I am trying to get with this.
>>
>> We used to have a whole bunch of different ways of making decisions based on whether the card table is scanned concurrently or not, queried in various ways, depending on whether we were talking to the CollectedHeap interface, the CardTableModRefBS interface, or whether we were inside of the CardTableModRefBS class. I am trying to remove those one by one, until only one is left, the configuration point in CardTable which describes precisely that: that the card table is scanned concurrently. Here are a few examples:
>>
>> * The ReduceInitialCardMarks optimization either defers card marks or issues them immediately on slowpath allocations, depending on whether the card table is scanned concurrently or not (this used to ask CollectedHeap about these queries).
>> * Inside of the post barriers, StoreStore fencing between the reference store and card mark depends on whether the card table is scanned concurrently or not. (checked with explicit CMS + precleaning and sometimes conservatively just CMS checks)
>> * When using UseCondCardMark, there is a StoreLoad fence to make sure the store of the reference happens-before the *load* of the card value (not the store of the card value) for filtering. Again, this is only an issue when the card table is scanned concurrently, and not very well described by whether the card mark must follow the store IMO.
>>
>> The reason there is not yet a single property is that some code has previously asked CollectedHeap about these questions from outside of GC code (ReduceInitialCardMarks), while other code lived in the card table barrier set (CMS + pre-cleaning checks). Where I want to go is that no code outside of the CardTableBarrierSet classes should need to ask these questions. And code inside of the CardTableBarrierSet classes should ask its CardTable, which acts as a configuration, whether it is scanned concurrently or not.
>>
>> So basically, I would prefer to now remove the card_mark_must_follow_store() method, and replace it with direct calls to whether the card table is scanned concurrently.
>>
>> Do you agree?
> I agree that fewer sources for what is effectively the same
> information would be good. I just don't think CardTable is the right
> place for this piece of information. CardTable is (largely) a
> "simple" data structure (*), and doesn't care whether it's scanned
> concurrently or not. I think it belongs in the CTBS.
Whether the CardTable is scanned concurrently or not is the property we
are consistently interested in. That is a natural property of the
CardTable to me, and hence belongs in the CardTable. I don't see a
convincing argument why it would not be a natural property of the
CardTable. Conversely, I find that it would mess up GenCollectedHeap if
it was not. Currently, the GenCollectedHeaps unconditionally
instantiates a CardTableBarrierSet, with a single configuration
parameter: the CardTable, which is created with a virtual call as either
CardTableRS or CMSCardTable. With your proposal to move the property of
whether the CardTable is scanned concurrently or not, out from the
CardTable, that would inevitably result in more virtual calls only for
configuring the CardTableBarrierSet with this property, or make the
CardTableBarrierSet itself into a configuration (created with virtual
calls). That does not look like a win to me. Do you agree?
> (*) I think CardTable could be simpler. It presently contains a fair
> amount of stuff that seems only needed by CMS or only needed by G1,
> and should perhaps be placed elsewhere.
Sure. Those things should be moved into CMSCardTable and G1CardTable
respectively.
>>> ------------------------------------------------------------------------------
>>> src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
>>> 113 AddressLiteral cardtable((address)ctbs->card_table()->byte_map_base(), relocInfo::none);
>>>
>>> [pre-existing]
>>>
>>> Why isn't this using (address)disp rather than refetching the value.
>>>
>>> ------------------------------------------------------------------------------
>> That seems unrelated to my changes.
> Sort of; I did note it as pre-existing, but this line is being
> changed. And you've added a variable early in the method for the card
> table, yet it isn't being used in the initializer for disp or in the
> argument for cardtable construction. Why not
>
> intptr_t disp = (intptr_t) ct->byte_map_base();
> ...
> AddressLiteral cardtable((address)disp, relocInfo::none);
>
> That would have saved me some staring at these expressions to figure
> out that there weren't any differences.
>
> Although the ct variable was added for a later use that I've disagreed
> with above...
Okay. I will fix it then.
/Erik
From kim.barrett at oracle.com Tue Apr 24 19:17:55 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 24 Apr 2018 15:17:55 -0400
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
readdir_r(DIR*, dirent*, dirent**)' is deprecated
In-Reply-To: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
Message-ID: <D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
> On Apr 23, 2018, at 3:51 AM, Michal Vala <mvala at redhat.com> wrote:
>
> Hi,
>
> following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm posting updated patch replacing deprecated readdir_r with readdir. Bug ID is JDK-8179887 [2].
>
> webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
>
> I'm asking for the review and eventually sponsorship.
The change to os::readdir in os_linux.inline.hpp looks fine.
I was going to suggest that rather than changing perfMemory_linux.cpp to use os::readdir in an
unusual and platform-specific way, it should instead just call ::readdir directly. However, neither
of those is right, and that part of the change should not be made; see
https://bugs.openjdk.java.net/browse/JDK-8134540
Much nearly duplicated code for PerfMemory support
Looking a bit deeper, there might be some additional follow-on that could be done, eliminating
the second argument to os::readdir.
windows: unused
bsd: freebsd also deprecated readdir_r, I think for similar reasons.
solaris: doc is clear about thread safety issue being about sharing the DIR*
aix: I haven?t looked at it, but would guess it?s similar.
In other words, don?t operate on the DIR* from multiple threads simultaneously, and just use
::readdir on non-Windows. That would all be for another RFE though.
From erik.osterlund at oracle.com Tue Apr 24 20:02:55 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Tue, 24 Apr 2018 22:02:55 +0200
Subject: RFR 8201799: Build failures after JDK-8195099 (Concurrent
safe-memory-reclamation mechanism)
In-Reply-To: <233865c337b14531acd0dd9fceb9c01d@sap.com>
References: <150dc231-d81e-58da-fa46-fd2397bb7ca2@redhat.com>
<ee7c6a6c-7697-ca4b-dd3d-484ca24aeabd@oracle.com> <5AD73E53.90904@oracle.com>
<803cb23d4b754d2384d9681950f5297c@sap.com>
<661ce2cc-2ea7-9a99-e646-ac3fd8c3494e@redhat.com>
<5ADDB823.5060002@oracle.com> <8d27cc92babd424e878ca6312000db3d@sap.com>
<0d76e23a-a61a-c77f-a41d-fa6099ecdc51@oracle.com>
<233865c337b14531acd0dd9fceb9c01d@sap.com>
Message-ID: <3ed44888-420e-4a0b-0bc6-184c6ae14287@oracle.com>
Hi Martin,
On 2018-04-24 19:02, Doerr, Martin wrote:
> Hi Erik,
>
>> I was not suggesting removing the more conservative ordering property,
>> only allowing using seq_cst, when you know that is the correct semantics.
> Ok, thanks for clarifying.
>
>> There are both leading sync and trailing sync conventions for
>> implementing C++11 seq_cst on PPC
> I'm not convinced that this can be freely selected.
> Is there a GCC switch? What about xlC on AIX?
It is not selectable by the compiler, which is why I think we should
generate our own inline assembly where we explicitly choose the
convention as either leading sync or trailing sync, depending on how we
roll (cf. Repairing Sequential Consistency in C/C++11
https://dl.acm.org/citation.cfm?id=3062352 where both leading and
trailing sync bindings for C++11 are provided). Anything else seems
unsafe (to me). When I talk about C++11 semantics, I don't necessarily
mean the chosen implementation by specific compilers. I mean the
semantic properties of seq_cst, acquire, release, acq_rel, consume, etc.
> The trailing sync convention would have a different weakness: Store + Cmpxchg
> The store will have to be SeqCst in order to generate correct code on PPC64.
Sure, if you move the fence from one side to another, but still have one
side lacking a full fence, there will naturally be a possibility of
reordering on the other side. And therefore I am not arguing we
necessarily remove "conservative". Having said that - doesn't this look
like a much less innocent mistake - having some sort of dekker duality
between a relaxed store (?!) and seq_cst cmpxchg/load? I am biased to
think that seems like a much worse and less subtle programmer mistake,
that is easier to understand. We don't even do that on x86 today (we
would use release_store_fence for the store in such a dekker duality),
and it would break more consistently on other platforms too. The
comments in orderAccess.hpp file states: "Use release_store_fence to
update values like the thread state, where we don't want the current
thread to continue until all our prior memory accesses (including the
new thread state) are visible to other threads". Now we can have
opinions about this "visibility" property, but we have arbitrarily tied
it to the stores. Therefore, the fact is that such dekker dualities use
release_store_fence today, and there is no corresponding
fence_load_acquire() operation. Therefore, I think it would seem, in
HotSpot, easier to adopt a trailing sync seq_cst convention, to fit into
existing code conventions. Sorry for derailing further down the rabbit
hole...
> Even if we can select it in C++, it would be unfortunate if it differs from JMM.
> JMM should not be changed for the sake of C++ implementation cleanup.
> We have "JEP 188: Java Memory Model Update" for that.
Sure. The chosen bindings for the JMM would have to comply with that. I
will stop myself from derailing into a conversation about that. :)
> From the other mail:
>> With C++11, you can choose both what memory ordering
>> semantics successful CAS and failing CAS should have
> You're right. We just need to use it correctly.
Indeed. :)
Thanks,
/Erik
> Thanks and best regards,
> Martin
>
>
> -----Original Message-----
> From: Erik ?sterlund [mailto:erik.osterlund at oracle.com]
> Sent: Dienstag, 24. April 2018 18:25
> To: Doerr, Martin <martin.doerr at sap.com>; Andrew Haley <aph at redhat.com>; David Holmes <david.holmes at oracle.com>; Aleksey Shipilev <shade at redhat.com>; hotspot-dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Subject: Re: RFR 8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism)
>
> Hi Martin,
>
> On 2018-04-24 15:43, Doerr, Martin wrote:
>> Hi Erik,
>>
>> I highly appreciate if we can get the VM code to work correctly with C++ 2011 semantics on PPC64.
>> But I think this needs to be done very carefully in order to avoid missing sync instructions between CAS and Load.
> I was not suggesting removing the more conservative ordering property,
> only allowing using seq_cst, when you know that is the correct semantics.
>
>> E.g. the new global counter implementation uses (after fix):
>> Atomic::add(memory_order_conservative) + OrderAccess::load_acquire
>>
>> In C++2011 this should become:
>> Cmpxchg SeqCst + Load Seq Cst
>>
>> Cmpxchg SeqCst + any other Load would be incorrect on PPC64. So we will need to double-check all corresponding loads.
> This might be getting out of topic, but here goes...
>
> There are both leading sync and trailing sync conventions for
> implementing C++11 seq_cst on PPC. What you are saying is true for the
> leading sync convention, but not for the trailing sync convention. In
> HotSpot, I think it is probably more desirable to bind the expectations
> for *all* seq_cst accesses to have trailing sync convention to avoid
> this issue of seq_cst store followed by load_acquire being reordered. I
> don't think we want a situation where PPC implements leading sync
> (despite being able to choose trailing sync), when AArch64 uses trailing
> sync. But perhaps this is derailing a bit...
>
>> I've seen that you have moved the support_IRIW_for_not_multiple_copy_atomic_cpu fence into RawAccessBarrier<decorators>::load_internal. Ideally, RawAccessBarrier<decorators>::store_internal should use OrderAccess::release_store without fence in case of support_IRIW_for_not_multiple_copy_atomic_cpu, but I'm not requesting to change this now. We'd get this by moving to C++ 2011 semantics (which assumes support_IRIW_for_not_multiple_copy_atomic_cpu), right?
> That code should really call into Atomic/OrderAccess with seq_cst, and
> let the platform layer do what it needs to do.
>
> Thanks,
> /Erik
>
>> Best regards,
>> Martin
>>
>>
>> -----Original Message-----
>> From: Erik ?sterlund [mailto:erik.osterlund at oracle.com]
>> Sent: Montag, 23. April 2018 12:41
>> To: Andrew Haley <aph at redhat.com>; Doerr, Martin <martin.doerr at sap.com>; David Holmes <david.holmes at oracle.com>; Aleksey Shipilev <shade at redhat.com>; hotspot-dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>> Subject: Re: RFR 8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism)
>>
>> Hi Andrew,
>>
>> On 2018-04-23 12:20, Andrew Haley wrote:
>>> On 04/18/2018 05:37 PM, Doerr, Martin wrote:
>>>
>>>> It'd be great if we could specify semantics for Atomic:add like we
>>>> do for Atomic::cmpchgx.
>>>> However, the double-fence is a very bad default from performance
>>>> perspective. I wonder if PPC64 is the only platform which gets hit.
>>> Probably not.
>>>
>>>> Would it be acceptable to set the default to
>>>> memory_order_acquire_release and specify memory_order_conservative
>>>> for the new usage? I think this would fit perfectly for PPC64, but
>>>> some people may not like it. One could say PPC64 is the problem, but
>>>> one could also say the VM code is the problem ??
>>> Indeed. In as much as we use stronger memory ordering than we need in
>>> more than one place, the VM code is the problem.
>>>
>>>> I don't really like the straight forward fix to insert a fence with
>>>> #ifdef AIX.
>>> I agree. It looks to me like it's sufficient if the increment of
>>> global_counter and the load of thread->get_rcu_counter() are
>>> sequentially consistent. On at least one platform, AArch64, we can
>>> do that without additional fencing.
>> I would also like to have seq_cst available. In the Access API, I need
>> MO_SEQ_CST for JMM volatile support. I would like the semantic
>> requirements to go straight into Atomic, instead of doing a "if
>> (support_IRIW_for_not_multiple_copy_atomic_cpu) { OrderAccess::fence();
>> }" dance in shared code, that may or may not make sense at a given
>> platform (among other reasons because it enforces whether leading or
>> trailing sync convention is used in shared code, rather than leave that
>> decision to the platform level). Plus I have a mouse pad that says I
>> love sequential consistency, although that might not be a valid argument
>> to introduce this to Atomic.
>>
>> Thanks,
>> /Erik
From dean.long at oracle.com Tue Apr 24 20:20:59 2018
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Tue, 24 Apr 2018 13:20:59 -0700
Subject: [11] RFR(XS) 8202152:
test/hotspot/jtreg/runtime/whitebox/WBStackSize.java fails
In-Reply-To: <31ee2175-349e-8f0c-4bc7-0bd58faabfe0@oracle.com>
References: <074d0bb7-4d1e-91a2-541f-50ecd9eb4cb6@oracle.com>
<df053f49-ff6a-0c9e-1589-95b6a1dc5abb@oracle.com>
<84dc4c3c-6e00-189d-755a-aa0a257d5f93@oracle.com>
<31ee2175-349e-8f0c-4bc7-0bd58faabfe0@oracle.com>
Message-ID: <8fd9d941-9bf2-5f8d-2df5-c4d73d820c82@oracle.com>
It seems like this could still break if the pthreads implementation
decides to hand out (non-recycled) threads with oversized stacks, or if
there are recycled threads that don't use the values from the
command-line.? What happens if we run lots of tests in samevm mode, and
those tests uses different values for the stack size?? Then wouldn't
pthreads have a cache of various stack sizes to recycle new threads from?
dl
On 4/23/18 11:12 PM, David Holmes wrote:
> On 24/04/2018 3:54 PM, David Holmes wrote:
>> To follow up ... Vladimir and I have had an interesting back and
>> forth in the bug report. It seems that at least in some cases
>> terminated threads are getting recycled - not just their pthread_t
>> identities but the actual allocated stack region as well. We seem to
>> end up with a new regular Java thread acquiring the id and stack of a
>> just terminated compiler thread - hence the regular Java thread gets
>> the wrong size stack!
>>
>> This is quite bizarre and seems quite broken.
>
> No it's not broken. The stacksize attribute is just a minimum size, so
> the OS can reuse a terminated thread with a larger stack - and that's
> what we are seeing.
>
> So the fix is fine, I would just add before @run:
>
> @comment Must use the same stacksize for Java threads and compiler
> threads in case of thread recycling
>
> Or something to that affect.
>
> Thanks,
> David
>
>> David
>>
>> On 24/04/2018 7:24 AM, David Holmes wrote:
>>> Hi Vladimir,
>>>
>>> On 24/04/2018 5:20 AM, Vladimir Kozlov wrote:
>>>> http://cr.openjdk.java.net/~kvn/8202152/webrev.00/
>>>> https://bugs.openjdk.java.net/browse/JDK-8202152
>>>>
>>>> After 8198756 changes compiler threads could be released and other
>>>> Java threads can re-use the same HW threads for which stack size
>>>> was determined during start. The test WBStackSize.java may fail in
>>>> such cases because Java thread stack size is set and checked in test.
>>>
>>> That does not make sense to me. We don't "re-use HW threads" - I'm
>>> not even sure what that means. Compiler threads have a different
>>> stacksize to other Java threads - that seems simple enough.
>>>
>>>> For 8198756 changes we added thread name check to workaround the
>>>> problem [1]. But it seems is not enough.
>>>
>>> Why would this test be run in a compiler thread ????
>>>
>>>> To avoid this issue I added -XX:CompilerThreadStackSize=512 flag to
>>>> match Java thread stack size (note, size is in Kb for this flag).
>>>
>>> That seems like a workaround of the real problem.
>>>
>>> David
>>> -----
>>>
>>>> I also reverted changes in test code and instead added thread name
>>>> print to know in case we still have problem in a future.
>>>>
>>>> Tier1 testing (which run the test) passed.
>>>>
From daniel.smith at oracle.com Tue Apr 24 20:47:20 2018
From: daniel.smith at oracle.com (Dan Smith)
Date: Tue, 24 Apr 2018 14:47:20 -0600
Subject: Call for Speakers -- 2018 JVM Language Summit
Message-ID: <AF8E5930-6CF4-44EB-90AE-BF2BA24A9E80@oracle.com>
CALL FOR SPEAKERS -- JVM LANGUAGE SUMMIT, JULY 30-AUGUST 1, 2018
We are pleased to announce the 2018 JVM Language Summit to be held at Oracle?s Santa Clara campus on July 30-August 1, 2018. Registration is now open for speaker submissions and will remain open through May 25. There is no registration fee for speakers.
The JVM Language Summit is an open technical collaboration among language designers, compiler writers, tool builders, runtime engineers, and VM architects. We will share our experiences as creators of both the JVM and programming languages for the JVM. We also welcome non-JVM developers of similar technologies to attend or speak on their runtime, VM, or language of choice.
Presentations will be recorded and made available to the public.
This event is being organized by language and JVM engineers -- no marketers involved! So bring your slide rules and be prepared for some seriously geeky discussions.
Format
The summit is held in a single classroom-style room to support direct communication between participants. About 100-120 attendees are expected.
The schedule consists of a single track of traditional presentations (about 6 each day) interspersed with less-formal multi-track "workshop" discussion groups (2?4 each day) and, possibly, impromptu "lightning talks."
Workshops are open discussions with only a small amount of prepared material. We ask each registrant to suggest a few topics of interest. After choosing the most popular topics, we'll ask some registrants if they'd like to act as discussion leaders.
Instructions for Speaker Registration
If you?d like give a presentation, please register as "Speaker" or "Speaker (Oracle)" (the latter for Oracle employees) and include a detailed abstract. There is no fee. See below for help preparing your abstract and talk. You will be notified about whether your proposal has been accepted; if not, you will be able to register as a regular attendee.
For a successful speaker submission, please note the following:
- All talks should be deeply technical, given by designers and implementors to designers and implementors. We all speak bytecode here!
- Each talk, we hope and expect, will inform the audience, in detail, about the state of the art of language design or implementation on the JVM, or will explore the present and future capabilities of the JVM itself. (Some will do so indirectly by discussing non-JVM technologies.)
- Know your audience: attendees may not be likely to ever use your specific language or tool, but could learn something from your interactions with the JVM. A broad goal of the summit is to inspire collaboration on JVM-based technologies that enable a rich ecosystem at higher layers.
To register:
register.jvmlangsummit.com
For further information:
jvmlangsummit.com
Questions:
inquire2018 at jvmlangsummit.com
From vladimir.kozlov at oracle.com Tue Apr 24 21:30:43 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 24 Apr 2018 14:30:43 -0700
Subject: [11] RFR(XS) 8202152:
test/hotspot/jtreg/runtime/whitebox/WBStackSize.java fails
In-Reply-To: <8fd9d941-9bf2-5f8d-2df5-c4d73d820c82@oracle.com>
References: <074d0bb7-4d1e-91a2-541f-50ecd9eb4cb6@oracle.com>
<df053f49-ff6a-0c9e-1589-95b6a1dc5abb@oracle.com>
<84dc4c3c-6e00-189d-755a-aa0a257d5f93@oracle.com>
<31ee2175-349e-8f0c-4bc7-0bd58faabfe0@oracle.com>
<8fd9d941-9bf2-5f8d-2df5-c4d73d820c82@oracle.com>
Message-ID: <cb81c197-098f-23a5-efbc-6a6d059d799a@oracle.com>
I don't think pthreads from other tests/apps will have affect.
Stack sizes are set during startup regardless what will be run after
that (one or several tests).
We have only 3 (I think) stack size: VM (vm, gc, watcher - native
threads), compiler, Java threads.
The only concern that GC also now has dynamic threads creation. But I am
not sure they release those threads.
Note, in general it is not a problem to reuse bigger stacks.
The test is too strict assuming a new stack will always be created. That
is a problem and it addressed by the fix.
Thanks,
Vladimir
On 4/24/18 1:20 PM, dean.long at oracle.com wrote:
> It seems like this could still break if the pthreads implementation
> decides to hand out (non-recycled) threads with oversized stacks, or if
> there are recycled threads that don't use the values from the
> command-line.? What happens if we run lots of tests in samevm mode, and
> those tests uses different values for the stack size?? Then wouldn't
> pthreads have a cache of various stack sizes to recycle new threads from?
>
> dl
>
> On 4/23/18 11:12 PM, David Holmes wrote:
>> On 24/04/2018 3:54 PM, David Holmes wrote:
>>> To follow up ... Vladimir and I have had an interesting back and
>>> forth in the bug report. It seems that at least in some cases
>>> terminated threads are getting recycled - not just their pthread_t
>>> identities but the actual allocated stack region as well. We seem to
>>> end up with a new regular Java thread acquiring the id and stack of a
>>> just terminated compiler thread - hence the regular Java thread gets
>>> the wrong size stack!
>>>
>>> This is quite bizarre and seems quite broken.
>>
>> No it's not broken. The stacksize attribute is just a minimum size, so
>> the OS can reuse a terminated thread with a larger stack - and that's
>> what we are seeing.
>>
>> So the fix is fine, I would just add before @run:
>>
>> @comment Must use the same stacksize for Java threads and compiler
>> threads in case of thread recycling
>>
>> Or something to that affect.
>>
>> Thanks,
>> David
>>
>>> David
>>>
>>> On 24/04/2018 7:24 AM, David Holmes wrote:
>>>> Hi Vladimir,
>>>>
>>>> On 24/04/2018 5:20 AM, Vladimir Kozlov wrote:
>>>>> http://cr.openjdk.java.net/~kvn/8202152/webrev.00/
>>>>> https://bugs.openjdk.java.net/browse/JDK-8202152
>>>>>
>>>>> After 8198756 changes compiler threads could be released and other
>>>>> Java threads can re-use the same HW threads for which stack size
>>>>> was determined during start. The test WBStackSize.java may fail in
>>>>> such cases because Java thread stack size is set and checked in test.
>>>>
>>>> That does not make sense to me. We don't "re-use HW threads" - I'm
>>>> not even sure what that means. Compiler threads have a different
>>>> stacksize to other Java threads - that seems simple enough.
>>>>
>>>>> For 8198756 changes we added thread name check to workaround the
>>>>> problem [1]. But it seems is not enough.
>>>>
>>>> Why would this test be run in a compiler thread ????
>>>>
>>>>> To avoid this issue I added -XX:CompilerThreadStackSize=512 flag to
>>>>> match Java thread stack size (note, size is in Kb for this flag).
>>>>
>>>> That seems like a workaround of the real problem.
>>>>
>>>> David
>>>> -----
>>>>
>>>>> I also reverted changes in test code and instead added thread name
>>>>> print to know in case we still have problem in a future.
>>>>>
>>>>> Tier1 testing (which run the test) passed.
>>>>>
>
From martin.doerr at sap.com Tue Apr 24 22:40:08 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 24 Apr 2018 22:40:08 +0000
Subject: RFR 8201799: Build failures after JDK-8195099 (Concurrent
safe-memory-reclamation mechanism)
In-Reply-To: <3ed44888-420e-4a0b-0bc6-184c6ae14287@oracle.com>
References: <150dc231-d81e-58da-fa46-fd2397bb7ca2@redhat.com>
<ee7c6a6c-7697-ca4b-dd3d-484ca24aeabd@oracle.com> <5AD73E53.90904@oracle.com>
<803cb23d4b754d2384d9681950f5297c@sap.com>
<661ce2cc-2ea7-9a99-e646-ac3fd8c3494e@redhat.com>
<5ADDB823.5060002@oracle.com> <8d27cc92babd424e878ca6312000db3d@sap.com>
<0d76e23a-a61a-c77f-a41d-fa6099ecdc51@oracle.com>
<233865c337b14531acd0dd9fceb9c01d@sap.com>
<3ed44888-420e-4a0b-0bc6-184c6ae14287@oracle.com>
Message-ID: <0abf0bb844374207b1539a7d7d8c95c8@sap.com>
Hi Erik,
thanks a lot for your explanations and for digging so much into PPC stuff.
So I think we should continue using memory_order_conservative instead of seq_cst for now.
Or we could introduce seq_cst and implement it like conservative on PPC64 for now.
Best regards,
Martin
-----Original Message-----
From: Erik ?sterlund <erik.osterlund at oracle.com>
Sent: Dienstag, 24. April 2018 22:03
To: Doerr, Martin <martin.doerr at sap.com>; Andrew Haley <aph at redhat.com>; David Holmes <david.holmes at oracle.com>; Aleksey Shipilev <shade at redhat.com>; hotspot-dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Subject: Re: RFR 8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism)
Hi Martin,
On 2018-04-24 19:02, Doerr, Martin wrote:
> Hi Erik,
>
>> I was not suggesting removing the more conservative ordering property,
>> only allowing using seq_cst, when you know that is the correct semantics.
> Ok, thanks for clarifying.
>
>> There are both leading sync and trailing sync conventions for
>> implementing C++11 seq_cst on PPC
> I'm not convinced that this can be freely selected.
> Is there a GCC switch? What about xlC on AIX?
It is not selectable by the compiler, which is why I think we should
generate our own inline assembly where we explicitly choose the
convention as either leading sync or trailing sync, depending on how we
roll (cf. Repairing Sequential Consistency in C/C++11
https://dl.acm.org/citation.cfm?id=3062352 where both leading and
trailing sync bindings for C++11 are provided). Anything else seems
unsafe (to me). When I talk about C++11 semantics, I don't necessarily
mean the chosen implementation by specific compilers. I mean the
semantic properties of seq_cst, acquire, release, acq_rel, consume, etc.
> The trailing sync convention would have a different weakness: Store + Cmpxchg
> The store will have to be SeqCst in order to generate correct code on PPC64.
Sure, if you move the fence from one side to another, but still have one
side lacking a full fence, there will naturally be a possibility of
reordering on the other side. And therefore I am not arguing we
necessarily remove "conservative". Having said that - doesn't this look
like a much less innocent mistake - having some sort of dekker duality
between a relaxed store (?!) and seq_cst cmpxchg/load? I am biased to
think that seems like a much worse and less subtle programmer mistake,
that is easier to understand. We don't even do that on x86 today (we
would use release_store_fence for the store in such a dekker duality),
and it would break more consistently on other platforms too. The
comments in orderAccess.hpp file states: "Use release_store_fence to
update values like the thread state, where we don't want the current
thread to continue until all our prior memory accesses (including the
new thread state) are visible to other threads". Now we can have
opinions about this "visibility" property, but we have arbitrarily tied
it to the stores. Therefore, the fact is that such dekker dualities use
release_store_fence today, and there is no corresponding
fence_load_acquire() operation. Therefore, I think it would seem, in
HotSpot, easier to adopt a trailing sync seq_cst convention, to fit into
existing code conventions. Sorry for derailing further down the rabbit
hole...
> Even if we can select it in C++, it would be unfortunate if it differs from JMM.
> JMM should not be changed for the sake of C++ implementation cleanup.
> We have "JEP 188: Java Memory Model Update" for that.
Sure. The chosen bindings for the JMM would have to comply with that. I
will stop myself from derailing into a conversation about that. :)
> From the other mail:
>> With C++11, you can choose both what memory ordering
>> semantics successful CAS and failing CAS should have
> You're right. We just need to use it correctly.
Indeed. :)
Thanks,
/Erik
> Thanks and best regards,
> Martin
>
>
> -----Original Message-----
> From: Erik ?sterlund [mailto:erik.osterlund at oracle.com]
> Sent: Dienstag, 24. April 2018 18:25
> To: Doerr, Martin <martin.doerr at sap.com>; Andrew Haley <aph at redhat.com>; David Holmes <david.holmes at oracle.com>; Aleksey Shipilev <shade at redhat.com>; hotspot-dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Subject: Re: RFR 8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism)
>
> Hi Martin,
>
> On 2018-04-24 15:43, Doerr, Martin wrote:
>> Hi Erik,
>>
>> I highly appreciate if we can get the VM code to work correctly with C++ 2011 semantics on PPC64.
>> But I think this needs to be done very carefully in order to avoid missing sync instructions between CAS and Load.
> I was not suggesting removing the more conservative ordering property,
> only allowing using seq_cst, when you know that is the correct semantics.
>
>> E.g. the new global counter implementation uses (after fix):
>> Atomic::add(memory_order_conservative) + OrderAccess::load_acquire
>>
>> In C++2011 this should become:
>> Cmpxchg SeqCst + Load Seq Cst
>>
>> Cmpxchg SeqCst + any other Load would be incorrect on PPC64. So we will need to double-check all corresponding loads.
> This might be getting out of topic, but here goes...
>
> There are both leading sync and trailing sync conventions for
> implementing C++11 seq_cst on PPC. What you are saying is true for the
> leading sync convention, but not for the trailing sync convention. In
> HotSpot, I think it is probably more desirable to bind the expectations
> for *all* seq_cst accesses to have trailing sync convention to avoid
> this issue of seq_cst store followed by load_acquire being reordered. I
> don't think we want a situation where PPC implements leading sync
> (despite being able to choose trailing sync), when AArch64 uses trailing
> sync. But perhaps this is derailing a bit...
>
>> I've seen that you have moved the support_IRIW_for_not_multiple_copy_atomic_cpu fence into RawAccessBarrier<decorators>::load_internal. Ideally, RawAccessBarrier<decorators>::store_internal should use OrderAccess::release_store without fence in case of support_IRIW_for_not_multiple_copy_atomic_cpu, but I'm not requesting to change this now. We'd get this by moving to C++ 2011 semantics (which assumes support_IRIW_for_not_multiple_copy_atomic_cpu), right?
> That code should really call into Atomic/OrderAccess with seq_cst, and
> let the platform layer do what it needs to do.
>
> Thanks,
> /Erik
>
>> Best regards,
>> Martin
>>
>>
>> -----Original Message-----
>> From: Erik ?sterlund [mailto:erik.osterlund at oracle.com]
>> Sent: Montag, 23. April 2018 12:41
>> To: Andrew Haley <aph at redhat.com>; Doerr, Martin <martin.doerr at sap.com>; David Holmes <david.holmes at oracle.com>; Aleksey Shipilev <shade at redhat.com>; hotspot-dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>> Subject: Re: RFR 8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism)
>>
>> Hi Andrew,
>>
>> On 2018-04-23 12:20, Andrew Haley wrote:
>>> On 04/18/2018 05:37 PM, Doerr, Martin wrote:
>>>
>>>> It'd be great if we could specify semantics for Atomic:add like we
>>>> do for Atomic::cmpchgx.
>>>> However, the double-fence is a very bad default from performance
>>>> perspective. I wonder if PPC64 is the only platform which gets hit.
>>> Probably not.
>>>
>>>> Would it be acceptable to set the default to
>>>> memory_order_acquire_release and specify memory_order_conservative
>>>> for the new usage? I think this would fit perfectly for PPC64, but
>>>> some people may not like it. One could say PPC64 is the problem, but
>>>> one could also say the VM code is the problem ??
>>> Indeed. In as much as we use stronger memory ordering than we need in
>>> more than one place, the VM code is the problem.
>>>
>>>> I don't really like the straight forward fix to insert a fence with
>>>> #ifdef AIX.
>>> I agree. It looks to me like it's sufficient if the increment of
>>> global_counter and the load of thread->get_rcu_counter() are
>>> sequentially consistent. On at least one platform, AArch64, we can
>>> do that without additional fencing.
>> I would also like to have seq_cst available. In the Access API, I need
>> MO_SEQ_CST for JMM volatile support. I would like the semantic
>> requirements to go straight into Atomic, instead of doing a "if
>> (support_IRIW_for_not_multiple_copy_atomic_cpu) { OrderAccess::fence();
>> }" dance in shared code, that may or may not make sense at a given
>> platform (among other reasons because it enforces whether leading or
>> trailing sync convention is used in shared code, rather than leave that
>> decision to the platform level). Plus I have a mouse pad that says I
>> love sequential consistency, although that might not be a valid argument
>> to introduce this to Atomic.
>>
>> Thanks,
>> /Erik
From kim.barrett at oracle.com Wed Apr 25 02:23:38 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 24 Apr 2018 22:23:38 -0400
Subject: RFR: 8202082: Remove explicit CMS checks in
CardTableBarrierSetAssembler
In-Reply-To: <9c283f66-326a-d640-432d-b6c573802b5e@oracle.com>
References: <5AD9FC94.70607@oracle.com>
<6A476A6A-47BB-4141-980E-DB98D9BAD405@oracle.com>
<67ac1742-640e-f011-f371-cf53b782e969@oracle.com>
<60EA410E-E1FE-4A54-95CA-E3F11CC9B168@oracle.com>
<9c283f66-326a-d640-432d-b6c573802b5e@oracle.com>
Message-ID: <1964D307-E283-47CA-96C6-7AF577F96EC4@oracle.com>
> On Apr 24, 2018, at 3:17 PM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>
> Hi Kim,
>
> On 2018-04-24 20:23, Kim Barrett wrote:
>>> On Apr 24, 2018, at 2:57 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>>>
>>> Hi Kim,
>>>
>>> On 2018-04-24 04:15, Kim Barrett wrote:
>>>>> On Apr 20, 2018, at 10:43 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> In CardTableBarrierSetAssembler, we sometimes need fencing due to the card table being scanned concurrently when using CMS with pre-cleaning. Rather than explicitly checking for those CMS flags in the generic CardTableBarrierSetAssembler class, it is preferrable to check the CardTable scanned_concurrently() property which already precisely reflects that.
>>>>>
>>>>> Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8202082
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.00/
>>>>>
>>>>> Thanks,
>>>>> /Erik
>>>> ------------------------------------------------------------------------------
>>>> src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
>>>> 121 if (ct->scanned_concurrently()) {
>>>>
>>>> I think the correct test here is card_mark_must_follow_store. See
>>>> my review of 8202083 for more details.
>>>>
>>>> Similarly for the other platforms.
>>> I disagree. Let me explain why, and where I am trying to get with this.
>>>
>>> We used to have a whole bunch of different ways of making decisions based on whether the card table is scanned concurrently or not, queried in various ways, depending on whether we were talking to the CollectedHeap interface, the CardTableModRefBS interface, or whether we were inside of the CardTableModRefBS class. I am trying to remove those one by one, until only one is left, the configuration point in CardTable which describes precisely that: that the card table is scanned concurrently. Here are a few examples:
>>>
>>> * The ReduceInitialCardMarks optimization either defers card marks or issues them immediately on slowpath allocations, depending on whether the card table is scanned concurrently or not (this used to ask CollectedHeap about these queries).
>>> * Inside of the post barriers, StoreStore fencing between the reference store and card mark depends on whether the card table is scanned concurrently or not. (checked with explicit CMS + precleaning and sometimes conservatively just CMS checks)
>>> * When using UseCondCardMark, there is a StoreLoad fence to make sure the store of the reference happens-before the *load* of the card value (not the store of the card value) for filtering. Again, this is only an issue when the card table is scanned concurrently, and not very well described by whether the card mark must follow the store IMO.
>>>
>>> The reason there is not yet a single property is that some code has previously asked CollectedHeap about these questions from outside of GC code (ReduceInitialCardMarks), while other code lived in the card table barrier set (CMS + pre-cleaning checks). Where I want to go is that no code outside of the CardTableBarrierSet classes should need to ask these questions. And code inside of the CardTableBarrierSet classes should ask its CardTable, which acts as a configuration, whether it is scanned concurrently or not.
>>>
>>> So basically, I would prefer to now remove the card_mark_must_follow_store() method, and replace it with direct calls to whether the card table is scanned concurrently.
>>>
>>> Do you agree?
>> I agree that fewer sources for what is effectively the same
>> information would be good. I just don't think CardTable is the right
>> place for this piece of information. CardTable is (largely) a
>> "simple" data structure (*), and doesn't care whether it's scanned
>> concurrently or not. I think it belongs in the CTBS.
>
> Whether the CardTable is scanned concurrently or not is the property we are consistently interested in. That is a natural property of the CardTable to me, and hence belongs in the CardTable. I don't see a convincing argument why it would not be a natural property of the CardTable. Conversely, I find that it would mess up GenCollectedHeap if it was not. Currently, the GenCollectedHeaps unconditionally instantiates a CardTableBarrierSet, with a single configuration parameter: the CardTable, which is created with a virtual call as either CardTableRS or CMSCardTable. With your proposal to move the property of whether the CardTable is scanned concurrently or not, out from the CardTable, that would inevitably result in more virtual calls only for configuring the CardTableBarrierSet with this property, or make the CardTableBarrierSet itself into a configuration (created with virtual calls). That does not look like a win to me. Do you agree?
>
>> (*) I think CardTable could be simpler. It presently contains a fair
>> amount of stuff that seems only needed by CMS or only needed by G1,
>> and should perhaps be placed elsewhere.
>
> Sure. Those things should be moved into CMSCardTable and G1CardTable respectively.
Or stated differently:
Whether the collector scans the card table concurrently or not is the
property we are consistently interested in. That is a natural
property of the collector to me...
I see the card table as data, that can/should be largely independent
of the collector / barrier set. The collector / barrier set operate on
that data, and different collectors operate on it in different ways.
It's the collector / barrier set that determines the policies and
behaviors. In particular, there's no intrinsic reason for the card
table to have any knowledge at all about whether it is scanned
concurrently or not.
I'm also doubtful about the hierarchy based on CardTable, though I
understand how we got to where we are; I once took a stab at
extracting the card table stuff from the barrier set stuff, and all I
got was a mess. You did better, but it's still pretty messy and could
use more work.
That said, an argument that the messiness that we presently have makes
the card table an easier place to put this bit of information does
carry weight. So okay, I guess.
>>>> src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
>>>> 113 AddressLiteral cardtable((address)ctbs->card_table()->byte_map_base(), relocInfo::none);
>>
>> Why not
>>
>> intptr_t disp = (intptr_t) ct->byte_map_base();
>> ...
>> AddressLiteral cardtable((address)disp, relocInfo::none);
>>
>> That would have saved me some staring at these expressions to figure
>> out that there weren't any differences.
>
> Okay. I will fix it then.
Thanks.
From dean.long at oracle.com Wed Apr 25 03:34:11 2018
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Tue, 24 Apr 2018 20:34:11 -0700
Subject: [11] RFR(XS) 8202152:
test/hotspot/jtreg/runtime/whitebox/WBStackSize.java fails
In-Reply-To: <cb81c197-098f-23a5-efbc-6a6d059d799a@oracle.com>
References: <074d0bb7-4d1e-91a2-541f-50ecd9eb4cb6@oracle.com>
<df053f49-ff6a-0c9e-1589-95b6a1dc5abb@oracle.com>
<84dc4c3c-6e00-189d-755a-aa0a257d5f93@oracle.com>
<31ee2175-349e-8f0c-4bc7-0bd58faabfe0@oracle.com>
<8fd9d941-9bf2-5f8d-2df5-c4d73d820c82@oracle.com>
<cb81c197-098f-23a5-efbc-6a6d059d799a@oracle.com>
Message-ID: <fcb1d9a7-c083-bc10-8824-99260b4d65f3@oracle.com>
OK.? I guess another fix would be to have the test ignore
actualStackSize > configStackSize.
dl
On 4/24/18 2:30 PM, Vladimir Kozlov wrote:
> I don't think pthreads from other tests/apps will have affect.
> Stack sizes are set during startup regardless what will be run after
> that (one or several tests).
>
> We have only 3 (I think) stack size: VM (vm, gc, watcher - native
> threads), compiler, Java threads.
>
> The only concern that GC also now has dynamic threads creation. But I
> am not sure they release those threads.
>
> Note, in general it is not a problem to reuse bigger stacks.
> The test is too strict assuming a new stack will always be created.
> That is a problem and it addressed by the fix.
>
> Thanks,
> Vladimir
>
> On 4/24/18 1:20 PM, dean.long at oracle.com wrote:
>> It seems like this could still break if the pthreads implementation
>> decides to hand out (non-recycled) threads with oversized stacks, or
>> if there are recycled threads that don't use the values from the
>> command-line.? What happens if we run lots of tests in samevm mode,
>> and those tests uses different values for the stack size?? Then
>> wouldn't pthreads have a cache of various stack sizes to recycle new
>> threads from?
>>
>> dl
>>
>> On 4/23/18 11:12 PM, David Holmes wrote:
>>> On 24/04/2018 3:54 PM, David Holmes wrote:
>>>> To follow up ... Vladimir and I have had an interesting back and
>>>> forth in the bug report. It seems that at least in some cases
>>>> terminated threads are getting recycled - not just their pthread_t
>>>> identities but the actual allocated stack region as well. We seem
>>>> to end up with a new regular Java thread acquiring the id and stack
>>>> of a just terminated compiler thread - hence the regular Java
>>>> thread gets the wrong size stack!
>>>>
>>>> This is quite bizarre and seems quite broken.
>>>
>>> No it's not broken. The stacksize attribute is just a minimum size,
>>> so the OS can reuse a terminated thread with a larger stack - and
>>> that's what we are seeing.
>>>
>>> So the fix is fine, I would just add before @run:
>>>
>>> @comment Must use the same stacksize for Java threads and compiler
>>> threads in case of thread recycling
>>>
>>> Or something to that affect.
>>>
>>> Thanks,
>>> David
>>>
>>>> David
>>>>
>>>> On 24/04/2018 7:24 AM, David Holmes wrote:
>>>>> Hi Vladimir,
>>>>>
>>>>> On 24/04/2018 5:20 AM, Vladimir Kozlov wrote:
>>>>>> http://cr.openjdk.java.net/~kvn/8202152/webrev.00/
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202152
>>>>>>
>>>>>> After 8198756 changes compiler threads could be released and
>>>>>> other Java threads can re-use the same HW threads for which stack
>>>>>> size was determined during start. The test WBStackSize.java may
>>>>>> fail in such cases because Java thread stack size is set and
>>>>>> checked in test.
>>>>>
>>>>> That does not make sense to me. We don't "re-use HW threads" - I'm
>>>>> not even sure what that means. Compiler threads have a different
>>>>> stacksize to other Java threads - that seems simple enough.
>>>>>
>>>>>> For 8198756 changes we added thread name check to workaround the
>>>>>> problem [1]. But it seems is not enough.
>>>>>
>>>>> Why would this test be run in a compiler thread ????
>>>>>
>>>>>> To avoid this issue I added -XX:CompilerThreadStackSize=512 flag
>>>>>> to match Java thread stack size (note, size is in Kb for this flag).
>>>>>
>>>>> That seems like a workaround of the real problem.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>> I also reverted changes in test code and instead added thread
>>>>>> name print to know in case we still have problem in a future.
>>>>>>
>>>>>> Tier1 testing (which run the test) passed.
>>>>>>
>>
From erik.osterlund at oracle.com Wed Apr 25 05:18:17 2018
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Wed, 25 Apr 2018 07:18:17 +0200
Subject: RFR 8201799: Build failures after JDK-8195099 (Concurrent
safe-memory-reclamation mechanism)
In-Reply-To: <0abf0bb844374207b1539a7d7d8c95c8@sap.com>
References: <150dc231-d81e-58da-fa46-fd2397bb7ca2@redhat.com>
<ee7c6a6c-7697-ca4b-dd3d-484ca24aeabd@oracle.com> <5AD73E53.90904@oracle.com>
<803cb23d4b754d2384d9681950f5297c@sap.com>
<661ce2cc-2ea7-9a99-e646-ac3fd8c3494e@redhat.com>
<5ADDB823.5060002@oracle.com> <8d27cc92babd424e878ca6312000db3d@sap.com>
<0d76e23a-a61a-c77f-a41d-fa6099ecdc51@oracle.com>
<233865c337b14531acd0dd9fceb9c01d@sap.com>
<3ed44888-420e-4a0b-0bc6-184c6ae14287@oracle.com>
<0abf0bb844374207b1539a7d7d8c95c8@sap.com>
Message-ID: <02C4ABCA-DB99-4F00-B750-F73D22915A8C@oracle.com>
Hi Martin,
> On 25 Apr 2018, at 00:40, Doerr, Martin <martin.doerr at sap.com> wrote:
>
> Hi Erik,
>
> thanks a lot for your explanations and for digging so much into PPC stuff.
>
> So I think we should continue using memory_order_conservative instead of seq_cst for now.
> Or we could introduce seq_cst and implement it like conservative on PPC64 for now.
Agreed. I?d say probably keep conservative for now, and take one step at a time. We can introduce seq_cst another day.
Thanks,
/Erik
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: Erik ?sterlund <erik.osterlund at oracle.com>
> Sent: Dienstag, 24. April 2018 22:03
> To: Doerr, Martin <martin.doerr at sap.com>; Andrew Haley <aph at redhat.com>; David Holmes <david.holmes at oracle.com>; Aleksey Shipilev <shade at redhat.com>; hotspot-dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Subject: Re: RFR 8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism)
>
> Hi Martin,
>
>> On 2018-04-24 19:02, Doerr, Martin wrote:
>> Hi Erik,
>>
>>> I was not suggesting removing the more conservative ordering property,
>>> only allowing using seq_cst, when you know that is the correct semantics.
>> Ok, thanks for clarifying.
>>
>>> There are both leading sync and trailing sync conventions for
>>> implementing C++11 seq_cst on PPC
>> I'm not convinced that this can be freely selected.
>> Is there a GCC switch? What about xlC on AIX?
>
> It is not selectable by the compiler, which is why I think we should
> generate our own inline assembly where we explicitly choose the
> convention as either leading sync or trailing sync, depending on how we
> roll (cf. Repairing Sequential Consistency in C/C++11
> https://dl.acm.org/citation.cfm?id=3062352 where both leading and
> trailing sync bindings for C++11 are provided). Anything else seems
> unsafe (to me). When I talk about C++11 semantics, I don't necessarily
> mean the chosen implementation by specific compilers. I mean the
> semantic properties of seq_cst, acquire, release, acq_rel, consume, etc.
>
>> The trailing sync convention would have a different weakness: Store + Cmpxchg
>> The store will have to be SeqCst in order to generate correct code on PPC64.
>
> Sure, if you move the fence from one side to another, but still have one
> side lacking a full fence, there will naturally be a possibility of
> reordering on the other side. And therefore I am not arguing we
> necessarily remove "conservative". Having said that - doesn't this look
> like a much less innocent mistake - having some sort of dekker duality
> between a relaxed store (?!) and seq_cst cmpxchg/load? I am biased to
> think that seems like a much worse and less subtle programmer mistake,
> that is easier to understand. We don't even do that on x86 today (we
> would use release_store_fence for the store in such a dekker duality),
> and it would break more consistently on other platforms too. The
> comments in orderAccess.hpp file states: "Use release_store_fence to
> update values like the thread state, where we don't want the current
> thread to continue until all our prior memory accesses (including the
> new thread state) are visible to other threads". Now we can have
> opinions about this "visibility" property, but we have arbitrarily tied
> it to the stores. Therefore, the fact is that such dekker dualities use
> release_store_fence today, and there is no corresponding
> fence_load_acquire() operation. Therefore, I think it would seem, in
> HotSpot, easier to adopt a trailing sync seq_cst convention, to fit into
> existing code conventions. Sorry for derailing further down the rabbit
> hole...
>
>> Even if we can select it in C++, it would be unfortunate if it differs from JMM.
>> JMM should not be changed for the sake of C++ implementation cleanup.
>> We have "JEP 188: Java Memory Model Update" for that.
>
> Sure. The chosen bindings for the JMM would have to comply with that. I
> will stop myself from derailing into a conversation about that. :)
>
>> From the other mail:
>>> With C++11, you can choose both what memory ordering
>>> semantics successful CAS and failing CAS should have
>> You're right. We just need to use it correctly.
>
> Indeed. :)
>
> Thanks,
> /Erik
>
>> Thanks and best regards,
>> Martin
>>
>>
>> -----Original Message-----
>> From: Erik ?sterlund [mailto:erik.osterlund at oracle.com]
>> Sent: Dienstag, 24. April 2018 18:25
>> To: Doerr, Martin <martin.doerr at sap.com>; Andrew Haley <aph at redhat.com>; David Holmes <david.holmes at oracle.com>; Aleksey Shipilev <shade at redhat.com>; hotspot-dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>> Subject: Re: RFR 8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism)
>>
>> Hi Martin,
>>
>>> On 2018-04-24 15:43, Doerr, Martin wrote:
>>> Hi Erik,
>>>
>>> I highly appreciate if we can get the VM code to work correctly with C++ 2011 semantics on PPC64.
>>> But I think this needs to be done very carefully in order to avoid missing sync instructions between CAS and Load.
>> I was not suggesting removing the more conservative ordering property,
>> only allowing using seq_cst, when you know that is the correct semantics.
>>
>>> E.g. the new global counter implementation uses (after fix):
>>> Atomic::add(memory_order_conservative) + OrderAccess::load_acquire
>>>
>>> In C++2011 this should become:
>>> Cmpxchg SeqCst + Load Seq Cst
>>>
>>> Cmpxchg SeqCst + any other Load would be incorrect on PPC64. So we will need to double-check all corresponding loads.
>> This might be getting out of topic, but here goes...
>>
>> There are both leading sync and trailing sync conventions for
>> implementing C++11 seq_cst on PPC. What you are saying is true for the
>> leading sync convention, but not for the trailing sync convention. In
>> HotSpot, I think it is probably more desirable to bind the expectations
>> for *all* seq_cst accesses to have trailing sync convention to avoid
>> this issue of seq_cst store followed by load_acquire being reordered. I
>> don't think we want a situation where PPC implements leading sync
>> (despite being able to choose trailing sync), when AArch64 uses trailing
>> sync. But perhaps this is derailing a bit...
>>
>>> I've seen that you have moved the support_IRIW_for_not_multiple_copy_atomic_cpu fence into RawAccessBarrier<decorators>::load_internal. Ideally, RawAccessBarrier<decorators>::store_internal should use OrderAccess::release_store without fence in case of support_IRIW_for_not_multiple_copy_atomic_cpu, but I'm not requesting to change this now. We'd get this by moving to C++ 2011 semantics (which assumes support_IRIW_for_not_multiple_copy_atomic_cpu), right?
>> That code should really call into Atomic/OrderAccess with seq_cst, and
>> let the platform layer do what it needs to do.
>>
>> Thanks,
>> /Erik
>>
>>> Best regards,
>>> Martin
>>>
>>>
>>> -----Original Message-----
>>> From: Erik ?sterlund [mailto:erik.osterlund at oracle.com]
>>> Sent: Montag, 23. April 2018 12:41
>>> To: Andrew Haley <aph at redhat.com>; Doerr, Martin <martin.doerr at sap.com>; David Holmes <david.holmes at oracle.com>; Aleksey Shipilev <shade at redhat.com>; hotspot-dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>> Subject: Re: RFR 8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism)
>>>
>>> Hi Andrew,
>>>
>>>> On 2018-04-23 12:20, Andrew Haley wrote:
>>>>> On 04/18/2018 05:37 PM, Doerr, Martin wrote:
>>>>>
>>>>> It'd be great if we could specify semantics for Atomic:add like we
>>>>> do for Atomic::cmpchgx.
>>>>> However, the double-fence is a very bad default from performance
>>>>> perspective. I wonder if PPC64 is the only platform which gets hit.
>>>> Probably not.
>>>>
>>>>> Would it be acceptable to set the default to
>>>>> memory_order_acquire_release and specify memory_order_conservative
>>>>> for the new usage? I think this would fit perfectly for PPC64, but
>>>>> some people may not like it. One could say PPC64 is the problem, but
>>>>> one could also say the VM code is the problem ??
>>>> Indeed. In as much as we use stronger memory ordering than we need in
>>>> more than one place, the VM code is the problem.
>>>>
>>>>> I don't really like the straight forward fix to insert a fence with
>>>>> #ifdef AIX.
>>>> I agree. It looks to me like it's sufficient if the increment of
>>>> global_counter and the load of thread->get_rcu_counter() are
>>>> sequentially consistent. On at least one platform, AArch64, we can
>>>> do that without additional fencing.
>>> I would also like to have seq_cst available. In the Access API, I need
>>> MO_SEQ_CST for JMM volatile support. I would like the semantic
>>> requirements to go straight into Atomic, instead of doing a "if
>>> (support_IRIW_for_not_multiple_copy_atomic_cpu) { OrderAccess::fence();
>>> }" dance in shared code, that may or may not make sense at a given
>>> platform (among other reasons because it enforces whether leading or
>>> trailing sync convention is used in shared code, rather than leave that
>>> decision to the platform level). Plus I have a mouse pad that says I
>>> love sequential consistency, although that might not be a valid argument
>>> to introduce this to Atomic.
>>>
>>> Thanks,
>>> /Erik
>
From Ningsheng.Jian at arm.com Wed Apr 25 05:48:07 2018
From: Ningsheng.Jian at arm.com (Ningsheng Jian)
Date: Wed, 25 Apr 2018 05:48:07 +0000
Subject: 8185505: AArch64: Port AOT
In-Reply-To: <42c8b22b-a96d-a598-6ded-96bef4835a21@redhat.com>
References: <b439eaf0-e026-7ff8-e832-3717368027e4@redhat.com>
<AM5PR0802MB2449400467C4E4042C3C6A6390B00@AM5PR0802MB2449.eurprd08.prod.outlook.com>
<57767253-4826-e5b4-d142-7990d7114704@redhat.com>
<4626be6e-7927-a8ad-dead-1c3a4fca3ec9@oracle.com>
<5147cd22-8c3c-d72f-bf5d-0ef384eac45c@oracle.com>
<VI1PR0802MB2445EFDDB61AD73E87B99AC08E890@VI1PR0802MB2445.eurprd08.prod.outlook.com>
<a7cdcca0-d2e4-7285-51f4-d12420dd0d0e@redhat.com>
<AM5PR0802MB244964AA47218120992920A090880@AM5PR0802MB2449.eurprd08.prod.outlook.com>
<42c8b22b-a96d-a598-6ded-96bef4835a21@redhat.com>
Message-ID: <AM5PR0802MB24499A4225EBEBDDAF16F884908F0@AM5PR0802MB2449.eurprd08.prod.outlook.com>
> -----Original Message-----
> From: Andrew Haley <aph at redhat.com>
> Sent: Tuesday, April 24, 2018 9:27 PM
> To: Ningsheng Jian <Ningsheng.Jian at arm.com>; Yang Zhang
> <Yang.Zhang at arm.com>; Vladimir Kozlov <vladimir.kozlov at oracle.com>;
> hotspot-dev at openjdk.java.net
> Cc: nd <nd at arm.com>
> Subject: Re: 8185505: AArch64: Port AOT
>
> On 04/24/2018 06:45 AM, Ningsheng Jian wrote:
>
> > Specifically for the link error Yang met, since the stub code (not the
> > GOT cases) and the call site are both in .text section, I think it
> > might be helpful to issue warning/error when generating the relocation
> > entry (before the long time linking phase).
>
> We don't know that the overflow will happen until ink time.
>
I think we know the overflow for Stub<* functions, since they are local binding symbols and in .text section - the offset to the callsite is known.
Maybe we can put those compiled functions in different sections in .o file, other than all in the same .text section, and let linker to handle the overflow by itself. IIRC, ld will insert veneer code automatically for those out-of-range calls. But if all the code is already in one section, ld could not do that.
Thanks,
Ningsheng
From aph at redhat.com Wed Apr 25 07:30:52 2018
From: aph at redhat.com (Andrew Haley)
Date: Wed, 25 Apr 2018 08:30:52 +0100
Subject: 8185505: AArch64: Port AOT
In-Reply-To: <AM5PR0802MB24499A4225EBEBDDAF16F884908F0@AM5PR0802MB2449.eurprd08.prod.outlook.com>
References: <b439eaf0-e026-7ff8-e832-3717368027e4@redhat.com>
<AM5PR0802MB2449400467C4E4042C3C6A6390B00@AM5PR0802MB2449.eurprd08.prod.outlook.com>
<57767253-4826-e5b4-d142-7990d7114704@redhat.com>
<4626be6e-7927-a8ad-dead-1c3a4fca3ec9@oracle.com>
<5147cd22-8c3c-d72f-bf5d-0ef384eac45c@oracle.com>
<VI1PR0802MB2445EFDDB61AD73E87B99AC08E890@VI1PR0802MB2445.eurprd08.prod.outlook.com>
<a7cdcca0-d2e4-7285-51f4-d12420dd0d0e@redhat.com>
<AM5PR0802MB244964AA47218120992920A090880@AM5PR0802MB2449.eurprd08.prod.outlook.com>
<42c8b22b-a96d-a598-6ded-96bef4835a21@redhat.com>
<AM5PR0802MB24499A4225EBEBDDAF16F884908F0@AM5PR0802MB2449.eurprd08.prod.outlook.com>
Message-ID: <c6d83ef7-9004-175c-96c1-9f9bd8a689c7@redhat.com>
On 04/25/2018 06:48 AM, Ningsheng Jian wrote:
> Maybe we can put those compiled functions in different sections in
> .o file, other than all in the same .text section, and let linker to
> handle the overflow by itself. IIRC, ld will insert veneer code
> automatically for those out-of-range calls.
That's what I was referring to.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From aph at redhat.com Wed Apr 25 07:55:58 2018
From: aph at redhat.com (Andrew Haley)
Date: Wed, 25 Apr 2018 08:55:58 +0100
Subject: 8185505: AArch64: Port AOT
In-Reply-To: <AM5PR0802MB24499A4225EBEBDDAF16F884908F0@AM5PR0802MB2449.eurprd08.prod.outlook.com>
References: <b439eaf0-e026-7ff8-e832-3717368027e4@redhat.com>
<AM5PR0802MB2449400467C4E4042C3C6A6390B00@AM5PR0802MB2449.eurprd08.prod.outlook.com>
<57767253-4826-e5b4-d142-7990d7114704@redhat.com>
<4626be6e-7927-a8ad-dead-1c3a4fca3ec9@oracle.com>
<5147cd22-8c3c-d72f-bf5d-0ef384eac45c@oracle.com>
<VI1PR0802MB2445EFDDB61AD73E87B99AC08E890@VI1PR0802MB2445.eurprd08.prod.outlook.com>
<a7cdcca0-d2e4-7285-51f4-d12420dd0d0e@redhat.com>
<AM5PR0802MB244964AA47218120992920A090880@AM5PR0802MB2449.eurprd08.prod.outlook.com>
<42c8b22b-a96d-a598-6ded-96bef4835a21@redhat.com>
<AM5PR0802MB24499A4225EBEBDDAF16F884908F0@AM5PR0802MB2449.eurprd08.prod.outlook.com>
Message-ID: <94a02af9-e832-9c1a-0f1c-80afc74f53c2@redhat.com>
On 04/25/2018 06:48 AM, Ningsheng Jian wrote:
> I think we know the overflow for Stub<* functions, since they are local binding symbols and in .text section - the offset to the callsite is known.
Sure, but by them we've done all of the work. E don't know how big the
test section is going to be until we've generated all that code.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From mvala at redhat.com Wed Apr 25 10:33:05 2018
From: mvala at redhat.com (Michal Vala)
Date: Wed, 25 Apr 2018 12:33:05 +0200
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
readdir_r(DIR*, dirent*, dirent**)' is deprecated
In-Reply-To: <D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
<D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
Message-ID: <826e8757-2975-04f9-b5d6-d5e174ffede6@redhat.com>
On 04/24/2018 09:17 PM, Kim Barrett wrote:
>> On Apr 23, 2018, at 3:51 AM, Michal Vala <mvala at redhat.com> wrote:
>>
>> Hi,
>>
>> following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm posting updated patch replacing deprecated readdir_r with readdir. Bug ID is JDK-8179887 [2].
>>
>> webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
>>
>> I'm asking for the review and eventually sponsorship.
>
> The change to os::readdir in os_linux.inline.hpp looks fine.
>
> I was going to suggest that rather than changing perfMemory_linux.cpp to use os::readdir in an
> unusual and platform-specific way, it should instead just call ::readdir directly. However, neither
> of those is right, and that part of the change should not be made; see
> https://bugs.openjdk.java.net/browse/JDK-8134540
> Much nearly duplicated code for PerfMemory support
>
> Looking a bit deeper, there might be some additional follow-on that could be done, eliminating
> the second argument to os::readdir.
That's what was I first doing. However, I have no resources to test all OSes.
I understand that this solution is not clear. However, until we remove the
second argument and eventually merge PerfMemory code, it's useless to passing it
on linux. That's why I did that cleanup. It can be done for all OSes under
another bug id though.
> windows: unused
> bsd: freebsd also deprecated readdir_r, I think for similar reasons.
> solaris: doc is clear about thread safety issue being about sharing the DIR*
> aix: I haven?t looked at it, but would guess it?s similar.
>
> In other words, don?t operate on the DIR* from multiple threads simultaneously, and just use
> ::readdir on non-Windows. That would all be for another RFE though.
>
>
--
Michal Vala
OpenJDK QE
Red Hat Czech
From shade at redhat.com Wed Apr 25 10:34:22 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 25 Apr 2018 12:34:22 +0200
Subject: RFR [8u] 8165489 (S): Missing G1 barrier in Unsafe_GetObjectVolatile
Message-ID: <19ca5b19-d458-b37f-1a7c-7404a027306a@redhat.com>
(trying again on hotspot-dev@)
Hi,
Please review this this backport/fix for 8u. This improves G1 stability in 8u, and provides the base
for Shenandoah JDK 8 backport that piggybacks on G1 pre-barriers. The fix does not apply cleanly,
because there is also Unsafe_GetObject140 that needs fixing too.
JDK 9 bug:
https://bugs.openjdk.java.net/browse/JDK-8165489
JDK 9 fix:
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a696583f5ddb
JDK 8u fix:
http://cr.openjdk.java.net/~shade/8165489-8u/webrev.01/
Testing: x86_64 build, Shenandoah tests
Thanks,
-Aleksey
From erik.gahlin at oracle.com Wed Apr 25 11:06:23 2018
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Wed, 25 Apr 2018 13:06:23 +0200
Subject: RFR(XL): 8199712: Flight Recorder
Message-ID: <5AE0612F.8060200@oracle.com>
Greetings,
Could I have a review of 8199712: Flight Recorder
As mentioned in the preview [1] the tracing backend has been removed.
Event metadata has been consolidated into a single XML file and event
classes are now generated by GenerateJfrFiles.java.
Tests have been run on Linux-x64, Windows-x64 and MaxOSX-x64.
For details about the feature, see the JEP:
https://bugs.openjdk.java.net/browse/JDK-8193393
Webrev:
http://cr.openjdk.java.net/~egahlin/8199712.0/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8199712
[1]
http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031359.html
Thanks
Erik and Markus
From david.holmes at oracle.com Wed Apr 25 11:54:23 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 25 Apr 2018 21:54:23 +1000
Subject: [11] RFR(XS) 8202152:
test/hotspot/jtreg/runtime/whitebox/WBStackSize.java fails
In-Reply-To: <fcb1d9a7-c083-bc10-8824-99260b4d65f3@oracle.com>
References: <074d0bb7-4d1e-91a2-541f-50ecd9eb4cb6@oracle.com>
<df053f49-ff6a-0c9e-1589-95b6a1dc5abb@oracle.com>
<84dc4c3c-6e00-189d-755a-aa0a257d5f93@oracle.com>
<31ee2175-349e-8f0c-4bc7-0bd58faabfe0@oracle.com>
<8fd9d941-9bf2-5f8d-2df5-c4d73d820c82@oracle.com>
<cb81c197-098f-23a5-efbc-6a6d059d799a@oracle.com>
<fcb1d9a7-c083-bc10-8824-99260b4d65f3@oracle.com>
Message-ID: <45c2f50f-13f6-9381-54b7-7a4575eacba6@oracle.com>
On 25/04/2018 1:34 PM, dean.long at oracle.com wrote:
> OK.? I guess another fix would be to have the test ignore
> actualStackSize > configStackSize.
Yes - given the requested stacksizes are only minimums the test is
expecting too much.
But as the test is run in othervm mode we don't have to worry about
recycling a thread that may have had an explicit stack size set (via
java.lang.Thread constructor) - at least not until some other part of
the runtime innocently introduces one ...
David
> dl
>
> On 4/24/18 2:30 PM, Vladimir Kozlov wrote:
>> I don't think pthreads from other tests/apps will have affect.
>> Stack sizes are set during startup regardless what will be run after
>> that (one or several tests).
>>
>> We have only 3 (I think) stack size: VM (vm, gc, watcher - native
>> threads), compiler, Java threads.
>>
>> The only concern that GC also now has dynamic threads creation. But I
>> am not sure they release those threads.
>>
>> Note, in general it is not a problem to reuse bigger stacks.
>> The test is too strict assuming a new stack will always be created.
>> That is a problem and it addressed by the fix.
>>
>> Thanks,
>> Vladimir
>>
>> On 4/24/18 1:20 PM, dean.long at oracle.com wrote:
>>> It seems like this could still break if the pthreads implementation
>>> decides to hand out (non-recycled) threads with oversized stacks, or
>>> if there are recycled threads that don't use the values from the
>>> command-line.? What happens if we run lots of tests in samevm mode,
>>> and those tests uses different values for the stack size?? Then
>>> wouldn't pthreads have a cache of various stack sizes to recycle new
>>> threads from?
>>>
>>> dl
>>>
>>> On 4/23/18 11:12 PM, David Holmes wrote:
>>>> On 24/04/2018 3:54 PM, David Holmes wrote:
>>>>> To follow up ... Vladimir and I have had an interesting back and
>>>>> forth in the bug report. It seems that at least in some cases
>>>>> terminated threads are getting recycled - not just their pthread_t
>>>>> identities but the actual allocated stack region as well. We seem
>>>>> to end up with a new regular Java thread acquiring the id and stack
>>>>> of a just terminated compiler thread - hence the regular Java
>>>>> thread gets the wrong size stack!
>>>>>
>>>>> This is quite bizarre and seems quite broken.
>>>>
>>>> No it's not broken. The stacksize attribute is just a minimum size,
>>>> so the OS can reuse a terminated thread with a larger stack - and
>>>> that's what we are seeing.
>>>>
>>>> So the fix is fine, I would just add before @run:
>>>>
>>>> @comment Must use the same stacksize for Java threads and compiler
>>>> threads in case of thread recycling
>>>>
>>>> Or something to that affect.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> David
>>>>>
>>>>> On 24/04/2018 7:24 AM, David Holmes wrote:
>>>>>> Hi Vladimir,
>>>>>>
>>>>>> On 24/04/2018 5:20 AM, Vladimir Kozlov wrote:
>>>>>>> http://cr.openjdk.java.net/~kvn/8202152/webrev.00/
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202152
>>>>>>>
>>>>>>> After 8198756 changes compiler threads could be released and
>>>>>>> other Java threads can re-use the same HW threads for which stack
>>>>>>> size was determined during start. The test WBStackSize.java may
>>>>>>> fail in such cases because Java thread stack size is set and
>>>>>>> checked in test.
>>>>>>
>>>>>> That does not make sense to me. We don't "re-use HW threads" - I'm
>>>>>> not even sure what that means. Compiler threads have a different
>>>>>> stacksize to other Java threads - that seems simple enough.
>>>>>>
>>>>>>> For 8198756 changes we added thread name check to workaround the
>>>>>>> problem [1]. But it seems is not enough.
>>>>>>
>>>>>> Why would this test be run in a compiler thread ????
>>>>>>
>>>>>>> To avoid this issue I added -XX:CompilerThreadStackSize=512 flag
>>>>>>> to match Java thread stack size (note, size is in Kb for this flag).
>>>>>>
>>>>>> That seems like a workaround of the real problem.
>>>>>>
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> I also reverted changes in test code and instead added thread
>>>>>>> name print to know in case we still have problem in a future.
>>>>>>>
>>>>>>> Tier1 testing (which run the test) passed.
>>>>>>>
>>>
>
From bsrbnd at gmail.com Wed Apr 25 12:00:41 2018
From: bsrbnd at gmail.com (B. Blaser)
Date: Wed, 25 Apr 2018 14:00:41 +0200
Subject: Large page use crashes the JVM on some Linux systems
In-Reply-To: <3bfbdf0a-7c9c-6b95-8c6a-a92c169dbf9b@oracle.com>
References: <CAEgw74ApMVY2EiYwWN6UZcbCx6dQZMt2bCKMuMM_2rY4nCjGWA@mail.gmail.com>
<3bfbdf0a-7c9c-6b95-8c6a-a92c169dbf9b@oracle.com>
Message-ID: <CAEgw74Bre8s+L8hmUzPzeBfJE-odYwhshMxwD_H2v3YXEAB6bg@mail.gmail.com>
[further private conversation summary]
On 24 April 2018 at 21:15, B. Blaser <bsrbnd at gmail.com> wrote:
> On 24 April 2018 at 11:47, Claes Redestad <claes.redestad at oracle.com> wrote:
>> Hi Bernard,
>>
>> On 2018-04-24 11:27, B. Blaser wrote:
>>> Hi Claes,
>>>
>>> Thanks for your feedback, I'll try to improve the fix as suggested.
>>
>> someone pointed out we already do a sanity check similar to the one you're
>> proposing..
>>
>> src/hotspot/os/linux/os_linux.cpp:
>>
>> bool os::Linux::hugetlbfs_sanity_check(bool warn, size_t page_size) {
>> [...]
>> }
>>
>> It seems it'll warn only if you explicitly use -XX:+UseHugeTLBFS.
>> -XX:+UseLargePages
>> on linux first attempts to use UseHugeTLBFS, then falls back to -XX:+UseSHM.
>>
>> ... what errors do you see on your system when you run -version with
>> -XX:+UseLargePages,
>> -XX:+UseHugeTLBFS and -XX:+UseSHM respectively? Most systems aren't
>> configured to
>> use HugeTLBFS, so my guess is your system actually has an issue with
>> UseSHM...
>
> I'm aware of this sanity check. The problem is that on my system
> 'mmap()' always fails and then the JVM attempts to use SHM instead.
> I'll check more deeply my configuration and read twice the kernel vm doc:
>
> https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt
>
> but, in short terms, both 'mmap()' and SHM can access large pages (2Mb
> on my computer) but it has to be enabled (also with SHM) which doesn't
> seem to be the case by default.
>
> So, to answer your questions:
> 1) -XX:+UseLargePages and -XX:+UseHugeTLBFS have the same effect than
> -XX:UseSHM because 'mmap' nicely complains when trying to use huge TLB
> and then SHM is used instead.
> 2) unfortunately, SHM doesn't complain (no problem when calling
> 'shmget' or 'shmat') but the allocated memory isn't aligned with the
> large page size (2Mb) which crashes the JVM (SHM probably allocates
> memory using the default page size even if requesting 2Mb pages -
> which I have to verify).
>
> In conclusion, the current JVM behavior of trying to use SHM if
> 'mmap()' fails seems to be brittle.
>
> I think, we have to check if large pages are supported/enabled when
> starting the JVM.
> Probably checking '/proc/meminfo' - '/proc/filesystems' -
> '/proc/sys/vm/nr_hugepages' would be faster than calling 'mmap()'.
>
> I'll read again the kernel doc, but I think calling 'mmap()' is a
> robust "slow" way to see if large pages can be used but I agree that
> it doesn't tell if they are not *enabled* or not *supported*.
>
> What do you think we should do?
>
> Bernard
>
>> /Claes
>>
>>> Thanks,
>>> Bernard
---------------------------------------------------------
On 24 April 2018 at 21:39, Claes Redestad <claes.redestad at oracle.com> wrote:
> The root issue here could very well be that the SHM sanity test is
> insufficient. Adding the same test as we already do for TLBFS seems like the
> wrong approach.
>
> I'm not the most knowledgeable about SHM, though, in fact not knowledgeable
> at all, so let's try and get you subscribed to hotspot-dev and spark a
> discussion on the list.
>
> /Claes
In concrete terms (on my system):
$ grep "hugetlbfs" /proc/filesystems
nodev hugetlbfs
$ grep -e "HugePages_" -e "Hugepagesize" /proc/meminfo
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Which means that huge pages are supported but not configured.
$ ./build/linux-x86_64-normal-server-release/jdk/bin/java
-XX:+UseLargePages -version
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (g1PageBasedVirtualSpace.cpp:49), pid=2914, tid=2915
# guarantee(is_aligned(rs.base(), page_size)) failed: Reserved space
base 0x00007f5c20b10000 is not aligned to requested page size 2097152
#
# JRE version: (11.0) (build )
# Java VM: OpenJDK 64-Bit Server VM (11-internal+0-adhoc.devel.jdk,
mixed mode, aot, tiered, compressed oops, g1 gc, linux-amd64)
# Core dump will be written. Default location: core.2914 (may not exist)
#
# An error report file with more information is saved as:
# /home/****/jdk/hs_err_pid2914.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
Aborted (core dumped)
$ ./build/linux-x86_64-normal-server-release/jdk/bin/java
-XX:+UseHugeTLBFS -version
OpenJDK 64-Bit Server VM warning: HugeTLBFS is not supported by the
operating system.
openjdk version "11-internal" 2018-09-25
OpenJDK Runtime Environment (build 11-internal+0-adhoc.devel.jdk)
OpenJDK 64-Bit Server VM (build 11-internal+0-adhoc.devel.jdk, mixed mode)
$ ./build/linux-x86_64-normal-server-release/jdk/bin/java -XX:+UseSHM -version
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (g1PageBasedVirtualSpace.cpp:49), pid=2974, tid=2975
# guarantee(is_aligned(rs.base(), page_size)) failed: Reserved space
base 0x00007f8a06890000 is not aligned to requested page size 2097152
#
# JRE version: (11.0) (build )
# Java VM: OpenJDK 64-Bit Server VM (11-internal+0-adhoc.devel.jdk,
mixed mode, aot, tiered, compressed oops, g1 gc, linux-amd64)
# Core dump will be written. Default location: core.2974 (may not exist)
#
# An error report file with more information is saved as:
# /home/****/jdk/hs_err_pid2974.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
Aborted (core dumped)
So, I guess the least the JVM should do is unconditionally disabling
large page use when starting if 'HugePages_Total: 0' in
'/proc/meminfo'.
But I'll investigate what can be done to improve SHM sanity check too.
Or maybe someone on hotspot-dev would have another idea?
Bernard
---------------------------------------------------------
On 23 April 2018 at 11:18, Claes Redestad <claes.redestad at oracle.com> wrote:
> [ /bcc amber-dev, /cc hotspot-dev ]
>
> Hi,
>
> unconditionally mapping and unmapping a large page on startup seems
> sub-optimal to me - could this be checked directly after
> -XX:+UseLargePages flag has been parsed?
>
> I'd also note that explicitly configured large pages are typically a limited
> resource: does this test distinguish between a failure due the system not
> supporting the feature and a failure due not having any free pages left?
> Printing a "UseLargePages is unsupported" message in the latter case
> would be misleading.
>
> I wonder if checking something like /proc/meminfo for HugePages_* is a
> more robust way to probe capabilities, and also whether this is more
> suited as a test harness feature, i.e., enhance jtreg and tag these tests
> so that they're ignored on systems that doesn't have any/enough huge
> pages.
>
> Thanks!
>
> /Claes
>
>
> On 2018-04-22 23:18, B. Blaser wrote:
>>
>> [ I've trouble subscribing to hotspot-dev, please forward if necessary. ]
>>
>> Hi,
>>
>> After a clean build, some hotspot tests related to large page use are
>> failing on my 64-bit Linux system, for example:
>>
>> gc/g1/TestLargePageUseForAuxMemory.java
>> [...]
>>
>> Or simply:
>>
>> $ ./build/linux-x86_64-normal-server-release/images/jdk/bin/java
>> -XX:+UseLargePages -version
>>
>> is crashing the JVM because the latter assumes that large pages are
>> always supported on Linux, which appears to be wrong.
>>
>> I suggest to make sure that large pages are supported when parsing the
>> arguments, as below.
>>
>> Does this look reasonable (tier1 looks better now)?
>>
>> Thanks,
>> Bernard
>>
>> diff -r 8c85a1855e10 src/hotspot/share/runtime/arguments.cpp
>> --- a/src/hotspot/share/runtime/arguments.cpp Fri Apr 13 11:14:49 2018
>> -0700
>> +++ b/src/hotspot/share/runtime/arguments.cpp Sun Apr 22 20:29:21 2018
>> +0200
>> @@ -60,6 +60,7 @@
>> #include "utilities/defaultStream.hpp"
>> #include "utilities/macros.hpp"
>> #include "utilities/stringUtils.hpp"
>> +#include "sys/mman.h"
>> #if INCLUDE_JVMCI
>> #include "jvmci/jvmciRuntime.hpp"
>> #endif
>> @@ -4107,6 +4108,18 @@
>> UNSUPPORTED_OPTION(UseLargePages);
>> #endif
>>
>> +#ifdef LINUX
>> + void *p = mmap(NULL, os::large_page_size(), PROT_READ|PROT_WRITE,
>> + MAP_ANONYMOUS|MAP_PRIVATE|MAP_HUGETLB,
>> + -1, 0);
>> + if (p != MAP_FAILED) {
>> + munmap(p, os::large_page_size());
>> + }
>> + else {
>> + UNSUPPORTED_OPTION(UseLargePages);
>> + }
>> +#endif
>> +
>> ArgumentsExt::report_unsupported_options();
>>
>> #ifndef PRODUCT
>> diff -r 8c85a1855e10
>> test/hotspot/jtreg/runtime/memory/LargePages/TestLargePagesFlags.java
>> ---
>> a/test/hotspot/jtreg/runtime/memory/LargePages/TestLargePagesFlags.java
>> Fri Apr 13 11:14:49 2018 -0700
>> +++
>> b/test/hotspot/jtreg/runtime/memory/LargePages/TestLargePagesFlags.java
>> Sun Apr 22 20:29:21 2018 +0200
>> @@ -37,7 +37,7 @@
>> public class TestLargePagesFlags {
>>
>> public static void main(String [] args) throws Exception {
>> - if (!Platform.isLinux()) {
>> + if (!Platform.isLinux() || !canUse(UseLargePages(true))) {
>> System.out.println("Skipping. TestLargePagesFlags has only been
>> implemented for Linux.");
>> return;
>> }
>
>
From david.holmes at oracle.com Wed Apr 25 12:05:07 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 25 Apr 2018 22:05:07 +1000
Subject: Bug Report: ConstantPool vs constantPool
In-Reply-To: <8fc3c700-fd0a-7ddc-435a-5b862aa679b8@oracle.com>
References: <OF194127C5.2275AA06-ON00258273.0045BB96-80258273.00464239@notes.na.collabserv.com>
<796afbd5-1832-0493-b4c5-0da8c12194ef@oracle.com>
<8fc3c700-fd0a-7ddc-435a-5b862aa679b8@oracle.com>
Message-ID: <09c987de-47b9-b8fd-adf7-2491a5ca4a39@oracle.com>
Hi Adam,
I'm curious what error you have seen as we don't seem to see it (though
perhaps we haven't looked closely enough). For me my Windows repo
already merges the two into a single ConstantPool directory.
I'm surprised Mercurial doesn't complain about it when cloning.
Still needs fixing of course.
Cheers,
David
On 25/04/2018 2:01 AM, coleen.phillimore at oracle.com wrote:
>
> Filed bug report:
> https://bugs.openjdk.java.net/browse/JDK-8202204
>
> thanks,
> Coleen
>
> On 4/24/18 11:13 AM, Jonathan Gibbons wrote:
>> Adam,
>>
>> While it would be good for jtreg to detect this,? the real fix is that
>> the directories need to be renamed, which is a matter for the hotspot
>> team. (cc:-ed)
>>
>> -- Jon
>>
>>
>>
>> On 4/18/18 5:47 AM, Adam Farley8 wrote:
>>> Hi All,
>>>
>>> Windows is having trouble with the constantPool and ConstantPool
>>> directories because they use the same name.
>>>
>>> Parent folder: test/hotspot/jtreg/runtime
>>>
>>> Is it a trivial matter to solve this?
>>>
>>> E.g. get the files from one copied into the other, followed by the
>>> deletion of the redundant constantPool?
>>>
>>> Best Regards
>>>
>>> Adam Farley
>>>
>>> Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales with number
>>> 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>>> PO6 3AU
>>
>
From glaubitz at physik.fu-berlin.de Wed Apr 25 12:18:09 2018
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Wed, 25 Apr 2018 14:18:09 +0200
Subject: Bug Report: ConstantPool vs constantPool
In-Reply-To: <09c987de-47b9-b8fd-adf7-2491a5ca4a39@oracle.com>
References: <OF194127C5.2275AA06-ON00258273.0045BB96-80258273.00464239@notes.na.collabserv.com>
<796afbd5-1832-0493-b4c5-0da8c12194ef@oracle.com>
<8fc3c700-fd0a-7ddc-435a-5b862aa679b8@oracle.com>
<09c987de-47b9-b8fd-adf7-2491a5ca4a39@oracle.com>
Message-ID: <849b842a-c6b6-3b89-f571-48fe38efc7ca@physik.fu-berlin.de>
On 04/25/2018 02:05 PM, David Holmes wrote:
> I'm curious what error you have seen as we don't seem to see it (though perhaps we haven't looked closely enough). For me my Windows repo already merges the two into a single ConstantPool directory.
>
> I'm surprised Mercurial doesn't complain about it when cloning.
>
> Still needs fixing of course.
It would be good to have an actual error message here, I think.
I would be surprised if such an issue was overlooked for a long
time. I would think that this would bite everyone trying to check
out the repository on Windows, wouldn't it?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz at debian.org
`. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
From david.holmes at oracle.com Wed Apr 25 12:45:15 2018
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 25 Apr 2018 22:45:15 +1000
Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for
ppc64
In-Reply-To: <OF16DAB34F.17FD9ED8-ON00258278.002211BA-49258278.003A0AFD@notes.na.collabserv.com>
References: <OF16DAB34F.17FD9ED8-ON00258278.002211BA-49258278.003A0AFD@notes.na.collabserv.com>
Message-ID: <5625a595-1165-8d48-afbd-8229cdc4ac07@oracle.com>
Hi Michihiro,
On 23/04/2018 8:33 PM, Michihiro Horie wrote:
>
>
> Dear all,
>
> I would like to ask reviews on 8154736 ?enhancement of cmpxchg and
> copy_to_survivor?. The change adds options to avoid expensive syncs with
> compare-and-exchange. An experiment by using SPECjbb2015 showed 6%
> improvement in critical-jOPS. This change focuses on ppc64 but would be
> potentially beneficial for aarch64.
>
> Although discussions stopped at
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-October/002718.html
> , I would like to restart the review by taking over Hiroshi's work if the
> discussion is still open.
So the very last comment there was about not implicitly assuming
memory_order_consume, yet that has not been addressed in the proposal.
Further the discussion on hotspot-runtime-dev through September and
October was far more illuminating. I think my post here:
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-October/021617.html
and the closely following one from Thomas Schatzl summed up the concerns
about the proposed changes.
AFAICS the restarted proposal addresses none of those concerns but
simply takes up where the previous implementation suggestion left off.
This is a proposal to change the memory ordering semantics of part of
the shared GC code _not_ just the PPC64 implementation, but I have seen
no analysis to demonstrate the correctness of such a proposal.
David
-----
> Bug: https://bugs.openjdk.java.net/browse/JDK-8154736
> Webrev: http://cr.openjdk.java.net/~mhorie/8154736/webrev.08/
>
> Previous review had discussions on improper log output (
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-September/002672.html
> ). Logs can be generated properly with this change, but I would like to ask
> if we should use ?if(log) OrderAccess:acquire()? as is in webrev or more
> general approach with a call to OrderAccess:consume() with empty
> implementation on all supported platforms.
>
> Also, there were discussions on the problem of unawareness of copied obj (
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-October/002696.html
> ). This change adds ?release? in cmpxchg_pre_membar. This was discussed in
> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-October/002698.html
> .
>
> I measured SPECjbb2015 with its multi JVMs mode on a POWER8 node (for JDK11
> , I modified MANIFEST in specjbb2015.jar to specify locations of JAXB
> related libraries). As a result, critical-jOPS improved by 6% due to this
> change.
>
> Best regards,
> --
> Michihiro,
> IBM Research - Tokyo
>
From adam.farley at uk.ibm.com Wed Apr 25 13:16:36 2018
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Wed, 25 Apr 2018 14:16:36 +0100
Subject: Bug Report: ConstantPool vs constantPool
In-Reply-To: <849b842a-c6b6-3b89-f571-48fe38efc7ca@physik.fu-berlin.de>
References: <OF194127C5.2275AA06-ON00258273.0045BB96-80258273.00464239@notes.na.collabserv.com>
<796afbd5-1832-0493-b4c5-0da8c12194ef@oracle.com>
<8fc3c700-fd0a-7ddc-435a-5b862aa679b8@oracle.com>
<09c987de-47b9-b8fd-adf7-2491a5ca4a39@oracle.com>
<849b842a-c6b6-3b89-f571-48fe38efc7ca@physik.fu-berlin.de>
Message-ID: <OFDEEDA1FE.532784E1-ON0025827A.0045FB32-8025827A.0048EF28@notes.na.collabserv.com>
Hi David, John,
There is no error message. The specific problem I'm seeing is when
I view the OpenJDK source in Eclipse. We test our changes locally
using a GIT repository to record progress and share fixes. When I
check out the "Unstaged changes" view, a fresh clone shows a
set of changes whereby it thinks a bunch of the constant pool files
got moved into the other folder, because it can't understand two folders
on windows with the same paths but different names.
This blocks a bunch of functionality, as these "changes" can't be ignored,
either via the ignore file or the ignore case git environment variable.
Best Regards
Adam Farley
> On 04/25/2018 02:05 PM, David Holmes wrote:
> > I'm curious what error you have seen as we don't seem to see it
(though perhaps we haven't looked closely enough). For me my Windows repo
already merges the two into a single ConstantPool directory.
> >
> > I'm surprised Mercurial doesn't complain about it when cloning.
> >
> > Still needs fixing of course.
> It would be good to have an actual error message here, I think.
>
> I would be surprised if such an issue was overlooked for a long
> time. I would think that this would bite everyone trying to check
> out the repository on Windows, wouldn't it?
>
> Adrian
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
From rickard.backman at oracle.com Wed Apr 25 13:31:17 2018
From: rickard.backman at oracle.com (Rickard =?utf-8?Q?B=C3=A4ckman?=)
Date: Wed, 25 Apr 2018 15:31:17 +0200
Subject: RFR: 8201543: Modularize C1 GC barriers
In-Reply-To: <5AD9EFE3.4020203@oracle.com>
References: <5AD0C89E.7050807@oracle.com>
<5AD9EFE3.4020203@oracle.com>
Message-ID: <20180425133117.o6bj5lratdeqts2c@rbackman>
Looks good :)
/R
On 04/20, Erik ?sterlund wrote:
> Hi everyone,
>
> I sat down with Rickard and Per at the office to have a look at this, and
> have built a new webrev based on their feedback.
> The main elements in the delta are the following:
>
> 1) Wrap various context information that is passed around in the
> BarrierSetC1 hierarchy in a wrapper object (to reduce boiler plate), that
> has been named LIRAccess. It contains the address elements (base and offset,
> as either LIRItem or LIROpr), as well as the decorators, and the
> CodeEmitInfo of the address (for patching), the CodeEmitInfo for the access
> (for things like implicit null checks), and the LIRGenerator instance, that
> would normally be passed around to every function.
> 2) Added #ifdef COMPILER1 in the G1BarrierSetC1 classes to be polite to
> people trying to build HotSpot with a generated interpreter but no C1
> compiler.
> 3) Added a decorator_fixup() method that applies various implicit decorator
> rules for sane defaults (for example, IN_HEAP_ARRAY implies IN_HEAP). This
> is a 1:1 mirror to the DecoratorFixup meta function used in the runtime
> backend. Both are now located in accessDecorator.hpp. One for use by
> templates (DecoratorFixup), and one for use by code generators that do not
> use templates (decorator_fixup()).
> 4) Removed some unnecessary includes and friend class declarations.
> 5) Made BarrierSetC1 a member of LIRGenerator to reduce boiler plate
> further.
> 6) Changed name of the lir_generator variable passed around to gen, to be
> consistent with what other code in C1 does when passing around the
> LIRGenerator instance.
>
> Incremental webrev:
> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.00_01/
>
> Full webrev:
> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.01/
>
> Big thanks to Rickard and Per for having a look at this.
>
> Thanks,
> /Erik
>
> On 2018-04-13 17:11, Erik ?sterlund wrote:
> > Hi,
> >
> > The GC barriers for C1 are not as modular as they could be. It currently
> > uses switch statements to check which GC barrier set is being used, and
> > calls one or another barrier based on that, in a way that it can only be
> > used for write barriers.
> >
> > The solution I propose is to add the same facilities that have been
> > added in runtime and the interpreter already: a barrier set backend for
> > C1. I call it BarrierSetC1, and it helps us generate decorated accesses
> > that give the GC control over the details how to generate this access.
> > It recognizes the same decorators (accessDecorators.hpp) that the other
> > parts of the VM recognize. Each concrete barrier set has its own
> > backend. For now, these are CardTableBarrierSetC1 and G1BarrierSetC1,
> > but this should pave way for upcoming concurrently compacting GCs as
> > well.
> >
> > Two decorators were added for C1 specifically (found in
> > c1_Decorators.hpp):
> > C1_NEEDS_PATCHING for accesses where the index is not yet load because
> > the class has yet to be loaded, and
> > C1_MASK_BOOLEAN for accesses that need to mask untrusted boolean values.
> >
> > LIRGenerator calls a wrapper called access_store_at, access_load_at, etc
> > (there are variants for cpmxchg, xchg and atomic add as well).
> > The access call calls straight into the BarrierSetC1 hierarchy using
> > virtual calls. It is structured in a way very similar to
> > BarrierSetAssembler.
> >
> > BarrierSetC1 can also be called during initialization to generate stubs
> > and runtime methods required by C1. For G1BarrierSetC1, this results in
> > calling the BarrierSetAssembler for the platform specific code. This
> > way, the BarrierSetC1 hierarchy has been carefully kept in shared code,
> > and the switch statements for generating G1 code have been removed. Some
> > code that used to be platform specific (like unsafe get/set and array
> > store) have been broken out to shared code, with the actual platform
> > specific details (some register allocation for store check and atomics)
> > broken out to platform specific methods. This way, calls to access are
> > kept in platform specific code.
> >
> > As usual, big thanks go to Martin Doerr for helping out with S390 and
> > PPC, and Roman for taking care of AArch64.
> >
> > Bug:
> > https://bugs.openjdk.java.net/browse/JDK-8201543
> >
> > Webrev:
> > http://cr.openjdk.java.net/~eosterlund/8201543/webrev.00/
> >
> > Thanks,
> > /Erik
>
From erik.osterlund at oracle.com Wed Apr 25 13:35:31 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Wed, 25 Apr 2018 15:35:31 +0200
Subject: RFR: 8201543: Modularize C1 GC barriers
In-Reply-To: <20180425133117.o6bj5lratdeqts2c@rbackman>
References: <5AD0C89E.7050807@oracle.com> <5AD9EFE3.4020203@oracle.com>
<20180425133117.o6bj5lratdeqts2c@rbackman>
Message-ID: <5AE08423.9000702@oracle.com>
Hi Rickard,
Thanks for the review!
/Erik
On 2018-04-25 15:31, Rickard B?ckman wrote:
> Looks good :)
>
> /R
>
> On 04/20, Erik ?sterlund wrote:
>> Hi everyone,
>>
>> I sat down with Rickard and Per at the office to have a look at this, and
>> have built a new webrev based on their feedback.
>> The main elements in the delta are the following:
>>
>> 1) Wrap various context information that is passed around in the
>> BarrierSetC1 hierarchy in a wrapper object (to reduce boiler plate), that
>> has been named LIRAccess. It contains the address elements (base and offset,
>> as either LIRItem or LIROpr), as well as the decorators, and the
>> CodeEmitInfo of the address (for patching), the CodeEmitInfo for the access
>> (for things like implicit null checks), and the LIRGenerator instance, that
>> would normally be passed around to every function.
>> 2) Added #ifdef COMPILER1 in the G1BarrierSetC1 classes to be polite to
>> people trying to build HotSpot with a generated interpreter but no C1
>> compiler.
>> 3) Added a decorator_fixup() method that applies various implicit decorator
>> rules for sane defaults (for example, IN_HEAP_ARRAY implies IN_HEAP). This
>> is a 1:1 mirror to the DecoratorFixup meta function used in the runtime
>> backend. Both are now located in accessDecorator.hpp. One for use by
>> templates (DecoratorFixup), and one for use by code generators that do not
>> use templates (decorator_fixup()).
>> 4) Removed some unnecessary includes and friend class declarations.
>> 5) Made BarrierSetC1 a member of LIRGenerator to reduce boiler plate
>> further.
>> 6) Changed name of the lir_generator variable passed around to gen, to be
>> consistent with what other code in C1 does when passing around the
>> LIRGenerator instance.
>>
>> Incremental webrev:
>> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.00_01/
>>
>> Full webrev:
>> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.01/
>>
>> Big thanks to Rickard and Per for having a look at this.
>>
>> Thanks,
>> /Erik
>>
>> On 2018-04-13 17:11, Erik ?sterlund wrote:
>>> Hi,
>>>
>>> The GC barriers for C1 are not as modular as they could be. It currently
>>> uses switch statements to check which GC barrier set is being used, and
>>> calls one or another barrier based on that, in a way that it can only be
>>> used for write barriers.
>>>
>>> The solution I propose is to add the same facilities that have been
>>> added in runtime and the interpreter already: a barrier set backend for
>>> C1. I call it BarrierSetC1, and it helps us generate decorated accesses
>>> that give the GC control over the details how to generate this access.
>>> It recognizes the same decorators (accessDecorators.hpp) that the other
>>> parts of the VM recognize. Each concrete barrier set has its own
>>> backend. For now, these are CardTableBarrierSetC1 and G1BarrierSetC1,
>>> but this should pave way for upcoming concurrently compacting GCs as
>>> well.
>>>
>>> Two decorators were added for C1 specifically (found in
>>> c1_Decorators.hpp):
>>> C1_NEEDS_PATCHING for accesses where the index is not yet load because
>>> the class has yet to be loaded, and
>>> C1_MASK_BOOLEAN for accesses that need to mask untrusted boolean values.
>>>
>>> LIRGenerator calls a wrapper called access_store_at, access_load_at, etc
>>> (there are variants for cpmxchg, xchg and atomic add as well).
>>> The access call calls straight into the BarrierSetC1 hierarchy using
>>> virtual calls. It is structured in a way very similar to
>>> BarrierSetAssembler.
>>>
>>> BarrierSetC1 can also be called during initialization to generate stubs
>>> and runtime methods required by C1. For G1BarrierSetC1, this results in
>>> calling the BarrierSetAssembler for the platform specific code. This
>>> way, the BarrierSetC1 hierarchy has been carefully kept in shared code,
>>> and the switch statements for generating G1 code have been removed. Some
>>> code that used to be platform specific (like unsafe get/set and array
>>> store) have been broken out to shared code, with the actual platform
>>> specific details (some register allocation for store check and atomics)
>>> broken out to platform specific methods. This way, calls to access are
>>> kept in platform specific code.
>>>
>>> As usual, big thanks go to Martin Doerr for helping out with S390 and
>>> PPC, and Roman for taking care of AArch64.
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8201543
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.00/
>>>
>>> Thanks,
>>> /Erik
From erik.osterlund at oracle.com Wed Apr 25 13:53:40 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Wed, 25 Apr 2018 15:53:40 +0200
Subject: RFR: 8202082: Remove explicit CMS checks in
CardTableBarrierSetAssembler
In-Reply-To: <1964D307-E283-47CA-96C6-7AF577F96EC4@oracle.com>
References: <5AD9FC94.70607@oracle.com>
<6A476A6A-47BB-4141-980E-DB98D9BAD405@oracle.com>
<67ac1742-640e-f011-f371-cf53b782e969@oracle.com>
<60EA410E-E1FE-4A54-95CA-E3F11CC9B168@oracle.com>
<9c283f66-326a-d640-432d-b6c573802b5e@oracle.com>
<1964D307-E283-47CA-96C6-7AF577F96EC4@oracle.com>
Message-ID: <5AE08864.4070802@oracle.com>
Hi Kim,
Okay, it looks like we kind of agree that this is a step in the right
direction for now. Thank you for the review.
Here is my final webrev with "disp" not refetched (and renamed to
card_table_addr):
http://cr.openjdk.java.net/~eosterlund/8202082/webrev.01/
Incremental:
http://cr.openjdk.java.net/~eosterlund/8202082/webrev.00_01/
Thanks,
/Erik
On 2018-04-25 04:23, Kim Barrett wrote:
>> On Apr 24, 2018, at 3:17 PM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>>
>> Hi Kim,
>>
>> On 2018-04-24 20:23, Kim Barrett wrote:
>>>> On Apr 24, 2018, at 2:57 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>>>>
>>>> Hi Kim,
>>>>
>>>> On 2018-04-24 04:15, Kim Barrett wrote:
>>>>>> On Apr 20, 2018, at 10:43 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> In CardTableBarrierSetAssembler, we sometimes need fencing due to the card table being scanned concurrently when using CMS with pre-cleaning. Rather than explicitly checking for those CMS flags in the generic CardTableBarrierSetAssembler class, it is preferrable to check the CardTable scanned_concurrently() property which already precisely reflects that.
>>>>>>
>>>>>> Bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202082
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.00/
>>>>>>
>>>>>> Thanks,
>>>>>> /Erik
>>>>> ------------------------------------------------------------------------------
>>>>> src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
>>>>> 121 if (ct->scanned_concurrently()) {
>>>>>
>>>>> I think the correct test here is card_mark_must_follow_store. See
>>>>> my review of 8202083 for more details.
>>>>>
>>>>> Similarly for the other platforms.
>>>> I disagree. Let me explain why, and where I am trying to get with this.
>>>>
>>>> We used to have a whole bunch of different ways of making decisions based on whether the card table is scanned concurrently or not, queried in various ways, depending on whether we were talking to the CollectedHeap interface, the CardTableModRefBS interface, or whether we were inside of the CardTableModRefBS class. I am trying to remove those one by one, until only one is left, the configuration point in CardTable which describes precisely that: that the card table is scanned concurrently. Here are a few examples:
>>>>
>>>> * The ReduceInitialCardMarks optimization either defers card marks or issues them immediately on slowpath allocations, depending on whether the card table is scanned concurrently or not (this used to ask CollectedHeap about these queries).
>>>> * Inside of the post barriers, StoreStore fencing between the reference store and card mark depends on whether the card table is scanned concurrently or not. (checked with explicit CMS + precleaning and sometimes conservatively just CMS checks)
>>>> * When using UseCondCardMark, there is a StoreLoad fence to make sure the store of the reference happens-before the *load* of the card value (not the store of the card value) for filtering. Again, this is only an issue when the card table is scanned concurrently, and not very well described by whether the card mark must follow the store IMO.
>>>>
>>>> The reason there is not yet a single property is that some code has previously asked CollectedHeap about these questions from outside of GC code (ReduceInitialCardMarks), while other code lived in the card table barrier set (CMS + pre-cleaning checks). Where I want to go is that no code outside of the CardTableBarrierSet classes should need to ask these questions. And code inside of the CardTableBarrierSet classes should ask its CardTable, which acts as a configuration, whether it is scanned concurrently or not.
>>>>
>>>> So basically, I would prefer to now remove the card_mark_must_follow_store() method, and replace it with direct calls to whether the card table is scanned concurrently.
>>>>
>>>> Do you agree?
>>> I agree that fewer sources for what is effectively the same
>>> information would be good. I just don't think CardTable is the right
>>> place for this piece of information. CardTable is (largely) a
>>> "simple" data structure (*), and doesn't care whether it's scanned
>>> concurrently or not. I think it belongs in the CTBS.
>> Whether the CardTable is scanned concurrently or not is the property we are consistently interested in. That is a natural property of the CardTable to me, and hence belongs in the CardTable. I don't see a convincing argument why it would not be a natural property of the CardTable. Conversely, I find that it would mess up GenCollectedHeap if it was not. Currently, the GenCollectedHeaps unconditionally instantiates a CardTableBarrierSet, with a single configuration parameter: the CardTable, which is created with a virtual call as either CardTableRS or CMSCardTable. With your proposal to move the property of whether the CardTable is scanned concurrently or not, out from the CardTable, that would inevitably result in more virtual calls only for configuring the CardTableBarrierSet with this property, or make the CardTableBarrierSet itself into a configuration (created with virtual calls). That does not look like a win to me. Do you agree?
>>
>>> (*) I think CardTable could be simpler. It presently contains a fair
>>> amount of stuff that seems only needed by CMS or only needed by G1,
>>> and should perhaps be placed elsewhere.
>> Sure. Those things should be moved into CMSCardTable and G1CardTable respectively.
> Or stated differently:
> Whether the collector scans the card table concurrently or not is the
> property we are consistently interested in. That is a natural
> property of the collector to me...
>
> I see the card table as data, that can/should be largely independent
> of the collector / barrier set. The collector / barrier set operate on
> that data, and different collectors operate on it in different ways.
> It's the collector / barrier set that determines the policies and
> behaviors. In particular, there's no intrinsic reason for the card
> table to have any knowledge at all about whether it is scanned
> concurrently or not.
>
> I'm also doubtful about the hierarchy based on CardTable, though I
> understand how we got to where we are; I once took a stab at
> extracting the card table stuff from the barrier set stuff, and all I
> got was a mess. You did better, but it's still pretty messy and could
> use more work.
>
> That said, an argument that the messiness that we presently have makes
> the card table an easier place to put this bit of information does
> carry weight. So okay, I guess.
>
>>>>> src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
>>>>> 113 AddressLiteral cardtable((address)ctbs->card_table()->byte_map_base(), relocInfo::none);
>>> Why not
>>>
>>> intptr_t disp = (intptr_t) ct->byte_map_base();
>>> ...
>>> AddressLiteral cardtable((address)disp, relocInfo::none);
>>>
>>> That would have saved me some staring at these expressions to figure
>>> out that there weren't any differences.
>> Okay. I will fix it then.
> Thanks.
>
From gnu.andrew at redhat.com Wed Apr 25 14:51:36 2018
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 25 Apr 2018 15:51:36 +0100
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
readdir_r(DIR*, dirent*, dirent**)' is deprecated
In-Reply-To: <D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
<D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
Message-ID: <CABi63P4-Grx7KNXrfRkZX9gGFkEida4Kzz2Eh2GsoLF+xT9WvQ@mail.gmail.com>
On 24 April 2018 at 20:17, Kim Barrett <kim.barrett at oracle.com> wrote:
>> On Apr 23, 2018, at 3:51 AM, Michal Vala <mvala at redhat.com> wrote:
>>
>> Hi,
>>
>> following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm posting updated patch replacing deprecated readdir_r with readdir. Bug ID is JDK-8179887 [2].
>>
>> webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
>>
>> I'm asking for the review and eventually sponsorship.
>
The patch looks good to me.
> The change to os::readdir in os_linux.inline.hpp looks fine.
>
> I was going to suggest that rather than changing perfMemory_linux.cpp to use os::readdir in an
> unusual and platform-specific way, it should instead just call ::readdir directly. However, neither
> of those is right, and that part of the change should not be made; see
> https://bugs.openjdk.java.net/browse/JDK-8134540
> Much nearly duplicated code for PerfMemory support
>
I think, in the circumstances, Michal's solution is the best option at
this point.
8134540 looks like a more long-term change currently scheduled for 12 (is
anyone currently working on it?), whereas this fix could go into 11 and remove
a couple of unneeded memory allocations.
> Looking a bit deeper, there might be some additional follow-on that could be done, eliminating
> the second argument to os::readdir.
> windows: unused
> bsd: freebsd also deprecated readdir_r, I think for similar reasons.
> solaris: doc is clear about thread safety issue being about sharing the DIR*
> aix: I haven?t looked at it, but would guess it?s similar.
>
> In other words, don?t operate on the DIR* from multiple threads simultaneously, and just use
> ::readdir on non-Windows. That would all be for another RFE though.
>
>
This also seems like a more in-depth separate change and not one that
can be performed
by any of us alone, as we don't test all these platforms. As it
stands, Michal's change affects
Linux and Linux alone, and the addition of the use of NULL will make
it clearer that moving
to an os:readdir is feasible on that platform.
Thanks,
--
Andrew :)
Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
From matthias.baesken at sap.com Wed Apr 25 14:56:45 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 25 Apr 2018 14:56:45 +0000
Subject: zip-library handling in Hotspot
Message-ID: <1ada76d3cf0d46fe890653978df530f2@sap.com>
Hello, when recently working on symbol visibility issues (in libzip and others too) after the removal of mapfiles across jdk11 ,
I thought it would be helpful to get the detailed information about missing libzip symbols not only for ZIP_InflateFully ("Corrupted ZIP library ZIP_InflateFully missing" )
But also for the other needed symbols.
Do you think it makes sense to add this small change ( a suggested diff is below ) ?
Best regards, Matthias
d040975 at ld9385:/usr/work/d040975/open_jdk/jdk_2/jdk> hg diff
diff -r b2e74972c7d4 src/hotspot/share/classfile/classLoader.cpp
--- a/src/hotspot/share/classfile/classLoader.cpp Wed Apr 25 13:54:11 2018 +0200
+++ b/src/hotspot/share/classfile/classLoader.cpp Wed Apr 25 16:39:39 2018 +0200
@@ -1195,16 +1195,17 @@
ZipInflateFully = CAST_TO_FN_PTR(ZipInflateFully_t, os::dll_lookup(handle, "ZIP_InflateFully"));
Crc32 = CAST_TO_FN_PTR(Crc32_t, os::dll_lookup(handle, "ZIP_CRC32"));
- // ZIP_Close is not exported on Windows in JDK5.0 so don't abort if ZIP_Close is NULL
if (ZipOpen == NULL || FindEntry == NULL || ReadEntry == NULL ||
- GetNextEntry == NULL || Crc32 == NULL) {
+ GetNextEntry == NULL || Crc32 == NULL || ZipInflateFully == NULL) {
+ if (ZipOpen == NULL) { tty->print_cr("Corrupted ZIP library at %s, ZIP_Open lookup failed", path); }
+ if (FindEntry == NULL) { tty->print_cr("Corrupted ZIP library at %s, ZIP_FindEntry lookup failed", path); }
+ if (ReadEntry == NULL) { tty->print_cr("Corrupted ZIP library at %s, ZIP_ReadEntry lookup failed", path); }
+ if (GetNextEntry == NULL) { tty->print_cr("Corrupted ZIP library at %s, ZIP_GetNextEntry lookup failed", path); }
+ if (Crc32 == NULL) { tty->print_cr("Corrupted ZIP library at %s, ZIP_CRC32 lookup failed", path); }
+ if (ZipInflateFully == NULL) { tty->print_cr("Corrupted ZIP library at %s, ZipInflateFully lookup failed", path); }
vm_exit_during_initialization("Corrupted ZIP library", path);
}
- if (ZipInflateFully == NULL) {
- vm_exit_during_initialization("Corrupted ZIP library ZIP_InflateFully missing", path);
- }
-
// Lookup canonicalize entry in libjava.dll
void *javalib_handle = os::native_java_library();
CanonicalizeEntry = CAST_TO_FN_PTR(canonicalize_fn_t, os::dll_lookup(javalib_handle, "Canonicalize"));
From kim.barrett at oracle.com Wed Apr 25 15:02:42 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 25 Apr 2018 11:02:42 -0400
Subject: RFR: 8200557: OopStorage parallel iteration scales poorly
In-Reply-To: <7CBB6FF2-AC36-4723-BBA1-B4FA277C707B@oracle.com>
References: <7CBB6FF2-AC36-4723-BBA1-B4FA277C707B@oracle.com>
Message-ID: <BFB64637-AF8E-4816-A302-A5096549CF29@oracle.com>
Anyone looking at this yet?
> On Apr 19, 2018, at 4:18 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
>
> Please review this change to OopStorage parallel iteration to improve
> the scaling with additional threads.
>
> Two sources of poor scaling were found: (1) contention when claiming
> blocks, and (2) each worker thread ended up touching the majority of
> the blocks, even those not processed by that thread.
>
> To address this, we changed the representation of the sequence of all
> blocks. Rather than being a doubly-linked intrusive list linked
> through the blocks, it is now an array of pointers to blocks. We use
> a combination of refcounts and an RCU-inspired mechanism to safely
> manage the array storage when it needs to grow, avoiding the need to
> lock access to the array while performing concurrent iteration.
>
> The use of an array for the sequence of all blocks permits parallel
> iteration to claim ranges of indices using Atomic::add, which can be
> more efficient on some platforms than using cmpxchg loops. It also
> allows a worker thread to only touch exactly those blocks it is going
> to process, rather than walking a list of blocks. The only
> complicating factor is that we have to account for possible overshoot
> in a claim attempt.
>
> Blocks know their position in the array, to facilitate empty block
> deletion (an empty block might be anywhere in the active array, and we
> don't want to have to search for it). This also helps with
> allocation_status, eliminating the verification search that was needed
> with the list representation. allocation_status is now constant-time,
> which directly benefits -Xcheck:jni.
>
> A new gtest-based performance demonstration is included. It's not
> really a test, in that it doesn't do any verification. Rather, it
> performs parallel iteration and reports total time, per-thread times,
> and per-thread percentage of blocks processed. This is done for a
> variety of thread counts, to show the parallel speedup and load
> balancing. Running on my dual 6 core Xeon, I'm seeing more or less
> linear speedup for up to 10 threads processing 1M OopStorage entries.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8200557
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8200557/open.00/
>
> Testing:
> jdk-tier{1-3}, hs-tier{1-5}, on all Oracle supported platforms
From adam.farley at uk.ibm.com Wed Apr 25 15:03:20 2018
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Wed, 25 Apr 2018 16:03:20 +0100
Subject: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory
Usage for Direct Byte Buffers
Message-ID: <OF455C7D14.D7B8702A-ON0025827A.0052A333-8025827A.0052B4B1@notes.na.collabserv.com>
> On 13/04/2018 15:14, Adam Farley8 wrote:
>> Hi Alan, Peter,
>>
>> I see that native memory is tracked in java.nio.Bits, but that only
includes what the user thinks they are allocating.
>>
>> When the VM adds extra memory to the allocation amount this extra bit
is not represented in the Bits total.
>> A cursory glance shows, minimum, that we round the requested memory
quantity up to the heap word size in
>> the Unsafe.allocateMemory code, and something to do with
nmt_header_size in os:malloc() (os.cpp) too.
> Is the align_up(sz, HeapWordSize) really causing an issue?
Coupled with the nmt_header_size business, it makes the Bits values wrong.
The more DBB allocations, the more
inaccurate those numbers will be.
>
> We could change Bits to align with HotSpot. The BufferPoolMXBean API
allows the capacity and memory usage to differ (when we originally added
this, direct buffers were page aligned) so doing this would mean it more
accurately reflects the memory allocated to direct buffers.
>
> -Alan
I agree with you that the "+x" information should be added to only one of
the two atomic longs.
To get "X", it seems to me that the best option would be to introduce an
native method in Bits that fetches
"X" directly from Hotspot, using the same code that Hotspot uses (so we'd
have to abstract-out the Hotspot logic
that adds X to the memory quantity).
This way, anyone modifying the Hotspot logic won't risk rendering the Bits
logic wrong again.
Best Regards
Adam Farley
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
From kim.barrett at oracle.com Wed Apr 25 21:09:40 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 25 Apr 2018 17:09:40 -0400
Subject: RFR: 8202230: Provide accessors for JNIHandles storage objects
Message-ID: <5910FB44-4D8C-4127-823E-DDB6ED4275CF@oracle.com>
Please review this addition to JNIHandles, providing access to the
OopStorage objects used to manage the global and weak global handles.
The accessors assert the storage objects have been allocated.
Also changed direct uses of the storage object variables to instead
use the new accessors, to get the initialization asserts during
development.
CR:
https://bugs.openjdk.java.net/browse/JDK-8202230
Webrev:
http://cr.openjdk.java.net/~kbarrett/8202230/open.00/
Testing:
{jdk,hs}-tier{1,2,3} for all Oracle platforms.
From coleen.phillimore at oracle.com Wed Apr 25 21:30:42 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 25 Apr 2018 17:30:42 -0400
Subject: RFR: 8200557: OopStorage parallel iteration scales poorly
In-Reply-To: <7CBB6FF2-AC36-4723-BBA1-B4FA277C707B@oracle.com>
References: <7CBB6FF2-AC36-4723-BBA1-B4FA277C707B@oracle.com>
Message-ID: <e97b683b-8930-7323-21c1-da7238fa9324@oracle.com>
http://cr.openjdk.java.net/~kbarrett/8200557/open.00/src/hotspot/share/gc/shared/oopStorage.cpp.udiff.html
+OopStorage::BasicParState::IterationData::IterationData() :
+ _segment_start(0),
+ _segment_end(0),
+ _processed(0)
+{}
Can this constructor be inlined in the declaration?? This seems out of
place here (and I had to hunt for it).
Can some other simple accessors be inlined in the declarations as well??
That would decrease jumping around trying to understand things.
I think the OopStorage::BasicParState functions should be in a new .cpp
file since there's now *src/hotspot/share/gc/shared/oopStorageParState.hpp
*Can you do this as a follow up/cleanup RFE?
http://cr.openjdk.java.net/~kbarrett/8200557/open.00/src/hotspot/share/gc/shared/oopStorage.hpp.udiff.html
class Block; // Forward decl; defined in .inline.hpp file.
+ class BlockArray; // Forward decl; defined in .inline.hpp file.
class BlockList; // Forward decl for BlockEntry friend decl.
Can you give a short description of these, ie:
class Block; // Block of oop* stored in OopStorage
+ class BlockArray; // Storage for all active oop Blocks
class BlockList; // List of oop Blocks from which are available for allocation
Or maybe a short description over the class declarations?? The trouble
with these generic names is you forget why they exist.
I'd call BlockList a AllocationBlockList and BlockArray an ActiveBlockArray
http://cr.openjdk.java.net/~kbarrett/8200557/open.00/src/hotspot/share/gc/shared/oopStorage.inline.hpp.frames.html
38 class OopStorage::BlockArray {
This would be a good place to comment the purpose of this and a line
about refcounting.
http://cr.openjdk.java.net/~kbarrett/8200557/open.00/src/hotspot/share/gc/shared/oopStorage.hpp.frames.html
Why does BlockList need to be included in the .hpp file?
http://cr.openjdk.java.net/~kbarrett/8200557/open.00/src/hotspot/share/gc/shared/oopStorage.cpp.frames.html
All these places have block_count() which are indistinguishable. It
looks like _block_count for the BlockArray should always be acquired
outside of BlockArray class or rather give that as the only public
option to prevent mistakes.? It seems like there wouldn't be much
performance cost to calling load_acquire once at the safepoint iteration.
Comment about _why_ refcounts and what do they do here would be nice.
151 void OopStorage::BlockArray::increment_refcount() const {
567 void OopStorage::relinquish_block_array(BlockArray* array) const {
568 if (array->decrement_refcount()) {
569 assert(array != _active_array, "invariant");
570 BlockArray::destroy(array);
571 }
572 }
Here array is a pointer to the active array so iterators could destroy
the array if they are the last ones to use it.? Is this right?
I've read through most of the rest of the code and it looks good apart
from how complicated it is, which I don't know how to suggest to improve
it other than some reminder comments and maybe more descriptive names.
thanks,
Coleen
On 4/19/18 4:18 AM, Kim Barrett wrote:
> Please review this change to OopStorage parallel iteration to improve
> the scaling with additional threads.
>
> Two sources of poor scaling were found: (1) contention when claiming
> blocks, and (2) each worker thread ended up touching the majority of
> the blocks, even those not processed by that thread.
>
> To address this, we changed the representation of the sequence of all
> blocks. Rather than being a doubly-linked intrusive list linked
> through the blocks, it is now an array of pointers to blocks. We use
> a combination of refcounts and an RCU-inspired mechanism to safely
> manage the array storage when it needs to grow, avoiding the need to
> lock access to the array while performing concurrent iteration.
>
> The use of an array for the sequence of all blocks permits parallel
> iteration to claim ranges of indices using Atomic::add, which can be
> more efficient on some platforms than using cmpxchg loops. It also
> allows a worker thread to only touch exactly those blocks it is going
> to process, rather than walking a list of blocks. The only
> complicating factor is that we have to account for possible overshoot
> in a claim attempt.
>
> Blocks know their position in the array, to facilitate empty block
> deletion (an empty block might be anywhere in the active array, and we
> don't want to have to search for it). This also helps with
> allocation_status, eliminating the verification search that was needed
> with the list representation. allocation_status is now constant-time,
> which directly benefits -Xcheck:jni.
>
> A new gtest-based performance demonstration is included. It's not
> really a test, in that it doesn't do any verification. Rather, it
> performs parallel iteration and reports total time, per-thread times,
> and per-thread percentage of blocks processed. This is done for a
> variety of thread counts, to show the parallel speedup and load
> balancing. Running on my dual 6 core Xeon, I'm seeing more or less
> linear speedup for up to 10 threads processing 1M OopStorage entries.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8200557
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8200557/open.00/
>
> Testing:
> jdk-tier{1-3}, hs-tier{1-5}, on all Oracle supported platforms
>
From coleen.phillimore at oracle.com Wed Apr 25 21:34:44 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 25 Apr 2018 17:34:44 -0400
Subject: RFR: 8202230: Provide accessors for JNIHandles storage objects
In-Reply-To: <5910FB44-4D8C-4127-823E-DDB6ED4275CF@oracle.com>
References: <5910FB44-4D8C-4127-823E-DDB6ED4275CF@oracle.com>
Message-ID: <abfb8c42-9c2e-751d-34f4-85b80c7e7089@oracle.com>
Looks good.
Coleen
On 4/25/18 5:09 PM, Kim Barrett wrote:
> Please review this addition to JNIHandles, providing access to the
> OopStorage objects used to manage the global and weak global handles.
> The accessors assert the storage objects have been allocated.
>
> Also changed direct uses of the storage object variables to instead
> use the new accessors, to get the initialization asserts during
> development.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8202230
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8202230/open.00/
>
> Testing:
> {jdk,hs}-tier{1,2,3} for all Oracle platforms.
>
From kim.barrett at oracle.com Wed Apr 25 21:42:10 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 25 Apr 2018 17:42:10 -0400
Subject: RFR (XXS) 8202164: Remove some unneeded BoolObjectClosure*
is_alive parameters
In-Reply-To: <5ec5a26b-4b52-2f95-0b54-3476f43c1ffe@oracle.com>
References: <60fb0500-7b14-6fa7-624c-60af670d3d13@oracle.com>
<B0FE2EF5-DA0E-45BC-B557-3075B7D60380@oracle.com>
<5ec5a26b-4b52-2f95-0b54-3476f43c1ffe@oracle.com>
Message-ID: <7C234F6F-D6AE-4233-84B7-E71F4AB989D4@oracle.com>
> On Apr 24, 2018, at 11:01 AM, coleen.phillimore at oracle.com wrote:
>> src/hotspot/share/code/nmethod.cpp
>> 1039 flush_dependencies(/*delete_immediately*/false);
>>
>> The preceding comment needs to be updated; there's no longer a closure
>> involved.
>
> I thought I'd gotten them all. I changed the comment to this. There's a more thorough comment in flush_dependencies that explains why.
>
> // If this work is being done during a GC, defer deleting dependencies from the
> // InstanceKlass.
s/If/Since/
Otherwise, looks good. No need for another webrev for the comment changes.
From kim.barrett at oracle.com Wed Apr 25 21:42:37 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 25 Apr 2018 17:42:37 -0400
Subject: RFR: 8202230: Provide accessors for JNIHandles storage objects
In-Reply-To: <abfb8c42-9c2e-751d-34f4-85b80c7e7089@oracle.com>
References: <5910FB44-4D8C-4127-823E-DDB6ED4275CF@oracle.com>
<abfb8c42-9c2e-751d-34f4-85b80c7e7089@oracle.com>
Message-ID: <77F50D65-6814-4247-8385-5686B9720708@oracle.com>
> On Apr 25, 2018, at 5:34 PM, coleen.phillimore at oracle.com wrote:
>
> Looks good.
> Coleen
Thanks.
> On 4/25/18 5:09 PM, Kim Barrett wrote:
>> Please review this addition to JNIHandles, providing access to the
>> OopStorage objects used to manage the global and weak global handles.
>> The accessors assert the storage objects have been allocated.
>>
>> Also changed direct uses of the storage object variables to instead
>> use the new accessors, to get the initialization asserts during
>> development.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8202230
>>
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8202230/open.00/
>>
>> Testing:
>> {jdk,hs}-tier{1,2,3} for all Oracle platforms.
From coleen.phillimore at oracle.com Wed Apr 25 21:44:35 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 25 Apr 2018 17:44:35 -0400
Subject: RFR (XXS) 8202164: Remove some unneeded BoolObjectClosure*
is_alive parameters
In-Reply-To: <7C234F6F-D6AE-4233-84B7-E71F4AB989D4@oracle.com>
References: <60fb0500-7b14-6fa7-624c-60af670d3d13@oracle.com>
<B0FE2EF5-DA0E-45BC-B557-3075B7D60380@oracle.com>
<5ec5a26b-4b52-2f95-0b54-3476f43c1ffe@oracle.com>
<7C234F6F-D6AE-4233-84B7-E71F4AB989D4@oracle.com>
Message-ID: <712fb833-4fe6-8e30-871f-cb200167d619@oracle.com>
On 4/25/18 5:42 PM, Kim Barrett wrote:
>> On Apr 24, 2018, at 11:01 AM, coleen.phillimore at oracle.com wrote:
>>> src/hotspot/share/code/nmethod.cpp
>>> 1039 flush_dependencies(/*delete_immediately*/false);
>>>
>>> The preceding comment needs to be updated; there's no longer a closure
>>> involved.
>> I thought I'd gotten them all. I changed the comment to this. There's a more thorough comment in flush_dependencies that explains why.
>>
>> // If this work is being done during a GC, defer deleting dependencies from the
>> // InstanceKlass.
> s/If/Since/
>
> Otherwise, looks good. No need for another webrev for the comment changes.
Thanks!
Coleen
>
From david.holmes at oracle.com Thu Apr 26 04:12:14 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Apr 2018 14:12:14 +1000
Subject: (M) RFR: 8200167: Validate more special case invocations
In-Reply-To: <27391c2a-fd5c-8133-8e31-b8b45db157ce@oracle.com>
References: <27391c2a-fd5c-8133-8e31-b8b45db157ce@oracle.com>
Message-ID: <a943a81b-e2da-57f2-92bd-1ef3d6fc7f72@oracle.com>
Revised webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev.v2/
Karen formulated an additional test scenario invoking Object methods
through an interface reference, which when turned into a new testcase
demonstrated that the receiver typecheck was also missing in that case
for Methodhandle's from findSpecial.
Again Vladimir Ivanov formulated the fix for this. Thanks Vladimir!
Summary of changes from original webrev:
- We introduce a new version of DirectMethodHandle.preparedlambdaForm
that takes the caller class as a parameter, and that class is checked
for being an interface (not the method's declaring class) to trigger the
switch to LF_SPECIAL_IFC. (This obviously addresses one problem with
invoking Object methods - as Object is not an interface - but by itself
did not fix the problem.)
- We introduce a new LambdaForm kind, DIRECT_INVOKE_SPECIAL_IFC, which
we use when dealing with LF_INVSPECIAL_IFC. (This was the key in
ensuring the receiver typecheck via Special.checkReceiver remained in
the generated code.)
- In the test we:
- introduce a new invokeDirect testcase for Object.toString(), but we
need to do that via a modified jcod file (as javac generates an
invokevirtual)
- introduce the new invokeSpecialObjectMH(I2 i) call for the MH case.
Thanks,
David
On 17/04/2018 6:48 PM, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200167
> webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev/
>
> Credit to John Rose and Vladimir Ivanov for the form of the MH fix; and
> to Tobias Hartmann for the C1 fix. Their help was very much appreciated
> (and needed!).
>
> tl;dr version: there are some places where badly formed interface method
> calls (which are not detected by the verifier) were missing runtime
> checks on the type of the receiver. Similar issues have been fixed in
> the past and this was a remaining hole in relation to invokespecial
> semantics and interface calls via MethodHandles. It also turned out
> there was an issue in C1 that affected direct invokespecial calls.
>
> Description of changes:
>
> - src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java
>
> Added a new form LF_INVSPECIAL_IFC for invokespecial of interface methods.
>
> - src/java.base/share/classes/java/lang/invoke/MethodHandles.java
>
> Renamed callerClass parameter to boundCallerClass, where it originates
> from findBoundCallerClass. The name "callerClass" is misleading because
> most of the time it is NULL!
>
> In getDirectMethodCommon, pass the actual caller class (lookupClass) to
> DirectMethodHandle.make. And correct the comment about restrictReceiver.
>
> - src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
>
> DirectMethodHandle.make now takes a callerClass parameter (which may be
> null).
>
> DirectMethodHandle make "receiver" parameter is renamed "refc" as it is
> not the receiver (it's the resolved type of the method holder ie REFC).
>
> The Special subclass now takes a "checkClass" parameter which is either
> refc, or callerClass. This is what we will check the receiver against.
>
> In preparedLambdaForm we switch from LF_INVSPECIAL to LF_INVSPECIAL_IFC
> if the target method is in an interface.
>
> In makePreparedLambdaForm we augment the needsReceiverCheck test to
> include LF_INVSPECIAL_IFC. (So we will not be doing a new receiver type
> check on all invokespecials, just those involving interface methods.)
>
> Added DMH.checkReceiver which is overridden by both the Special and
> Interface subclasses.
>
> - src/hotspot/share/c1/c1_Canonicalizer.cpp
>
> Don't optimize away the checkcast when it is an invokespecial receiver
> check.
>
> - test/jdk/java/lang/invoke/SpecialInterfaceCall.java
>
> (I've moved this test back and forth between hotspot/runtime and
> j.l.invoke as it spans direct calls and MH calls. But I think on balance
> it lands better here.)
>
> The test sets up direct interface method calls for which invokespecial
> is generated by javac, and similarly it creates MethodHandles with
> invokespecial semantics. The should-not-throw cases are trivial. The
> should-throw cases involve MH wizardry.
>
> The test is broken into three parts to check the behaviour on first use
> (when the method has to be initially resolved); on second use (to test
> we don't use the cpcache in a way that is invalid); and again after
> forcing JIT compilation of the calls.
>
> The test is run 5 times to exercise the interpreter (yes the multiple
> runs internal to the test are redundant in this case, but it's much
> simpler to just run it all than try to work out what needs to be run);
> the three variants of using C1, plus a C2 only run.
>
> ---
>
> Testing:
> ? - the new test of course
> ? - hotspot/runtime/*
> ? - hotspot/compiler/jsr292
> ? - jdk/java/lang/invoke
>
> ? - hs tiers 1 and 2
> ? - jdk tiers 1, 2 and 3
>
> Plus some related closed tests.
>
> Thanks,
> David
> -----
From kim.barrett at oracle.com Thu Apr 26 04:36:44 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 26 Apr 2018 00:36:44 -0400
Subject: RFR: 8202082: Remove explicit CMS checks in
CardTableBarrierSetAssembler
In-Reply-To: <5AE08864.4070802@oracle.com>
References: <5AD9FC94.70607@oracle.com>
<6A476A6A-47BB-4141-980E-DB98D9BAD405@oracle.com>
<67ac1742-640e-f011-f371-cf53b782e969@oracle.com>
<60EA410E-E1FE-4A54-95CA-E3F11CC9B168@oracle.com>
<9c283f66-326a-d640-432d-b6c573802b5e@oracle.com>
<1964D307-E283-47CA-96C6-7AF577F96EC4@oracle.com>
<5AE08864.4070802@oracle.com>
Message-ID: <B2AF6F60-26C3-4371-A1BE-E9ECF1A57AAF@oracle.com>
> On Apr 25, 2018, at 9:53 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>
> Hi Kim,
>
> Okay, it looks like we kind of agree that this is a step in the right direction for now. Thank you for the review.
>
> Here is my final webrev with "disp" not refetched (and renamed to card_table_addr):
> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.01/
>
> Incremental:
> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.00_01/
Only partially addressed my comment:
src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
105 intptr_t card_table_addr = (intptr_t)ctbs->card_table()->byte_map_base();
s/ctbs->card_table()/ct/
But wait, that version shouldn?t even compile?
107 card_addr = Address(noreg, obj, Address::times_1, disp);
still refers to ?disp?.
card_table_add is better than disp.
From erik.osterlund at oracle.com Thu Apr 26 06:52:48 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Thu, 26 Apr 2018 08:52:48 +0200
Subject: RFR: 8202082: Remove explicit CMS checks in
CardTableBarrierSetAssembler
In-Reply-To: <B2AF6F60-26C3-4371-A1BE-E9ECF1A57AAF@oracle.com>
References: <5AD9FC94.70607@oracle.com>
<6A476A6A-47BB-4141-980E-DB98D9BAD405@oracle.com>
<67ac1742-640e-f011-f371-cf53b782e969@oracle.com>
<60EA410E-E1FE-4A54-95CA-E3F11CC9B168@oracle.com>
<9c283f66-326a-d640-432d-b6c573802b5e@oracle.com>
<1964D307-E283-47CA-96C6-7AF577F96EC4@oracle.com>
<5AE08864.4070802@oracle.com>
<B2AF6F60-26C3-4371-A1BE-E9ECF1A57AAF@oracle.com>
Message-ID: <b96d0e61-094c-cf0c-56ca-9239a980240c@oracle.com>
Hi Kim,
On 2018-04-26 06:36, Kim Barrett wrote:
>> On Apr 25, 2018, at 9:53 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>>
>> Hi Kim,
>>
>> Okay, it looks like we kind of agree that this is a step in the right direction for now. Thank you for the review.
>>
>> Here is my final webrev with "disp" not refetched (and renamed to card_table_addr):
>> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.01/
>>
>> Incremental:
>> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.00_01/
> Only partially addressed my comment:
> src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
> 105 intptr_t card_table_addr = (intptr_t)ctbs->card_table()->byte_map_base();
>
> s/ctbs->card_table()/ct/
>
> But wait, that version shouldn?t even compile?
> 107 card_addr = Address(noreg, obj, Address::times_1, disp);
> still refers to ?disp?.
Fixed.
> card_table_add is better than disp.
Actually now that I think of it, I decided the name should be
byte_map_base instead. That is indeed what the comments already refer to
and what other platforms consistently call this variable. And it is not
a real address.
Incremental:
http://cr.openjdk.java.net/~eosterlund/8202082/webrev.01_02/
Full:
http://cr.openjdk.java.net/~eosterlund/8202082/webrev.02/
Thanks,
/Erik
From robbin.ehn at oracle.com Thu Apr 26 07:38:02 2018
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Thu, 26 Apr 2018 09:38:02 +0200
Subject: RFR(L): Low latency hashtable for read-mostly scenarios
Message-ID: <1cc85bdc-98cb-115d-a904-4cf1c94259b2@oracle.com>
Hi all, please review.
The lower latency of the new gcs have higher demands on runtime data-structure
in terms of latency. This is a concurrent hashtable using the global-counter
(8195099).
Webrev:
http://cr.openjdk.java.net/~rehn/8195098/v0/webrev/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8195098
* Readers never blocks or spins.
* Inserts do CAS from a read-side, need to re-CAS during re-size/deletion in
targeted bucket or insert collision. (inserts are conceptually a reader)
* Deletes locks the targeted bucket, all other buckets are free for operations.
* Re-size locks one bucket at the time, all other buckets are free for operations.
It does concurrent re-size by doubling size and use one more bit from hash.
That means a bucket in the old table contains nodes to either one of two buckets
in the new table. Each node in the chain is sorted into one of the two buckets
with concurrent readers. Shrinking just take two node chains and put them
together in the corresponding bucket. To keep track of what is visible to the
concurrent readers it's uses a global-counter, needed during re-size and for
deletes.
A gtest is provided which passes on our platforms, we also have a prototype of
the stringtable using this which passes tier 1-5 on our platforms.
Various people have pre-reviewed various parts, thanks! And a special thanks to
Coleen for a lot of reviewing!
Thanks, Robbin
From magnus.ihse.bursie at oracle.com Thu Apr 26 09:45:02 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 26 Apr 2018 11:45:02 +0200
Subject: RFR(XL): 8199712: Flight Recorder
In-Reply-To: <5AE0612F.8060200@oracle.com>
References: <5AE0612F.8060200@oracle.com>
Message-ID: <0e2f481f-0c7c-5dfa-c37b-1b453b3b2d8d@oracle.com>
On 2018-04-25 13:06, Erik Gahlin wrote:
> Greetings,
>
> Could I have a review of 8199712: Flight Recorder
>
> As mentioned in the preview [1] the tracing backend has been removed.
> Event metadata has been consolidated into a single XML file and event
> classes are now generated by GenerateJfrFiles.java.
>
> Tests have been run on Linux-x64, Windows-x64 and MaxOSX-x64.
>
> For details about the feature, see the JEP:
> https://bugs.openjdk.java.net/browse/JDK-8193393
>
> Webrev:
> http://cr.openjdk.java.net/~egahlin/8199712.0/
Hi Erik,
When posting build changes (files in "make/*"), please always include
build-dev. Thanks! :-)
This review is for build changes only.
* make/RunTestsPrebuiltSpec.gmk: This file has only a copyright year
change. It can be reverted.
* make/copy/Copy-jdk.jfr.gmk:
COPY_HOTSPOT_TRACE_FILES should be renamed to something like
COPY_JFR_METADATA.
The second part is better off rewritten using SetupCopyFiles.
Something like this, written on-the-fly, so might not work. (Email me
privately if it does not work and you need help.)
JFR_CONF_DIR := $(TOPDIR)/src/jdk.jfr/share/conf/jfr
$(eval $(call SetupCopyFiles, COPY_JFR_CONF, \
? DEST := $(LIB_DST_DIR)/jfr, \
? FILES := $(wildcard $(JFR_CONF_DIR)/*.jfc), \
? FLATTEN := true, \
))
TARGETS += $(COPY_JFR_CONF)
* make/autoconf/hotspot.m4:
It's a bit unfortunate with the --enable-jfr option. Ideally, this
should be handled only as a JVM feature (--with-jvm-features=jfr). Try
this piece of code instead: (Not tested, but should work.)
diff --git a/make/autoconf/hotspot.m4 b/make/autoconf/hotspot.m4
--- a/make/autoconf/hotspot.m4
+++ b/make/autoconf/hotspot.m4
@@ -26,7 +26,7 @@
?# All valid JVM features, regardless of platform
?VALID_JVM_FEATURES="compiler1 compiler2 zero minimal dtrace jvmti jvmci \
???? graal vm-structs jni-check services management all-gcs nmt cds \
-??? static-build link-time-opt aot"
+??? static-build link-time-opt aot jfr"
?# All valid JVM variants
?VALID_JVM_VARIANTS="server client minimal core zero custom"
@@ -313,6 +313,11 @@
???? AC_MSG_ERROR([Specified JVM feature 'vm-structs' requires feature
'all-gcs'])
?? fi
+? # Enable JFR by default, except on linux-sparcv9 and on minimal.
+? if test "x$OPENJDK_TARGET_OS" != xlinux || test
"x$OPENJDK_TARGET_CPU" != xsparcv9; then
+??? NON_MINIMAL_FEATURES="$NON_MINIMAL_FEATURES jfr"
+? fi
+
?? # Turn on additional features based on other parts of configure
?? if test "x$INCLUDE_DTRACE" = "xtrue"; then
???? JVM_FEATURES="$JVM_FEATURES dtrace"
Otherwise, build changes look good!
/Magnus
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8199712
>
> [1]
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031359.html
>
> Thanks
> Erik and Markus
From per.liden at oracle.com Thu Apr 26 10:38:04 2018
From: per.liden at oracle.com (Per Liden)
Date: Thu, 26 Apr 2018 12:38:04 +0200
Subject: RFR: 8201543: Modularize C1 GC barriers
In-Reply-To: <5AD0C89E.7050807@oracle.com>
References: <5AD0C89E.7050807@oracle.com>
Message-ID: <84386dca-b882-cfba-e21b-765523d93f75@oracle.com>
Hi Erik,
On 04/13/2018 05:11 PM, Erik ?sterlund wrote:
> Hi,
>
> The GC barriers for C1 are not as modular as they could be. It currently
> uses switch statements to check which GC barrier set is being used, and
> calls one or another barrier based on that, in a way that it can only be
> used for write barriers.
>
> The solution I propose is to add the same facilities that have been
> added in runtime and the interpreter already: a barrier set backend for
> C1. I call it BarrierSetC1, and it helps us generate decorated accesses
> that give the GC control over the details how to generate this access.
> It recognizes the same decorators (accessDecorators.hpp) that the other
> parts of the VM recognize. Each concrete barrier set has its own
> backend. For now, these are CardTableBarrierSetC1 and G1BarrierSetC1,
> but this should pave way for upcoming concurrently compacting GCs as well.
>
> Two decorators were added for C1 specifically (found in c1_Decorators.hpp):
> C1_NEEDS_PATCHING for accesses where the index is not yet load because
> the class has yet to be loaded, and
> C1_MASK_BOOLEAN for accesses that need to mask untrusted boolean values.
>
> LIRGenerator calls a wrapper called access_store_at, access_load_at, etc
> (there are variants for cpmxchg, xchg and atomic add as well).
> The access call calls straight into the BarrierSetC1 hierarchy using
> virtual calls. It is structured in a way very similar to
> BarrierSetAssembler.
>
> BarrierSetC1 can also be called during initialization to generate stubs
> and runtime methods required by C1. For G1BarrierSetC1, this results in
> calling the BarrierSetAssembler for the platform specific code. This
> way, the BarrierSetC1 hierarchy has been carefully kept in shared code,
> and the switch statements for generating G1 code have been removed. Some
> code that used to be platform specific (like unsafe get/set and array
> store) have been broken out to shared code, with the actual platform
> specific details (some register allocation for store check and atomics)
> broken out to platform specific methods. This way, calls to access are
> kept in platform specific code.
>
> As usual, big thanks go to Martin Doerr for helping out with S390 and
> PPC, and Roman for taking care of AArch64.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8201543
>
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.00/
Looks good overall, just some minor comments.
src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.hpp
-------------------------------------------------------
59 void gen_g1_pre_barrier_stub(LIR_Assembler* ce, G1PreBarrierStub*
stub);
60 void gen_g1_post_barrier_stub(LIR_Assembler* ce, G1PostBarrierStub*
stub);
It seems superfluous to have "g1" in the function names given the context ;)
src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
-------------------------------------------------------
The C1-related includes and functions should be under #ifdef COMPILER1.
src/hotspot/share/gc/shared/c1/barrierSetC1.hpp
-----------------------------------------------
96 CodeEmitInfo*& patch_info() { return _patch_info; }
97 CodeEmitInfo*& access_emit_info() { return _access_emit_info; }
Should we make this "patch_info" and "access_info"? Or maybe
"patch_emit_info" and "access_emit_info"? I think I prefer the former.
122 virtual LIR_Opr atomic_cmpxchg_resolved(LIRAccess& access,
LIRItem& cmp_value, LIRItem& new_value);
123
124 virtual LIR_Opr atomic_xchg_resolved(LIRAccess& access, LIRItem&
value);
...
133 virtual LIR_Opr atomic_xchg(LIRAccess& access, LIRItem& value);
The methods above are missing an "_at" in their name.
src/hotspot/share/gc/shared/c1/barrierSetC1.cpp
-----------------------------------------------
73 void BarrierSetC1::store_at(LIRAccess& access,LIR_Opr value) {
Missing space in argument list.
src/hotspot/share/runtime/sharedRuntime.cpp
-------------------------------------------
The only change in this file is a single (unnecessary) line delete.
cheers,
Per
>
> Thanks,
> /Erik
From per.liden at oracle.com Thu Apr 26 10:44:19 2018
From: per.liden at oracle.com (Per Liden)
Date: Thu, 26 Apr 2018 12:44:19 +0200
Subject: RFR: 8201543: Modularize C1 GC barriers
In-Reply-To: <84386dca-b882-cfba-e21b-765523d93f75@oracle.com>
References: <5AD0C89E.7050807@oracle.com>
<84386dca-b882-cfba-e21b-765523d93f75@oracle.com>
Message-ID: <195242d4-8f68-517c-7da7-c57912cec64c@oracle.com>
On 04/26/2018 12:38 PM, Per Liden wrote:
[...]
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.00/
>
>
> Looks good overall, just some minor comments.
>
>
> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.hpp
> -------------------------------------------------------
> 59?? void gen_g1_pre_barrier_stub(LIR_Assembler* ce, G1PreBarrierStub*
> stub);
> 60?? void gen_g1_post_barrier_stub(LIR_Assembler* ce, G1PostBarrierStub*
> stub);
>
> It seems superfluous to have "g1" in the function names given the
> context ;)
>
>
> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
> -------------------------------------------------------
> The C1-related includes and functions should be under #ifdef COMPILER1.
>
>
> src/hotspot/share/gc/shared/c1/barrierSetC1.hpp
> -----------------------------------------------
>
> ?96?? CodeEmitInfo*& patch_info()????????? { return _patch_info; }
> ?97?? CodeEmitInfo*& access_emit_info()??? { return _access_emit_info; }
>
> Should we make this "patch_info" and "access_info"? Or maybe
> "patch_emit_info" and "access_emit_info"? I think I prefer the former.
>
>
> 122?? virtual LIR_Opr atomic_cmpxchg_resolved(LIRAccess& access,
> LIRItem& cmp_value, LIRItem& new_value);
> 123
> 124?? virtual LIR_Opr atomic_xchg_resolved(LIRAccess& access, LIRItem&
> value);
> ...
> 133?? virtual LIR_Opr atomic_xchg(LIRAccess& access, LIRItem& value);
>
> The methods above are missing an "_at" in their name.
>
>
> src/hotspot/share/gc/shared/c1/barrierSetC1.cpp
> -----------------------------------------------
>
> ?73 void BarrierSetC1::store_at(LIRAccess& access,LIR_Opr value) {
>
> Missing space in argument list.
>
>
> src/hotspot/share/runtime/sharedRuntime.cpp
> -------------------------------------------
> The only change in this file is a single (unnecessary) line delete.
Btw, I don't need to see a new webrev.
/Per
From swatibits14 at gmail.com Thu Apr 26 12:20:21 2018
From: swatibits14 at gmail.com (Swati Sharma)
Date: Thu, 26 Apr 2018 17:50:21 +0530
Subject: UseNUMA membind Issue in openJDK
Message-ID: <CAN_ztC2OkiX33hY5N-=ebhJRLRr7fnzOXi=8o+-Jm4gWVFX13Q@mail.gmail.com>
Hi Everyone,
I work at AMD and this is my first patch as a new member of openJDK
community.
I have found some issue while running specjbb2015 composite workload with
the flag -XX:+UseNUMA. It seems that JVM does not allocate memory according
to the explicit node binding done using "numactl --membind".
E.g. If bound to a single memory node, JVM divides the whole heap based on
the total number of numa nodes available on the system which creates more
logical groups(lgrps) than required which cannot be used except the one.
The following examples will explain clearly :
(Note : Collected GC logs with
-Xlog:gc*=debug:file=gc.log:time,uptimemillis)
1) Allocating a heap of 22GB for single node divides the whole heap in 8
lgrp(Actual no of Nodes are 8)
$numactl --cpunodebind=0 --membind=0 java -Xmx24g -Xms24g -Xmn22g
-XX:+UseNUMA <composite_application>
eden space 22511616K(22GB), 12% used
lgrp 0 space 2813952K, 100% used lgrp 1 space
2813952K, 0% used lgrp 2 space 2813952K, 0% used
lgrp 3 space 2813952K, 0% used lgrp 4 space
2813952K, 0% used lgrp 5 space 2813952K, 0% used
lgrp 6 space 2813952K, 0% used lgrp 7 space
2813952K, 0% used
Observation : Instead of disabling UseNUMA for single node binding JVM
divides the memory in 8 lgrps and allocates memory always on the bounded
node hence in eden space allocation never happens more than 12%.
2) Another case of binding to node 0 and 7 results in dividing the heap in
8lgrp
$numactl --cpunodebind=0,7 ?membind=0,7 java -Xms50g -Xmx50g -Xmn45g
-XX:+UseNUMA <composite_application>
eden space 46718976K, 6% used
lgrp 0 space 5838848K, 14% used lgrp 1 space 5838848K,
0% used lgrp 2 space 5838848K, 0% used
lgrp 3 space 5838848K, 0% used lgrp 4 space
5838848K, 0% used lgrp 5 space 5838848K, 0%
used
lgrp 6 space 5838848K, 0% used lgrp 7 space
5847040K, 35% used
Observation : Similar to first case allocation happens only on 0th and 7th
node and rest of the lgrps never gets used.
After applying the patch, JVM divides the given heap size according to the
bounded memory nodes only.
1) Binding to single node disables UseNUMA
eden space 46718976K(45GB), 99% used
Observation : UseNUMA gets disabled hence no lgrp creation and the whole
heap allocation happens on the bounded node.
2) Binding to node 0 and 7
$ numactl --cpunodebind=0,7 ?membind=0,7 java -Xms50g -Xmx50g -Xmn45g
-XX:+UseNUMA <composite_application>
eden space 46718976K(45GB), 99% used
lgrp 0 space 23359488K(23.5GB), 100% used lgrp 7 space
23359488K(23.5GB), 99% used
Observation : Only two lgrps gets created and heap size gets divided
equally in both nodes.
If there is no binding, then JVM will divide the whole heap based on the
number of NUMA nodes available on the system.
The following patch fixes the issue(attached also).
Please review and let me know your comments.
Regression testing using jtreg (make -J=1 run-test-tier1 run-test-tier2)
didn't show any new failures.
===============================PATCH========================================
diff --git a/src/hotspot/os/linux/os_linux.cpp
b/src/hotspot/os/linux/os_linux.cpp
--- a/src/hotspot/os/linux/os_linux.cpp
+++ b/src/hotspot/os/linux/os_linux.cpp
@@ -2832,8 +2832,10 @@
// Map all node ids in which is possible to allocate memory. Also nodes
are
// not always consecutively available, i.e. available from 0 to the
highest
// node number.
+ // If the nodes have been bound explicitly using numactl membind, then
+ // allocate memory from those nodes only.
for (size_t node = 0; node <= highest_node_number; node++) {
- if (Linux::isnode_in_configured_nodes(node)) {
+ if (Linux::isnode_in_bounded_nodes(node)) {
ids[i++] = node;
}
}
@@ -2930,6 +2932,10 @@
libnuma_dlsym(handle,
"numa_bitmask_isbitset")));
set_numa_distance(CAST_TO_FN_PTR(numa_distance_func_t,
libnuma_dlsym(handle,
"numa_distance")));
+ set_numa_set_membind(CAST_TO_FN_PTR(numa_set_membind_func_t,
+ libnuma_dlsym(handle,
"numa_set_membind")));
+ set_numa_get_membind(CAST_TO_FN_PTR(numa_get_membind_func_t,
+ libnuma_v2_dlsym(handle,
"numa_get_membind")));
if (numa_available() != -1) {
set_numa_all_nodes((unsigned long*)libnuma_dlsym(handle,
"numa_all_nodes"));
@@ -3054,6 +3060,8 @@
os::Linux::numa_set_bind_policy_func_t os::Linux::_numa_set_bind_policy;
os::Linux::numa_bitmask_isbitset_func_t os::Linux::_numa_bitmask_isbitset;
os::Linux::numa_distance_func_t os::Linux::_numa_distance;
+os::Linux::numa_set_membind_func_t os::Linux::_numa_set_membind;
+os::Linux::numa_get_membind_func_t os::Linux::_numa_get_membind;
unsigned long* os::Linux::_numa_all_nodes;
struct bitmask* os::Linux::_numa_all_nodes_ptr;
struct bitmask* os::Linux::_numa_nodes_ptr;
@@ -4962,8 +4970,9 @@
if (!Linux::libnuma_init()) {
UseNUMA = false;
} else {
- if ((Linux::numa_max_node() < 1)) {
- // There's only one node(they start from 0), disable NUMA.
+ if ((Linux::numa_max_node() < 1) || Linux::issingle_node_bound()) {
+ // If there's only one node(they start from 0) or if the process
+ // is bound explicitly to a single node using membind, disable
NUMA.
UseNUMA = false;
}
}
diff --git a/src/hotspot/os/linux/os_linux.hpp
b/src/hotspot/os/linux/os_linux.hpp
--- a/src/hotspot/os/linux/os_linux.hpp
+++ b/src/hotspot/os/linux/os_linux.hpp
@@ -228,6 +228,8 @@
typedef int (*numa_tonode_memory_func_t)(void *start, size_t size, int
node);
typedef void (*numa_interleave_memory_func_t)(void *start, size_t size,
unsigned long *nodemask);
typedef void (*numa_interleave_memory_v2_func_t)(void *start, size_t
size, struct bitmask* mask);
+ typedef void (*numa_set_membind_func_t)(struct bitmask *mask);
+ typedef struct bitmask* (*numa_get_membind_func_t)(void);
typedef void (*numa_set_bind_policy_func_t)(int policy);
typedef int (*numa_bitmask_isbitset_func_t)(struct bitmask *bmp,
unsigned int n);
@@ -244,6 +246,8 @@
static numa_set_bind_policy_func_t _numa_set_bind_policy;
static numa_bitmask_isbitset_func_t _numa_bitmask_isbitset;
static numa_distance_func_t _numa_distance;
+ static numa_set_membind_func_t _numa_set_membind;
+ static numa_get_membind_func_t _numa_get_membind;
static unsigned long* _numa_all_nodes;
static struct bitmask* _numa_all_nodes_ptr;
static struct bitmask* _numa_nodes_ptr;
@@ -259,6 +263,8 @@
static void set_numa_set_bind_policy(numa_set_bind_policy_func_t func) {
_numa_set_bind_policy = func; }
static void set_numa_bitmask_isbitset(numa_bitmask_isbitset_func_t func)
{ _numa_bitmask_isbitset = func; }
static void set_numa_distance(numa_distance_func_t func) {
_numa_distance = func; }
+ static void set_numa_set_membind(numa_set_membind_func_t func) {
_numa_set_membind = func; }
+ static void set_numa_get_membind(numa_get_membind_func_t func) {
_numa_get_membind = func; }
static void set_numa_all_nodes(unsigned long* ptr) { _numa_all_nodes =
ptr; }
static void set_numa_all_nodes_ptr(struct bitmask **ptr) {
_numa_all_nodes_ptr = (ptr == NULL ? NULL : *ptr); }
static void set_numa_nodes_ptr(struct bitmask **ptr) { _numa_nodes_ptr =
(ptr == NULL ? NULL : *ptr); }
@@ -320,6 +326,34 @@
} else
return 0;
}
+ // Check if node in bounded nodes
+ static bool isnode_in_bounded_nodes(int node) {
+ struct bitmask* bmp = _numa_get_membind != NULL ? _numa_get_membind()
: NULL;
+ if (bmp != NULL && _numa_bitmask_isbitset != NULL &&
_numa_bitmask_isbitset(bmp, node)) {
+ return true;
+ } else
+ return false;
+ }
+ // Check if a single node is bound
+ static bool issingle_node_bound() {
+ struct bitmask* bmp = _numa_get_membind != NULL ? _numa_get_membind()
: NULL;
+ if(bmp == NULL) return false;
+ int issingle = 0;
+ // System can have more than 64 nodes so check in all the elements of
+ // unsigned long array
+ for (unsigned long i = 0; i < (bmp->size / (8 * sizeof(unsigned
long))); i++) {
+ if (bmp->maskp != NULL && (((bmp->maskp[i]) & (((bmp->maskp[i])) -
1)) == 0)) {
+ issingle++;
+ } else if (bmp->maskp[i] == 0) {
+ continue;
+ } else {
+ return false;
+ }
+ }
+ if (issingle == 1)
+ return true;
+ return false;
+ }
};
#endif // OS_LINUX_VM_OS_LINUX_HPP
diff --git a/src/hotspot/share/runtime/os.hpp
b/src/hotspot/share/runtime/os.hpp
--- a/src/hotspot/share/runtime/os.hpp
+++ b/src/hotspot/share/runtime/os.hpp
@@ -81,6 +81,10 @@
CriticalPriority = 11 // Critical thread priority
};
+extern "C" struct bitmask {
+ unsigned long size; /* number of bits in the map */
+ unsigned long *maskp;
+};
// Executable parameter flag for os::commit_memory() and
// os::commit_memory_or_exit().
const bool ExecMem = true;
=============================================================================
Thanks,
Swati
From erik.osterlund at oracle.com Thu Apr 26 12:33:46 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Thu, 26 Apr 2018 14:33:46 +0200
Subject: RFR: 8201543: Modularize C1 GC barriers
In-Reply-To: <195242d4-8f68-517c-7da7-c57912cec64c@oracle.com>
References: <5AD0C89E.7050807@oracle.com>
<84386dca-b882-cfba-e21b-765523d93f75@oracle.com>
<195242d4-8f68-517c-7da7-c57912cec64c@oracle.com>
Message-ID: <5AE1C72A.9090203@oracle.com>
Hi Per,
Thank you for the review. I have incorporated your suggested improvements.
/Erik
On 2018-04-26 12:44, Per Liden wrote:
> On 04/26/2018 12:38 PM, Per Liden wrote:
> [...]
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~eosterlund/8201543/webrev.00/
>>
>>
>> Looks good overall, just some minor comments.
>>
>>
>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.hpp
>> -------------------------------------------------------
>> 59 void gen_g1_pre_barrier_stub(LIR_Assembler* ce,
>> G1PreBarrierStub* stub);
>> 60 void gen_g1_post_barrier_stub(LIR_Assembler* ce,
>> G1PostBarrierStub* stub);
>>
>> It seems superfluous to have "g1" in the function names given the
>> context ;)
>>
>>
>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp
>> -------------------------------------------------------
>> The C1-related includes and functions should be under #ifdef COMPILER1.
>>
>>
>> src/hotspot/share/gc/shared/c1/barrierSetC1.hpp
>> -----------------------------------------------
>>
>> 96 CodeEmitInfo*& patch_info() { return _patch_info; }
>> 97 CodeEmitInfo*& access_emit_info() { return
>> _access_emit_info; }
>>
>> Should we make this "patch_info" and "access_info"? Or maybe
>> "patch_emit_info" and "access_emit_info"? I think I prefer the former.
>>
>>
>> 122 virtual LIR_Opr atomic_cmpxchg_resolved(LIRAccess& access,
>> LIRItem& cmp_value, LIRItem& new_value);
>> 123
>> 124 virtual LIR_Opr atomic_xchg_resolved(LIRAccess& access,
>> LIRItem& value);
>> ...
>> 133 virtual LIR_Opr atomic_xchg(LIRAccess& access, LIRItem& value);
>>
>> The methods above are missing an "_at" in their name.
>>
>>
>> src/hotspot/share/gc/shared/c1/barrierSetC1.cpp
>> -----------------------------------------------
>>
>> 73 void BarrierSetC1::store_at(LIRAccess& access,LIR_Opr value) {
>>
>> Missing space in argument list.
>>
>>
>> src/hotspot/share/runtime/sharedRuntime.cpp
>> -------------------------------------------
>> The only change in this file is a single (unnecessary) line delete.
>
>
> Btw, I don't need to see a new webrev.
>
> /Per
From david.holmes at oracle.com Thu Apr 26 12:40:02 2018
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Apr 2018 22:40:02 +1000
Subject: UseNUMA membind Issue in openJDK
In-Reply-To: <CAN_ztC2OkiX33hY5N-=ebhJRLRr7fnzOXi=8o+-Jm4gWVFX13Q@mail.gmail.com>
References: <CAN_ztC2OkiX33hY5N-=ebhJRLRr7fnzOXi=8o+-Jm4gWVFX13Q@mail.gmail.com>
Message-ID: <9a0310b7-2880-db69-cfbc-7abba844ecbf@oracle.com>
Hi Swati,
On 26/04/2018 10:20 PM, Swati Sharma wrote:
> Hi Everyone,
>
> I work at AMD and this is my first patch as a new member of openJDK
> community.
Welcome!
I can't comment on the actual NUMA details of the patch (though I can
see what you're doing), but the struct bitmask declaration in os.hpp
should be localized in os_linux.hpp as far as I can see, as it's only
needed internally in the Linux code.
Thanks,
David
-----
> I have found some issue while running specjbb2015 composite workload with
> the flag -XX:+UseNUMA. It seems that JVM does not allocate memory according
> to the explicit node binding done using "numactl --membind".
>
> E.g. If bound to a single memory node, JVM divides the whole heap based on
> the total number of numa nodes available on the system which creates more
> logical groups(lgrps) than required which cannot be used except the one.
>
> The following examples will explain clearly :
> (Note : Collected GC logs with
> -Xlog:gc*=debug:file=gc.log:time,uptimemillis)
> 1) Allocating a heap of 22GB for single node divides the whole heap in 8
> lgrp(Actual no of Nodes are 8)
> $numactl --cpunodebind=0 --membind=0 java -Xmx24g -Xms24g -Xmn22g
> -XX:+UseNUMA <composite_application>
>
> eden space 22511616K(22GB), 12% used
> lgrp 0 space 2813952K, 100% used lgrp 1 space
> 2813952K, 0% used lgrp 2 space 2813952K, 0% used
> lgrp 3 space 2813952K, 0% used lgrp 4 space
> 2813952K, 0% used lgrp 5 space 2813952K, 0% used
> lgrp 6 space 2813952K, 0% used lgrp 7 space
> 2813952K, 0% used
>
> Observation : Instead of disabling UseNUMA for single node binding JVM
> divides the memory in 8 lgrps and allocates memory always on the bounded
> node hence in eden space allocation never happens more than 12%.
>
> 2) Another case of binding to node 0 and 7 results in dividing the heap in
> 8lgrp
> $numactl --cpunodebind=0,7 ?membind=0,7 java -Xms50g -Xmx50g -Xmn45g
> -XX:+UseNUMA <composite_application>
>
> eden space 46718976K, 6% used
> lgrp 0 space 5838848K, 14% used lgrp 1 space 5838848K,
> 0% used lgrp 2 space 5838848K, 0% used
> lgrp 3 space 5838848K, 0% used lgrp 4 space
> 5838848K, 0% used lgrp 5 space 5838848K, 0%
> used
> lgrp 6 space 5838848K, 0% used lgrp 7 space
> 5847040K, 35% used
>
> Observation : Similar to first case allocation happens only on 0th and 7th
> node and rest of the lgrps never gets used.
>
> After applying the patch, JVM divides the given heap size according to the
> bounded memory nodes only.
>
> 1) Binding to single node disables UseNUMA
> eden space 46718976K(45GB), 99% used
>
> Observation : UseNUMA gets disabled hence no lgrp creation and the whole
> heap allocation happens on the bounded node.
>
> 2) Binding to node 0 and 7
> $ numactl --cpunodebind=0,7 ?membind=0,7 java -Xms50g -Xmx50g -Xmn45g
> -XX:+UseNUMA <composite_application>
> eden space 46718976K(45GB), 99% used
> lgrp 0 space 23359488K(23.5GB), 100% used lgrp 7 space
> 23359488K(23.5GB), 99% used
>
> Observation : Only two lgrps gets created and heap size gets divided
> equally in both nodes.
>
> If there is no binding, then JVM will divide the whole heap based on the
> number of NUMA nodes available on the system.
>
> The following patch fixes the issue(attached also).
> Please review and let me know your comments.
>
> Regression testing using jtreg (make -J=1 run-test-tier1 run-test-tier2)
> didn't show any new failures.
>
> ===============================PATCH========================================
> diff --git a/src/hotspot/os/linux/os_linux.cpp
> b/src/hotspot/os/linux/os_linux.cpp
> --- a/src/hotspot/os/linux/os_linux.cpp
> +++ b/src/hotspot/os/linux/os_linux.cpp
> @@ -2832,8 +2832,10 @@
> // Map all node ids in which is possible to allocate memory. Also nodes
> are
> // not always consecutively available, i.e. available from 0 to the
> highest
> // node number.
> + // If the nodes have been bound explicitly using numactl membind, then
> + // allocate memory from those nodes only.
> for (size_t node = 0; node <= highest_node_number; node++) {
> - if (Linux::isnode_in_configured_nodes(node)) {
> + if (Linux::isnode_in_bounded_nodes(node)) {
> ids[i++] = node;
> }
> }
> @@ -2930,6 +2932,10 @@
> libnuma_dlsym(handle,
> "numa_bitmask_isbitset")));
> set_numa_distance(CAST_TO_FN_PTR(numa_distance_func_t,
> libnuma_dlsym(handle,
> "numa_distance")));
> + set_numa_set_membind(CAST_TO_FN_PTR(numa_set_membind_func_t,
> + libnuma_dlsym(handle,
> "numa_set_membind")));
> + set_numa_get_membind(CAST_TO_FN_PTR(numa_get_membind_func_t,
> + libnuma_v2_dlsym(handle,
> "numa_get_membind")));
>
> if (numa_available() != -1) {
> set_numa_all_nodes((unsigned long*)libnuma_dlsym(handle,
> "numa_all_nodes"));
> @@ -3054,6 +3060,8 @@
> os::Linux::numa_set_bind_policy_func_t os::Linux::_numa_set_bind_policy;
> os::Linux::numa_bitmask_isbitset_func_t os::Linux::_numa_bitmask_isbitset;
> os::Linux::numa_distance_func_t os::Linux::_numa_distance;
> +os::Linux::numa_set_membind_func_t os::Linux::_numa_set_membind;
> +os::Linux::numa_get_membind_func_t os::Linux::_numa_get_membind;
> unsigned long* os::Linux::_numa_all_nodes;
> struct bitmask* os::Linux::_numa_all_nodes_ptr;
> struct bitmask* os::Linux::_numa_nodes_ptr;
> @@ -4962,8 +4970,9 @@
> if (!Linux::libnuma_init()) {
> UseNUMA = false;
> } else {
> - if ((Linux::numa_max_node() < 1)) {
> - // There's only one node(they start from 0), disable NUMA.
> + if ((Linux::numa_max_node() < 1) || Linux::issingle_node_bound()) {
> + // If there's only one node(they start from 0) or if the process
> + // is bound explicitly to a single node using membind, disable
> NUMA.
> UseNUMA = false;
> }
> }
> diff --git a/src/hotspot/os/linux/os_linux.hpp
> b/src/hotspot/os/linux/os_linux.hpp
> --- a/src/hotspot/os/linux/os_linux.hpp
> +++ b/src/hotspot/os/linux/os_linux.hpp
> @@ -228,6 +228,8 @@
> typedef int (*numa_tonode_memory_func_t)(void *start, size_t size, int
> node);
> typedef void (*numa_interleave_memory_func_t)(void *start, size_t size,
> unsigned long *nodemask);
> typedef void (*numa_interleave_memory_v2_func_t)(void *start, size_t
> size, struct bitmask* mask);
> + typedef void (*numa_set_membind_func_t)(struct bitmask *mask);
> + typedef struct bitmask* (*numa_get_membind_func_t)(void);
>
> typedef void (*numa_set_bind_policy_func_t)(int policy);
> typedef int (*numa_bitmask_isbitset_func_t)(struct bitmask *bmp,
> unsigned int n);
> @@ -244,6 +246,8 @@
> static numa_set_bind_policy_func_t _numa_set_bind_policy;
> static numa_bitmask_isbitset_func_t _numa_bitmask_isbitset;
> static numa_distance_func_t _numa_distance;
> + static numa_set_membind_func_t _numa_set_membind;
> + static numa_get_membind_func_t _numa_get_membind;
> static unsigned long* _numa_all_nodes;
> static struct bitmask* _numa_all_nodes_ptr;
> static struct bitmask* _numa_nodes_ptr;
> @@ -259,6 +263,8 @@
> static void set_numa_set_bind_policy(numa_set_bind_policy_func_t func) {
> _numa_set_bind_policy = func; }
> static void set_numa_bitmask_isbitset(numa_bitmask_isbitset_func_t func)
> { _numa_bitmask_isbitset = func; }
> static void set_numa_distance(numa_distance_func_t func) {
> _numa_distance = func; }
> + static void set_numa_set_membind(numa_set_membind_func_t func) {
> _numa_set_membind = func; }
> + static void set_numa_get_membind(numa_get_membind_func_t func) {
> _numa_get_membind = func; }
> static void set_numa_all_nodes(unsigned long* ptr) { _numa_all_nodes =
> ptr; }
> static void set_numa_all_nodes_ptr(struct bitmask **ptr) {
> _numa_all_nodes_ptr = (ptr == NULL ? NULL : *ptr); }
> static void set_numa_nodes_ptr(struct bitmask **ptr) { _numa_nodes_ptr =
> (ptr == NULL ? NULL : *ptr); }
> @@ -320,6 +326,34 @@
> } else
> return 0;
> }
> + // Check if node in bounded nodes
> + static bool isnode_in_bounded_nodes(int node) {
> + struct bitmask* bmp = _numa_get_membind != NULL ? _numa_get_membind()
> : NULL;
> + if (bmp != NULL && _numa_bitmask_isbitset != NULL &&
> _numa_bitmask_isbitset(bmp, node)) {
> + return true;
> + } else
> + return false;
> + }
> + // Check if a single node is bound
> + static bool issingle_node_bound() {
> + struct bitmask* bmp = _numa_get_membind != NULL ? _numa_get_membind()
> : NULL;
> + if(bmp == NULL) return false;
> + int issingle = 0;
> + // System can have more than 64 nodes so check in all the elements of
> + // unsigned long array
> + for (unsigned long i = 0; i < (bmp->size / (8 * sizeof(unsigned
> long))); i++) {
> + if (bmp->maskp != NULL && (((bmp->maskp[i]) & (((bmp->maskp[i])) -
> 1)) == 0)) {
> + issingle++;
> + } else if (bmp->maskp[i] == 0) {
> + continue;
> + } else {
> + return false;
> + }
> + }
> + if (issingle == 1)
> + return true;
> + return false;
> + }
> };
>
> #endif // OS_LINUX_VM_OS_LINUX_HPP
> diff --git a/src/hotspot/share/runtime/os.hpp
> b/src/hotspot/share/runtime/os.hpp
> --- a/src/hotspot/share/runtime/os.hpp
> +++ b/src/hotspot/share/runtime/os.hpp
> @@ -81,6 +81,10 @@
> CriticalPriority = 11 // Critical thread priority
> };
>
> +extern "C" struct bitmask {
> + unsigned long size; /* number of bits in the map */
> + unsigned long *maskp;
> +};
> // Executable parameter flag for os::commit_memory() and
> // os::commit_memory_or_exit().
> const bool ExecMem = true;
>
> =============================================================================
>
> Thanks,
> Swati
>
From erik.osterlund at oracle.com Thu Apr 26 13:36:31 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Thu, 26 Apr 2018 15:36:31 +0200
Subject: RFR: 8200557: OopStorage parallel iteration scales poorly
In-Reply-To: <7CBB6FF2-AC36-4723-BBA1-B4FA277C707B@oracle.com>
References: <7CBB6FF2-AC36-4723-BBA1-B4FA277C707B@oracle.com>
Message-ID: <5AE1D5DF.90909@oracle.com>
Hi Kim,
FIrst off, some high level comments:
1) I would have simply grabbed the allocation mutex when incrementing
the reference counter when starting concurrent iteration, instead of
using RCU. The path where we grab this active list for concurrent
iteration is stone cold, so I don't expect there to be any observable
benefit in using RCU here. But I am going to let that pass and just note
we think differently about things here, and I think that is okay.
2) It is a bit unfortunate that going down the RCU path led to yet
another implementation of RCU because GlobalCounter can not yet satisfy
your scenario. But I think that you have done a good job making the RCU
implementation pluggable in OopStorage, and we can easily remove it once
the ThreadsListHandle required by GlobalCounter starts supporting
lock-free nesting soon. I am speculating that your approach could be
folded in to the GlobalCounter, to accomodate non-JavaThreads and non-VM
threads, which that solution currently does not support. But perhaps
that is a discussion for later.
Low level comments:
* Noting that the new RCU mechanism will like the last one not work on
PPC until there is an atomic counter increment with more conservative
memory ordering. But I won't blame you for this.
In oopStorage.cpp:
879 size_t OopStorage::block_count() const {
880 WithActiveArray wab(this);
881 return wab.active_array().block_count_acquire();
882 }
Why do you need acquire here? I don't see subsequent loads into the
elements of the array, which seems to be what the paired release_store
when writing the counter protects against.
884 size_t OopStorage::total_memory_usage() const {
885 size_t total_size = sizeof(OopStorage);
886 total_size += strlen(name()) + 1;
887 total_size += sizeof(BlockArray);
888 WithActiveArray wab(this);
889 const BlockArray& blocks = wab.active_array();
890 total_size += blocks.block_count_acquire() *
Block::allocation_size();
891 total_size += blocks.size() * sizeof(Block*);
892 return total_size;
893 }
Same as above: what reordering is the block_count_acquire protecting
against? No element in the array is read after the acquire in program
order, that I can see.
760 _name(dup_name(name)),
761 _active_array(BlockArray::create(initial_active_array_size)),
762 _allocate_list(&Block::get_allocate_entry),
763 _deferred_updates(NULL),
764 _allocate_mutex(allocate_mutex),
765 _active_mutex(active_mutex),
766 _allocation_count(0),
767 _concurrent_iteration_active(false)
768 {
769 _active_array->increment_refcount();
I wonder if you could make BlockArray::create() always return an already
retained block array, instead of updating it after.
496 BlockArray* new_array = BlockArray::create(new_size);
497 if (new_array == NULL) return false;
498 new_array->copy_from(old_array);
499 replace_active_array(new_array);
And same here where a block array is created without retain reference
counter, which is then incremented manually inside of
replace_active_array. Seems to me like it would be easier to make
BlockArray::create return already retained block arrays.
Thanks,
/Erik
On 2018-04-19 10:18, Kim Barrett wrote:
> Please review this change to OopStorage parallel iteration to improve
> the scaling with additional threads.
>
> Two sources of poor scaling were found: (1) contention when claiming
> blocks, and (2) each worker thread ended up touching the majority of
> the blocks, even those not processed by that thread.
>
> To address this, we changed the representation of the sequence of all
> blocks. Rather than being a doubly-linked intrusive list linked
> through the blocks, it is now an array of pointers to blocks. We use
> a combination of refcounts and an RCU-inspired mechanism to safely
> manage the array storage when it needs to grow, avoiding the need to
> lock access to the array while performing concurrent iteration.
>
> The use of an array for the sequence of all blocks permits parallel
> iteration to claim ranges of indices using Atomic::add, which can be
> more efficient on some platforms than using cmpxchg loops. It also
> allows a worker thread to only touch exactly those blocks it is going
> to process, rather than walking a list of blocks. The only
> complicating factor is that we have to account for possible overshoot
> in a claim attempt.
>
> Blocks know their position in the array, to facilitate empty block
> deletion (an empty block might be anywhere in the active array, and we
> don't want to have to search for it). This also helps with
> allocation_status, eliminating the verification search that was needed
> with the list representation. allocation_status is now constant-time,
> which directly benefits -Xcheck:jni.
>
> A new gtest-based performance demonstration is included. It's not
> really a test, in that it doesn't do any verification. Rather, it
> performs parallel iteration and reports total time, per-thread times,
> and per-thread percentage of blocks processed. This is done for a
> variety of thread counts, to show the parallel speedup and load
> balancing. Running on my dual 6 core Xeon, I'm seeing more or less
> linear speedup for up to 10 threads processing 1M OopStorage entries.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8200557
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8200557/open.00/
>
> Testing:
> jdk-tier{1-3}, hs-tier{1-5}, on all Oracle supported platforms
>
From thomas.schatzl at oracle.com Thu Apr 26 14:15:46 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 26 Apr 2018 16:15:46 +0200
Subject: RFR: 8202230: Provide accessors for JNIHandles storage objects
In-Reply-To: <5910FB44-4D8C-4127-823E-DDB6ED4275CF@oracle.com>
References: <5910FB44-4D8C-4127-823E-DDB6ED4275CF@oracle.com>
Message-ID: <1524752146.11105.1.camel@oracle.com>
Hi,
On Wed, 2018-04-25 at 17:09 -0400, Kim Barrett wrote:
> Please review this addition to JNIHandles, providing access to the
> OopStorage objects used to manage the global and weak global handles.
> The accessors assert the storage objects have been allocated.
>
> Also changed direct uses of the storage object variables to instead
> use the new accessors, to get the initialization asserts during
> development.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8202230
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8202230/open.00/
>
> Testing:
> {jdk,hs}-tier{1,2,3} for all Oracle platforms.
>
looks good.
Thomas
From shade at redhat.com Thu Apr 26 15:55:31 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 26 Apr 2018 17:55:31 +0200
Subject: RFR 8201786: Modularize interpreter GC barriers: leftovers for ARM32
Message-ID: <4d22aacb-aa0d-4423-1a22-775e2be7eeaf@redhat.com>
http://cr.openjdk.java.net/~shade/8201786/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8201786
This finishes up the work for interpreter GC barriers modularization [1] for ARM32. My interest is
having a clean Epsilon GC patch, and this is the only remaining bit. The change is mostly about
moving the code around, but in some cases we have to replace the calls to "naked" stores with the
appropriate BSAsm calls too. There is a fair amount of symmetry with the x86 implementation, you may
want to cross-reference that during reviews.
Unfortunately, I have no way to test this thing thoroughly, except for running simple apps on Raspi
3 with the cross-compiled build. The largest app I tried was Wildfly Swarm demo with both Serial GC
(which covers CardTableBS) and G1 (which covers G1BS). More testing is appreciated!
Testing: arm32-hflt cross-build, some apps with Serial/G1 on Raspi 3
Thanks,
-Aleksey
[1] https://bugs.openjdk.java.net/browse/JDK-8201786
From erik.joelsson at oracle.com Thu Apr 26 16:03:39 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 26 Apr 2018 09:03:39 -0700
Subject: RFR(XL): 8199712: Flight Recorder
In-Reply-To: <0e2f481f-0c7c-5dfa-c37b-1b453b3b2d8d@oracle.com>
References: <5AE0612F.8060200@oracle.com>
<0e2f481f-0c7c-5dfa-c37b-1b453b3b2d8d@oracle.com>
Message-ID: <4ecc8033-f106-991e-caaa-a2c4bb0a072d@oracle.com>
Should linking to the -lkstat library be conditional on jfr feature
being set, or perhaps it doesn't matter that much. In that case, adding
the library could be done in JvmFeatures.gmk instead.
/Erik
On 2018-04-26 02:45, Magnus Ihse Bursie wrote:
>
> On 2018-04-25 13:06, Erik Gahlin wrote:
>> Greetings,
>>
>> Could I have a review of 8199712: Flight Recorder
>>
>> As mentioned in the preview [1] the tracing backend has been removed.
>> Event metadata has been consolidated into a single XML file and event
>> classes are now generated by GenerateJfrFiles.java.
>>
>> Tests have been run on Linux-x64, Windows-x64 and MaxOSX-x64.
>>
>> For details about the feature, see the JEP:
>> https://bugs.openjdk.java.net/browse/JDK-8193393
>>
>> Webrev:
>> http://cr.openjdk.java.net/~egahlin/8199712.0/
> Hi Erik,
>
> When posting build changes (files in "make/*"), please always include
> build-dev. Thanks! :-)
>
> This review is for build changes only.
>
> * make/RunTestsPrebuiltSpec.gmk: This file has only a copyright year
> change. It can be reverted.
>
> * make/copy/Copy-jdk.jfr.gmk:
> COPY_HOTSPOT_TRACE_FILES should be renamed to something like
> COPY_JFR_METADATA.
>
> The second part is better off rewritten using SetupCopyFiles.
>
> Something like this, written on-the-fly, so might not work. (Email me
> privately if it does not work and you need help.)
>
> JFR_CONF_DIR := $(TOPDIR)/src/jdk.jfr/share/conf/jfr
>
> $(eval $(call SetupCopyFiles, COPY_JFR_CONF, \
> ? DEST := $(LIB_DST_DIR)/jfr, \
> ? FILES := $(wildcard $(JFR_CONF_DIR)/*.jfc), \
> ? FLATTEN := true, \
> ))
>
> TARGETS += $(COPY_JFR_CONF)
>
> * make/autoconf/hotspot.m4:
> It's a bit unfortunate with the --enable-jfr option. Ideally, this
> should be handled only as a JVM feature (--with-jvm-features=jfr). Try
> this piece of code instead: (Not tested, but should work.)
>
> diff --git a/make/autoconf/hotspot.m4 b/make/autoconf/hotspot.m4
> --- a/make/autoconf/hotspot.m4
> +++ b/make/autoconf/hotspot.m4
> @@ -26,7 +26,7 @@
> ?# All valid JVM features, regardless of platform
> ?VALID_JVM_FEATURES="compiler1 compiler2 zero minimal dtrace jvmti
> jvmci \
> ???? graal vm-structs jni-check services management all-gcs nmt cds \
> -??? static-build link-time-opt aot"
> +??? static-build link-time-opt aot jfr"
>
> ?# All valid JVM variants
> ?VALID_JVM_VARIANTS="server client minimal core zero custom"
> @@ -313,6 +313,11 @@
> ???? AC_MSG_ERROR([Specified JVM feature 'vm-structs' requires feature
> 'all-gcs'])
> ?? fi
>
> +? # Enable JFR by default, except on linux-sparcv9 and on minimal.
> +? if test "x$OPENJDK_TARGET_OS" != xlinux || test
> "x$OPENJDK_TARGET_CPU" != xsparcv9; then
> +??? NON_MINIMAL_FEATURES="$NON_MINIMAL_FEATURES jfr"
> +? fi
> +
> ?? # Turn on additional features based on other parts of configure
> ?? if test "x$INCLUDE_DTRACE" = "xtrue"; then
> ???? JVM_FEATURES="$JVM_FEATURES dtrace"
>
> Otherwise, build changes look good!
>
> /Magnus
>
>
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8199712
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031359.html
>>
>> Thanks
>> Erik and Markus
>
From vladimir.kozlov at oracle.com Thu Apr 26 16:07:12 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 26 Apr 2018 09:07:12 -0700
Subject: RFR(XL): 8199712: Flight Recorder
In-Reply-To: <4ecc8033-f106-991e-caaa-a2c4bb0a072d@oracle.com>
References: <5AE0612F.8060200@oracle.com>
<0e2f481f-0c7c-5dfa-c37b-1b453b3b2d8d@oracle.com>
<4ecc8033-f106-991e-caaa-a2c4bb0a072d@oracle.com>
Message-ID: <1f750f87-057b-62b4-d434-d38e5afdc219@oracle.com>
-lkstat was also used to determine SPARC CPU features as I remember.
Vladimir
On 4/26/18 9:03 AM, Erik Joelsson wrote:
> Should linking to the -lkstat library be conditional on jfr feature
> being set, or perhaps it doesn't matter that much. In that case, adding
> the library could be done in JvmFeatures.gmk instead.
>
> /Erik
>
>
> On 2018-04-26 02:45, Magnus Ihse Bursie wrote:
>>
>> On 2018-04-25 13:06, Erik Gahlin wrote:
>>> Greetings,
>>>
>>> Could I have a review of 8199712: Flight Recorder
>>>
>>> As mentioned in the preview [1] the tracing backend has been removed.
>>> Event metadata has been consolidated into a single XML file and event
>>> classes are now generated by GenerateJfrFiles.java.
>>>
>>> Tests have been run on Linux-x64, Windows-x64 and MaxOSX-x64.
>>>
>>> For details about the feature, see the JEP:
>>> https://bugs.openjdk.java.net/browse/JDK-8193393
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~egahlin/8199712.0/
>> Hi Erik,
>>
>> When posting build changes (files in "make/*"), please always include
>> build-dev. Thanks! :-)
>>
>> This review is for build changes only.
>>
>> * make/RunTestsPrebuiltSpec.gmk: This file has only a copyright year
>> change. It can be reverted.
>>
>> * make/copy/Copy-jdk.jfr.gmk:
>> COPY_HOTSPOT_TRACE_FILES should be renamed to something like
>> COPY_JFR_METADATA.
>>
>> The second part is better off rewritten using SetupCopyFiles.
>>
>> Something like this, written on-the-fly, so might not work. (Email me
>> privately if it does not work and you need help.)
>>
>> JFR_CONF_DIR := $(TOPDIR)/src/jdk.jfr/share/conf/jfr
>>
>> $(eval $(call SetupCopyFiles, COPY_JFR_CONF, \
>> ? DEST := $(LIB_DST_DIR)/jfr, \
>> ? FILES := $(wildcard $(JFR_CONF_DIR)/*.jfc), \
>> ? FLATTEN := true, \
>> ))
>>
>> TARGETS += $(COPY_JFR_CONF)
>>
>> * make/autoconf/hotspot.m4:
>> It's a bit unfortunate with the --enable-jfr option. Ideally, this
>> should be handled only as a JVM feature (--with-jvm-features=jfr). Try
>> this piece of code instead: (Not tested, but should work.)
>>
>> diff --git a/make/autoconf/hotspot.m4 b/make/autoconf/hotspot.m4
>> --- a/make/autoconf/hotspot.m4
>> +++ b/make/autoconf/hotspot.m4
>> @@ -26,7 +26,7 @@
>> ?# All valid JVM features, regardless of platform
>> ?VALID_JVM_FEATURES="compiler1 compiler2 zero minimal dtrace jvmti
>> jvmci \
>> ???? graal vm-structs jni-check services management all-gcs nmt cds \
>> -??? static-build link-time-opt aot"
>> +??? static-build link-time-opt aot jfr"
>>
>> ?# All valid JVM variants
>> ?VALID_JVM_VARIANTS="server client minimal core zero custom"
>> @@ -313,6 +313,11 @@
>> ???? AC_MSG_ERROR([Specified JVM feature 'vm-structs' requires feature
>> 'all-gcs'])
>> ?? fi
>>
>> +? # Enable JFR by default, except on linux-sparcv9 and on minimal.
>> +? if test "x$OPENJDK_TARGET_OS" != xlinux || test
>> "x$OPENJDK_TARGET_CPU" != xsparcv9; then
>> +??? NON_MINIMAL_FEATURES="$NON_MINIMAL_FEATURES jfr"
>> +? fi
>> +
>> ?? # Turn on additional features based on other parts of configure
>> ?? if test "x$INCLUDE_DTRACE" = "xtrue"; then
>> ???? JVM_FEATURES="$JVM_FEATURES dtrace"
>>
>> Otherwise, build changes look good!
>>
>> /Magnus
>>
>>
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8199712
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031359.html
>>>
>>>
>>> Thanks
>>> Erik and Markus
>>
>
From coleen.phillimore at oracle.com Thu Apr 26 17:55:36 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 26 Apr 2018 13:55:36 -0400
Subject: RFR(XL): 8199712: Flight Recorder
In-Reply-To: <5AE0612F.8060200@oracle.com>
References: <5AE0612F.8060200@oracle.com>
Message-ID: <c03a0aaf-1b63-2296-14f2-6b469e633ec2@oracle.com>
http://cr.openjdk.java.net/~egahlin/8199712.0/src/hotspot/share/classfile/classLoaderData.cpp.udiff.html
We can file another RFE for this but I think you could call
post_class_unload_event() from in InstanceKlass and call from inside of
InstanceKlass::notify_unload_class.
void ClassLoaderData::unload() {
? _unloading = true;
? // Tell serviceability tools these classes are unloading
? classes_do(InstanceKlass::notify_unload_class);
Rather than walking through _klasses again during unloading.? I think we
should see if this is possible to improve this after this checkin.
http://cr.openjdk.java.net/~egahlin/8199712.0/src/hotspot/share/classfile/systemDictionary.cpp.udiff.html
Then move post_class_load and post_class_define events to
instanceKlass.cpp too.
http://cr.openjdk.java.net/~egahlin/8199712.0/src/hotspot/share/utilities/vmError.cpp.udiff.html
Sometimes files are #included inside of #if INCLUDE_JFR and sometimes
they aren't.?? Should jfr/jfr.hpp have the #if INCLUDE_JFR inside of it?
I reviewed all the shared code in directories classfile, runtime, oops,
utilities, except for utilities/ticks.hpp changes, which require an
expert for that.
It looks like you have my last change that was in jfrArtifacts.cpp now in
new/src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeManager.hpp
Great!
Thanks,
Coleen
On 4/25/18 7:06 AM, Erik Gahlin wrote:
> Greetings,
>
> Could I have a review of 8199712: Flight Recorder
>
> As mentioned in the preview [1] the tracing backend has been removed.
> Event metadata has been consolidated into a single XML file and event
> classes are now generated by GenerateJfrFiles.java.
>
> Tests have been run on Linux-x64, Windows-x64 and MaxOSX-x64.
>
> For details about the feature, see the JEP:
> https://bugs.openjdk.java.net/browse/JDK-8193393
>
> Webrev:
> http://cr.openjdk.java.net/~egahlin/8199712.0/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8199712
>
> [1]
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031359.html
>
> Thanks
> Erik and Markus
From coleen.phillimore at oracle.com Thu Apr 26 17:58:42 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 26 Apr 2018 13:58:42 -0400
Subject: RFR(XL): 8199712: Flight Recorder
In-Reply-To: <5AE0612F.8060200@oracle.com>
References: <5AE0612F.8060200@oracle.com>
Message-ID: <79cfed54-8b6f-97c6-7fbc-db4f5e5ed39b@oracle.com>
http://cr.openjdk.java.net/~egahlin/8199712.0/src/hotspot/share/classfile/classLoaderData.cpp.udiff.html
We can file another RFE for this but I think you could call
post_class_unload_event() from in InstanceKlass and call from inside of
InstanceKlass::notify_unload_class.
void ClassLoaderData::unload() {
? _unloading = true;
? // Tell serviceability tools these classes are unloading
? classes_do(InstanceKlass::notify_unload_class);
Rather than walking through _klasses again during unloading.? I think we
should see if this is possible to improve this after this checkin.
http://cr.openjdk.java.net/~egahlin/8199712.0/src/hotspot/share/classfile/systemDictionary.cpp.udiff.html
Then move post_class_load and post_class_define events to
instanceKlass.cpp too.
http://cr.openjdk.java.net/~egahlin/8199712.0/src/hotspot/share/utilities/vmError.cpp.udiff.html
Sometimes files are #included inside of #if INCLUDE_JFR and sometimes
they aren't.?? Should jfr/jfr.hpp have the #if INCLUDE_JFR inside of it?
I reviewed all the shared code in directories classfile, runtime, oops,
utilities, except for utilities/ticks.hpp changes, which require an
expert for that.
It looks like you have my last change that was in jfrArtifacts.cpp now in
new/src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeManager.hpp
Great!
Thanks,
Coleen
On 4/25/18 7:06 AM, Erik Gahlin wrote:
> Greetings,
>
> Could I have a review of 8199712: Flight Recorder
>
> As mentioned in the preview [1] the tracing backend has been removed.
> Event metadata has been consolidated into a single XML file and event
> classes are now generated by GenerateJfrFiles.java.
>
> Tests have been run on Linux-x64, Windows-x64 and MaxOSX-x64.
>
> For details about the feature, see the JEP:
> https://bugs.openjdk.java.net/browse/JDK-8193393
>
> Webrev:
> http://cr.openjdk.java.net/~egahlin/8199712.0/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8199712
>
> [1]
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031359.html
>
> Thanks
> Erik and Markus
From dms at samersoff.net Thu Apr 26 19:07:17 2018
From: dms at samersoff.net (Dmitry Samersoff)
Date: Thu, 26 Apr 2018 22:07:17 +0300
Subject: RFR(XL): 8199712: Flight Recorder
In-Reply-To: <5AE0612F.8060200@oracle.com>
References: <5AE0612F.8060200@oracle.com>
Message-ID: <706e6211-bdd7-6b80-872a-6a909756815b@samersoff.net>
Erik,
jfrRecorder.cpp:51:10: error: ?Flag? does not name a type
static Flag* const flight_recorder_flag =
Flag::find_flag("FlightRecorder", length);
Should it be JVMFlag ?
-Dmitry
On 04/25/2018 02:06 PM, Erik Gahlin wrote:
> Greetings,
>
> Could I have a review of 8199712: Flight Recorder
>
> As mentioned in the preview [1] the tracing backend has been removed.
> Event metadata has been consolidated into a single XML file and event
> classes are now generated by GenerateJfrFiles.java.
>
> Tests have been run on Linux-x64, Windows-x64 and MaxOSX-x64.
>
> For details about the feature, see the JEP:
> https://bugs.openjdk.java.net/browse/JDK-8193393
>
> Webrev:
> http://cr.openjdk.java.net/~egahlin/8199712.0/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8199712
>
> [1]
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031359.html
>
> Thanks
> Erik and Markus
--
Dmitry Samersoff
http://devnull.samersoff.net
* There will come soft rains ...
From kim.barrett at oracle.com Thu Apr 26 20:34:34 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 26 Apr 2018 16:34:34 -0400
Subject: RFR: 8202082: Remove explicit CMS checks in
CardTableBarrierSetAssembler
In-Reply-To: <b96d0e61-094c-cf0c-56ca-9239a980240c@oracle.com>
References: <5AD9FC94.70607@oracle.com>
<6A476A6A-47BB-4141-980E-DB98D9BAD405@oracle.com>
<67ac1742-640e-f011-f371-cf53b782e969@oracle.com>
<60EA410E-E1FE-4A54-95CA-E3F11CC9B168@oracle.com>
<9c283f66-326a-d640-432d-b6c573802b5e@oracle.com>
<1964D307-E283-47CA-96C6-7AF577F96EC4@oracle.com>
<5AE08864.4070802@oracle.com>
<B2AF6F60-26C3-4371-A1BE-E9ECF1A57AAF@oracle.com>
<b96d0e61-094c-cf0c-56ca-9239a980240c@oracle.com>
Message-ID: <183DA9B9-6802-48E4-BB3B-69553186ECD6@oracle.com>
> On Apr 26, 2018, at 2:52 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>
> Hi Kim,
>
> On 2018-04-26 06:36, Kim Barrett wrote:
>>> On Apr 25, 2018, at 9:53 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>>>
>>> Hi Kim,
>>>
>>> Okay, it looks like we kind of agree that this is a step in the right direction for now. Thank you for the review.
>>>
>>> Here is my final webrev with "disp" not refetched (and renamed to card_table_addr):
>>> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.01/
>>>
>>> Incremental:
>>> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.00_01/
>> Only partially addressed my comment:
>> src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
>> 105 intptr_t card_table_addr = (intptr_t)ctbs->card_table()->byte_map_base();
>>
>> s/ctbs->card_table()/ct/
>>
>> But wait, that version shouldn?t even compile?
>> 107 card_addr = Address(noreg, obj, Address::times_1, disp);
>> still refers to ?disp?.
>
> Fixed.
>
>> card_table_add is better than disp.
>
> Actually now that I think of it, I decided the name should be byte_map_base instead. That is indeed what the comments already refer to and what other platforms consistently call this variable. And it is not a real address.
Yes, that is better.
Looks good.
>
> Incremental:
> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.01_02/
>
> Full:
> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.02/
>
> Thanks,
> /Erik
From kim.barrett at oracle.com Thu Apr 26 20:35:09 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 26 Apr 2018 16:35:09 -0400
Subject: RFR: 8202230: Provide accessors for JNIHandles storage objects
In-Reply-To: <1524752146.11105.1.camel@oracle.com>
References: <5910FB44-4D8C-4127-823E-DDB6ED4275CF@oracle.com>
<1524752146.11105.1.camel@oracle.com>
Message-ID: <41F781A1-4803-4467-87A4-95337EDCB63A@oracle.com>
> On Apr 26, 2018, at 10:15 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
>
> Hi,
>
> On Wed, 2018-04-25 at 17:09 -0400, Kim Barrett wrote:
>> Please review this addition to JNIHandles, providing access to the
>> OopStorage objects used to manage the global and weak global handles.
>> The accessors assert the storage objects have been allocated.
>>
>> Also changed direct uses of the storage object variables to instead
>> use the new accessors, to get the initialization asserts during
>> development.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8202230
>>
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8202230/open.00/
>>
>> Testing:
>> {jdk,hs}-tier{1,2,3} for all Oracle platforms.
>>
>
> looks good.
>
> Thomas
Thanks.
From erik.osterlund at oracle.com Thu Apr 26 20:46:02 2018
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Thu, 26 Apr 2018 22:46:02 +0200
Subject: RFR: 8202082: Remove explicit CMS checks in
CardTableBarrierSetAssembler
In-Reply-To: <183DA9B9-6802-48E4-BB3B-69553186ECD6@oracle.com>
References: <5AD9FC94.70607@oracle.com>
<6A476A6A-47BB-4141-980E-DB98D9BAD405@oracle.com>
<67ac1742-640e-f011-f371-cf53b782e969@oracle.com>
<60EA410E-E1FE-4A54-95CA-E3F11CC9B168@oracle.com>
<9c283f66-326a-d640-432d-b6c573802b5e@oracle.com>
<1964D307-E283-47CA-96C6-7AF577F96EC4@oracle.com>
<5AE08864.4070802@oracle.com>
<B2AF6F60-26C3-4371-A1BE-E9ECF1A57AAF@oracle.com>
<b96d0e61-094c-cf0c-56ca-9239a980240c@oracle.com>
<183DA9B9-6802-48E4-BB3B-69553186ECD6@oracle.com>
Message-ID: <03CE4CBE-6D62-4AA7-A056-A7399F49AC4D@oracle.com>
Hi Kim,
Thank you for the review.
/Erik
On 26 Apr 2018, at 22:34, Kim Barrett <kim.barrett at oracle.com> wrote:
>> On Apr 26, 2018, at 2:52 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>>
>> Hi Kim,
>>
>> On 2018-04-26 06:36, Kim Barrett wrote:
>>>> On Apr 25, 2018, at 9:53 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>>>>
>>>> Hi Kim,
>>>>
>>>> Okay, it looks like we kind of agree that this is a step in the right direction for now. Thank you for the review.
>>>>
>>>> Here is my final webrev with "disp" not refetched (and renamed to card_table_addr):
>>>> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.01/
>>>>
>>>> Incremental:
>>>> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.00_01/
>>> Only partially addressed my comment:
>>> src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
>>> 105 intptr_t card_table_addr = (intptr_t)ctbs->card_table()->byte_map_base();
>>>
>>> s/ctbs->card_table()/ct/
>>>
>>> But wait, that version shouldn?t even compile?
>>> 107 card_addr = Address(noreg, obj, Address::times_1, disp);
>>> still refers to ?disp?.
>>
>> Fixed.
>>
>>> card_table_add is better than disp.
>>
>> Actually now that I think of it, I decided the name should be byte_map_base instead. That is indeed what the comments already refer to and what other platforms consistently call this variable. And it is not a real address.
>
> Yes, that is better.
>
> Looks good.
>
>>
>> Incremental:
>> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.01_02/
>>
>> Full:
>> http://cr.openjdk.java.net/~eosterlund/8202082/webrev.02/
>>
>> Thanks,
>> /Erik
>
>
From kim.barrett at oracle.com Thu Apr 26 21:03:16 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 26 Apr 2018 17:03:16 -0400
Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for
ppc64
In-Reply-To: <5625a595-1165-8d48-afbd-8229cdc4ac07@oracle.com>
References: <OF16DAB34F.17FD9ED8-ON00258278.002211BA-49258278.003A0AFD@notes.na.collabserv.com>
<5625a595-1165-8d48-afbd-8229cdc4ac07@oracle.com>
Message-ID: <F8C75A5A-404E-45CA-89CE-C97E582AF2D7@oracle.com>
> On Apr 25, 2018, at 8:45 AM, David Holmes <david.holmes at oracle.com> wrote:
>
> Hi Michihiro,
>
> On 23/04/2018 8:33 PM, Michihiro Horie wrote:
>> Dear all,
>> I would like to ask reviews on 8154736 ?enhancement of cmpxchg and
>> copy_to_survivor?. The change adds options to avoid expensive syncs with
>> compare-and-exchange. An experiment by using SPECjbb2015 showed 6%
>> improvement in critical-jOPS. This change focuses on ppc64 but would be
>> potentially beneficial for aarch64.
>> Although discussions stopped at
>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-October/002718.html
>> , I would like to restart the review by taking over Hiroshi's work if the
>> discussion is still open.
>
> So the very last comment there was about not implicitly assuming memory_order_consume, yet that has not been addressed in the proposal.
>
> Further the discussion on hotspot-runtime-dev through September and October was far more illuminating. I think my post here:
>
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-October/021617.html
>
> and the closely following one from Thomas Schatzl summed up the concerns about the proposed changes.
>
> AFAICS the restarted proposal addresses none of those concerns but simply takes up where the previous implementation suggestion left off.
>
> This is a proposal to change the memory ordering semantics of part of the shared GC code _not_ just the PPC64 implementation, but I have seen no analysis to demonstrate the correctness of such a proposal.
I agree with David here. So far we've seen no such analysis. All we
have seen is a series of proposed changes and non-failing test
results, all of which have then been shown to have holes. (Among other
things, this suggests the set of tests being applied is inadequate.)
Part of the author's job is to convince reviewers that the proposed
change is correct. I'm not expecting a formal proof, but I am
expecting a lot more than has been provided so far.
In this latest proposal, the conditional acquire doesn't look right to
me. If the logging is disabled so there is no acquire, the object is
then returned to the callers, who might do what with it? Is that safe?
For all callers? And is it stable through future maintenance? This is
not to say that I think making those acquires unconditional is
sufficient.
From vladimir.x.ivanov at oracle.com Thu Apr 26 21:07:56 2018
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 26 Apr 2018 14:07:56 -0700
Subject: (M) RFR: 8200167: Validate more special case invocations
In-Reply-To: <a943a81b-e2da-57f2-92bd-1ef3d6fc7f72@oracle.com>
References: <27391c2a-fd5c-8133-8e31-b8b45db157ce@oracle.com>
<a943a81b-e2da-57f2-92bd-1ef3d6fc7f72@oracle.com>
Message-ID: <2907289a-2915-118c-f3c0-1327798f6f80@oracle.com>
David, thanks for taking care of the bug!
src/hotspot/share/c1/c1_Canonicalizer.cpp
...
void Canonicalizer::do_CheckCast (CheckCast* x) {
- if (x->klass()->is_loaded()) {
+ if (x->klass()->is_loaded() && !x->is_invokespecial_receiver_check())
It seems like it's not something specific to invokespecial, but a
generic problem in how interface casts are handled in C1: it's not
correct to eliminate the cast if obj->declared_type() is an interface. I
assume that's what happens in your case. FTR I'm fine with handling it
separately.
test/jdk/java/lang/invoke/I4Special.jcod:
I'm curious why did you choose jcod here and not jasm? It seems jasm
should be a better fit to replace invokevirtual with invokespecial
(unless I'm missing something important in the test case).
Otherwise, looks good.
Best regards,
Vladimir Ivanov
On 4/25/18 21:12, David Holmes wrote:
> Revised webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev.v2/
>
> Karen formulated an additional test scenario invoking Object methods
> through an interface reference, which when turned into a new testcase
> demonstrated that the receiver typecheck was also missing in that case
> for Methodhandle's from findSpecial.
>
> Again Vladimir Ivanov formulated the fix for this. Thanks Vladimir!
>
> Summary of changes from original webrev:
>
> - We introduce a new version of DirectMethodHandle.preparedlambdaForm
> that takes the caller class as a parameter, and that class is checked
> for being an interface (not the method's declaring class) to trigger the
> switch to LF_SPECIAL_IFC. (This obviously addresses one problem with
> invoking Object methods - as Object is not an interface - but by itself
> did not fix the problem.)
>
> - We introduce a new LambdaForm kind, DIRECT_INVOKE_SPECIAL_IFC, which
> we use when dealing with LF_INVSPECIAL_IFC. (This was the key in
> ensuring the receiver typecheck via Special.checkReceiver remained in
> the generated code.)
>
> - In the test we:
> ? - introduce a new invokeDirect testcase for Object.toString(), but we
> need to do that via a modified jcod file (as javac generates an
> invokevirtual)
> ? - introduce the new invokeSpecialObjectMH(I2 i) call for the MH case.
>
> Thanks,
> David
>
> On 17/04/2018 6:48 PM, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200167
>> webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev/
>>
>> Credit to John Rose and Vladimir Ivanov for the form of the MH fix;
>> and to Tobias Hartmann for the C1 fix. Their help was very much
>> appreciated (and needed!).
>>
>> tl;dr version: there are some places where badly formed interface
>> method calls (which are not detected by the verifier) were missing
>> runtime checks on the type of the receiver. Similar issues have been
>> fixed in the past and this was a remaining hole in relation to
>> invokespecial semantics and interface calls via MethodHandles. It also
>> turned out there was an issue in C1 that affected direct invokespecial
>> calls.
>>
>> Description of changes:
>>
>> - src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java
>>
>> Added a new form LF_INVSPECIAL_IFC for invokespecial of interface
>> methods.
>>
>> - src/java.base/share/classes/java/lang/invoke/MethodHandles.java
>>
>> Renamed callerClass parameter to boundCallerClass, where it originates
>> from findBoundCallerClass. The name "callerClass" is misleading
>> because most of the time it is NULL!
>>
>> In getDirectMethodCommon, pass the actual caller class (lookupClass)
>> to DirectMethodHandle.make. And correct the comment about
>> restrictReceiver.
>>
>> - src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
>>
>> DirectMethodHandle.make now takes a callerClass parameter (which may
>> be null).
>>
>> DirectMethodHandle make "receiver" parameter is renamed "refc" as it
>> is not the receiver (it's the resolved type of the method holder ie
>> REFC).
>>
>> The Special subclass now takes a "checkClass" parameter which is
>> either refc, or callerClass. This is what we will check the receiver
>> against.
>>
>> In preparedLambdaForm we switch from LF_INVSPECIAL to
>> LF_INVSPECIAL_IFC if the target method is in an interface.
>>
>> In makePreparedLambdaForm we augment the needsReceiverCheck test to
>> include LF_INVSPECIAL_IFC. (So we will not be doing a new receiver
>> type check on all invokespecials, just those involving interface
>> methods.)
>>
>> Added DMH.checkReceiver which is overridden by both the Special and
>> Interface subclasses.
>>
>> - src/hotspot/share/c1/c1_Canonicalizer.cpp
>>
>> Don't optimize away the checkcast when it is an invokespecial receiver
>> check.
>>
>> - test/jdk/java/lang/invoke/SpecialInterfaceCall.java
>>
>> (I've moved this test back and forth between hotspot/runtime and
>> j.l.invoke as it spans direct calls and MH calls. But I think on
>> balance it lands better here.)
>>
>> The test sets up direct interface method calls for which invokespecial
>> is generated by javac, and similarly it creates MethodHandles with
>> invokespecial semantics. The should-not-throw cases are trivial. The
>> should-throw cases involve MH wizardry.
>>
>> The test is broken into three parts to check the behaviour on first
>> use (when the method has to be initially resolved); on second use (to
>> test we don't use the cpcache in a way that is invalid); and again
>> after forcing JIT compilation of the calls.
>>
>> The test is run 5 times to exercise the interpreter (yes the multiple
>> runs internal to the test are redundant in this case, but it's much
>> simpler to just run it all than try to work out what needs to be run);
>> the three variants of using C1, plus a C2 only run.
>>
>> ---
>>
>> Testing:
>> ?? - the new test of course
>> ?? - hotspot/runtime/*
>> ?? - hotspot/compiler/jsr292
>> ?? - jdk/java/lang/invoke
>>
>> ?? - hs tiers 1 and 2
>> ?? - jdk tiers 1, 2 and 3
>>
>> Plus some related closed tests.
>>
>> Thanks,
>> David
>> -----
From karen.kinnear at oracle.com Thu Apr 26 21:21:50 2018
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Thu, 26 Apr 2018 17:21:50 -0400
Subject: (M) RFR: 8200167: Validate more special case invocations
In-Reply-To: <a943a81b-e2da-57f2-92bd-1ef3d6fc7f72@oracle.com>
References: <27391c2a-fd5c-8133-8e31-b8b45db157ce@oracle.com>
<a943a81b-e2da-57f2-92bd-1ef3d6fc7f72@oracle.com>
Message-ID: <5378B538-F114-4199-9C1F-34F0A9E8F0B0@oracle.com>
Looks good!
Thank you so much David and Vladimir for all the work to cover the corner cases.
thanks,
Karen
> On Apr 26, 2018, at 12:12 AM, David Holmes <david.holmes at oracle.com> wrote:
>
> Revised webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev.v2/
>
> Karen formulated an additional test scenario invoking Object methods through an interface reference, which when turned into a new testcase demonstrated that the receiver typecheck was also missing in that case for Methodhandle's from findSpecial.
>
> Again Vladimir Ivanov formulated the fix for this. Thanks Vladimir!
>
> Summary of changes from original webrev:
>
> - We introduce a new version of DirectMethodHandle.preparedlambdaForm that takes the caller class as a parameter, and that class is checked for being an interface (not the method's declaring class) to trigger the switch to LF_SPECIAL_IFC. (This obviously addresses one problem with invoking Object methods - as Object is not an interface - but by itself did not fix the problem.)
>
> - We introduce a new LambdaForm kind, DIRECT_INVOKE_SPECIAL_IFC, which we use when dealing with LF_INVSPECIAL_IFC. (This was the key in ensuring the receiver typecheck via Special.checkReceiver remained in the generated code.)
>
> - In the test we:
> - introduce a new invokeDirect testcase for Object.toString(), but we need to do that via a modified jcod file (as javac generates an invokevirtual)
> - introduce the new invokeSpecialObjectMH(I2 i) call for the MH case.
>
> Thanks,
> David
>
> On 17/04/2018 6:48 PM, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200167
>> webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev/
>> Credit to John Rose and Vladimir Ivanov for the form of the MH fix; and to Tobias Hartmann for the C1 fix. Their help was very much appreciated (and needed!).
>> tl;dr version: there are some places where badly formed interface method calls (which are not detected by the verifier) were missing runtime checks on the type of the receiver. Similar issues have been fixed in the past and this was a remaining hole in relation to invokespecial semantics and interface calls via MethodHandles. It also turned out there was an issue in C1 that affected direct invokespecial calls.
>> Description of changes:
>> - src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java
>> Added a new form LF_INVSPECIAL_IFC for invokespecial of interface methods.
>> - src/java.base/share/classes/java/lang/invoke/MethodHandles.java
>> Renamed callerClass parameter to boundCallerClass, where it originates from findBoundCallerClass. The name "callerClass" is misleading because most of the time it is NULL!
>> In getDirectMethodCommon, pass the actual caller class (lookupClass) to DirectMethodHandle.make. And correct the comment about restrictReceiver.
>> - src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
>> DirectMethodHandle.make now takes a callerClass parameter (which may be null).
>> DirectMethodHandle make "receiver" parameter is renamed "refc" as it is not the receiver (it's the resolved type of the method holder ie REFC).
>> The Special subclass now takes a "checkClass" parameter which is either refc, or callerClass. This is what we will check the receiver against.
>> In preparedLambdaForm we switch from LF_INVSPECIAL to LF_INVSPECIAL_IFC if the target method is in an interface.
>> In makePreparedLambdaForm we augment the needsReceiverCheck test to include LF_INVSPECIAL_IFC. (So we will not be doing a new receiver type check on all invokespecials, just those involving interface methods.)
>> Added DMH.checkReceiver which is overridden by both the Special and Interface subclasses.
>> - src/hotspot/share/c1/c1_Canonicalizer.cpp
>> Don't optimize away the checkcast when it is an invokespecial receiver check.
>> - test/jdk/java/lang/invoke/SpecialInterfaceCall.java
>> (I've moved this test back and forth between hotspot/runtime and j.l.invoke as it spans direct calls and MH calls. But I think on balance it lands better here.)
>> The test sets up direct interface method calls for which invokespecial is generated by javac, and similarly it creates MethodHandles with invokespecial semantics. The should-not-throw cases are trivial. The should-throw cases involve MH wizardry.
>> The test is broken into three parts to check the behaviour on first use (when the method has to be initially resolved); on second use (to test we don't use the cpcache in a way that is invalid); and again after forcing JIT compilation of the calls.
>> The test is run 5 times to exercise the interpreter (yes the multiple runs internal to the test are redundant in this case, but it's much simpler to just run it all than try to work out what needs to be run); the three variants of using C1, plus a C2 only run.
>> ---
>> Testing:
>> - the new test of course
>> - hotspot/runtime/*
>> - hotspot/compiler/jsr292
>> - jdk/java/lang/invoke
>> - hs tiers 1 and 2
>> - jdk tiers 1, 2 and 3
>> Plus some related closed tests.
>> Thanks,
>> David
>> -----
From david.holmes at oracle.com Thu Apr 26 22:04:17 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 27 Apr 2018 08:04:17 +1000
Subject: (M) RFR: 8200167: Validate more special case invocations
In-Reply-To: <2907289a-2915-118c-f3c0-1327798f6f80@oracle.com>
References: <27391c2a-fd5c-8133-8e31-b8b45db157ce@oracle.com>
<a943a81b-e2da-57f2-92bd-1ef3d6fc7f72@oracle.com>
<2907289a-2915-118c-f3c0-1327798f6f80@oracle.com>
Message-ID: <4e8bbf0c-0e04-a74f-74a3-4b60ba47e48e@oracle.com>
Hi Vladimir,
On 27/04/2018 7:07 AM, Vladimir Ivanov wrote:
> David, thanks for taking care of the bug!
Thanks for all the help!
> src/hotspot/share/c1/c1_Canonicalizer.cpp
> ...
> ?void Canonicalizer::do_CheckCast????? (CheckCast*?????? x) {
> -? if (x->klass()->is_loaded()) {
> +? if (x->klass()->is_loaded() && !x->is_invokespecial_receiver_check())
>
> It seems like it's not something specific to invokespecial, but a
> generic problem in how interface casts are handled in C1: it's not
> correct to eliminate the cast if obj->declared_type() is an interface. I
> assume that's what happens in your case. FTR I'm fine with handling it
> separately.
The above came from Tobias. If you think there is a more general issue
here then we should file a separate bug and formulate a test case.
> test/jdk/java/lang/invoke/I4Special.jcod:
>
> I'm curious why did you choose jcod here and not jasm? It seems jasm
> should be a better fit to replace invokevirtual with invokespecial
> (unless I'm missing something important in the test case).
Simply because jcod is what I have been working with in nestmates for
classfile customizations and I don't know jasm.
> Otherwise, looks good.
Thanks again!
David
>
> Best regards,
> Vladimir Ivanov
>
> On 4/25/18 21:12, David Holmes wrote:
>> Revised webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev.v2/
>>
>> Karen formulated an additional test scenario invoking Object methods
>> through an interface reference, which when turned into a new testcase
>> demonstrated that the receiver typecheck was also missing in that case
>> for Methodhandle's from findSpecial.
>>
>> Again Vladimir Ivanov formulated the fix for this. Thanks Vladimir!
>>
>> Summary of changes from original webrev:
>>
>> - We introduce a new version of DirectMethodHandle.preparedlambdaForm
>> that takes the caller class as a parameter, and that class is checked
>> for being an interface (not the method's declaring class) to trigger
>> the switch to LF_SPECIAL_IFC. (This obviously addresses one problem
>> with invoking Object methods - as Object is not an interface - but by
>> itself did not fix the problem.)
>>
>> - We introduce a new LambdaForm kind, DIRECT_INVOKE_SPECIAL_IFC, which
>> we use when dealing with LF_INVSPECIAL_IFC. (This was the key in
>> ensuring the receiver typecheck via Special.checkReceiver remained in
>> the generated code.)
>>
>> - In the test we:
>> ?? - introduce a new invokeDirect testcase for Object.toString(), but
>> we need to do that via a modified jcod file (as javac generates an
>> invokevirtual)
>> ?? - introduce the new invokeSpecialObjectMH(I2 i) call for the MH case.
>>
>> Thanks,
>> David
>>
>> On 17/04/2018 6:48 PM, David Holmes wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200167
>>> webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev/
>>>
>>> Credit to John Rose and Vladimir Ivanov for the form of the MH fix;
>>> and to Tobias Hartmann for the C1 fix. Their help was very much
>>> appreciated (and needed!).
>>>
>>> tl;dr version: there are some places where badly formed interface
>>> method calls (which are not detected by the verifier) were missing
>>> runtime checks on the type of the receiver. Similar issues have been
>>> fixed in the past and this was a remaining hole in relation to
>>> invokespecial semantics and interface calls via MethodHandles. It
>>> also turned out there was an issue in C1 that affected direct
>>> invokespecial calls.
>>>
>>> Description of changes:
>>>
>>> - src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java
>>>
>>> Added a new form LF_INVSPECIAL_IFC for invokespecial of interface
>>> methods.
>>>
>>> - src/java.base/share/classes/java/lang/invoke/MethodHandles.java
>>>
>>> Renamed callerClass parameter to boundCallerClass, where it
>>> originates from findBoundCallerClass. The name "callerClass" is
>>> misleading because most of the time it is NULL!
>>>
>>> In getDirectMethodCommon, pass the actual caller class (lookupClass)
>>> to DirectMethodHandle.make. And correct the comment about
>>> restrictReceiver.
>>>
>>> - src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
>>>
>>> DirectMethodHandle.make now takes a callerClass parameter (which may
>>> be null).
>>>
>>> DirectMethodHandle make "receiver" parameter is renamed "refc" as it
>>> is not the receiver (it's the resolved type of the method holder ie
>>> REFC).
>>>
>>> The Special subclass now takes a "checkClass" parameter which is
>>> either refc, or callerClass. This is what we will check the receiver
>>> against.
>>>
>>> In preparedLambdaForm we switch from LF_INVSPECIAL to
>>> LF_INVSPECIAL_IFC if the target method is in an interface.
>>>
>>> In makePreparedLambdaForm we augment the needsReceiverCheck test to
>>> include LF_INVSPECIAL_IFC. (So we will not be doing a new receiver
>>> type check on all invokespecials, just those involving interface
>>> methods.)
>>>
>>> Added DMH.checkReceiver which is overridden by both the Special and
>>> Interface subclasses.
>>>
>>> - src/hotspot/share/c1/c1_Canonicalizer.cpp
>>>
>>> Don't optimize away the checkcast when it is an invokespecial
>>> receiver check.
>>>
>>> - test/jdk/java/lang/invoke/SpecialInterfaceCall.java
>>>
>>> (I've moved this test back and forth between hotspot/runtime and
>>> j.l.invoke as it spans direct calls and MH calls. But I think on
>>> balance it lands better here.)
>>>
>>> The test sets up direct interface method calls for which
>>> invokespecial is generated by javac, and similarly it creates
>>> MethodHandles with invokespecial semantics. The should-not-throw
>>> cases are trivial. The should-throw cases involve MH wizardry.
>>>
>>> The test is broken into three parts to check the behaviour on first
>>> use (when the method has to be initially resolved); on second use (to
>>> test we don't use the cpcache in a way that is invalid); and again
>>> after forcing JIT compilation of the calls.
>>>
>>> The test is run 5 times to exercise the interpreter (yes the multiple
>>> runs internal to the test are redundant in this case, but it's much
>>> simpler to just run it all than try to work out what needs to be
>>> run); the three variants of using C1, plus a C2 only run.
>>>
>>> ---
>>>
>>> Testing:
>>> ?? - the new test of course
>>> ?? - hotspot/runtime/*
>>> ?? - hotspot/compiler/jsr292
>>> ?? - jdk/java/lang/invoke
>>>
>>> ?? - hs tiers 1 and 2
>>> ?? - jdk tiers 1, 2 and 3
>>>
>>> Plus some related closed tests.
>>>
>>> Thanks,
>>> David
>>> -----
From david.holmes at oracle.com Thu Apr 26 22:05:16 2018
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 27 Apr 2018 08:05:16 +1000
Subject: (M) RFR: 8200167: Validate more special case invocations
In-Reply-To: <5378B538-F114-4199-9C1F-34F0A9E8F0B0@oracle.com>
References: <27391c2a-fd5c-8133-8e31-b8b45db157ce@oracle.com>
<a943a81b-e2da-57f2-92bd-1ef3d6fc7f72@oracle.com>
<5378B538-F114-4199-9C1F-34F0A9E8F0B0@oracle.com>
Message-ID: <0c33b0ae-60ed-2132-ebd4-a628ea837975@oracle.com>
Thanks Karen!
Once my re-testing has completed I'll look at pushing this.
David
On 27/04/2018 7:21 AM, Karen Kinnear wrote:
> Looks good!
>
> Thank you so much David and Vladimir for all the work to cover the corner cases.
>
> thanks,
> Karen
>
>> On Apr 26, 2018, at 12:12 AM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Revised webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev.v2/
>>
>> Karen formulated an additional test scenario invoking Object methods through an interface reference, which when turned into a new testcase demonstrated that the receiver typecheck was also missing in that case for Methodhandle's from findSpecial.
>>
>> Again Vladimir Ivanov formulated the fix for this. Thanks Vladimir!
>>
>> Summary of changes from original webrev:
>>
>> - We introduce a new version of DirectMethodHandle.preparedlambdaForm that takes the caller class as a parameter, and that class is checked for being an interface (not the method's declaring class) to trigger the switch to LF_SPECIAL_IFC. (This obviously addresses one problem with invoking Object methods - as Object is not an interface - but by itself did not fix the problem.)
>>
>> - We introduce a new LambdaForm kind, DIRECT_INVOKE_SPECIAL_IFC, which we use when dealing with LF_INVSPECIAL_IFC. (This was the key in ensuring the receiver typecheck via Special.checkReceiver remained in the generated code.)
>>
>> - In the test we:
>> - introduce a new invokeDirect testcase for Object.toString(), but we need to do that via a modified jcod file (as javac generates an invokevirtual)
>> - introduce the new invokeSpecialObjectMH(I2 i) call for the MH case.
>>
>> Thanks,
>> David
>>
>> On 17/04/2018 6:48 PM, David Holmes wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200167
>>> webrev: http://cr.openjdk.java.net/~dholmes/8200167/webrev/
>>> Credit to John Rose and Vladimir Ivanov for the form of the MH fix; and to Tobias Hartmann for the C1 fix. Their help was very much appreciated (and needed!).
>>> tl;dr version: there are some places where badly formed interface method calls (which are not detected by the verifier) were missing runtime checks on the type of the receiver. Similar issues have been fixed in the past and this was a remaining hole in relation to invokespecial semantics and interface calls via MethodHandles. It also turned out there was an issue in C1 that affected direct invokespecial calls.
>>> Description of changes:
>>> - src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java
>>> Added a new form LF_INVSPECIAL_IFC for invokespecial of interface methods.
>>> - src/java.base/share/classes/java/lang/invoke/MethodHandles.java
>>> Renamed callerClass parameter to boundCallerClass, where it originates from findBoundCallerClass. The name "callerClass" is misleading because most of the time it is NULL!
>>> In getDirectMethodCommon, pass the actual caller class (lookupClass) to DirectMethodHandle.make. And correct the comment about restrictReceiver.
>>> - src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
>>> DirectMethodHandle.make now takes a callerClass parameter (which may be null).
>>> DirectMethodHandle make "receiver" parameter is renamed "refc" as it is not the receiver (it's the resolved type of the method holder ie REFC).
>>> The Special subclass now takes a "checkClass" parameter which is either refc, or callerClass. This is what we will check the receiver against.
>>> In preparedLambdaForm we switch from LF_INVSPECIAL to LF_INVSPECIAL_IFC if the target method is in an interface.
>>> In makePreparedLambdaForm we augment the needsReceiverCheck test to include LF_INVSPECIAL_IFC. (So we will not be doing a new receiver type check on all invokespecials, just those involving interface methods.)
>>> Added DMH.checkReceiver which is overridden by both the Special and Interface subclasses.
>>> - src/hotspot/share/c1/c1_Canonicalizer.cpp
>>> Don't optimize away the checkcast when it is an invokespecial receiver check.
>>> - test/jdk/java/lang/invoke/SpecialInterfaceCall.java
>>> (I've moved this test back and forth between hotspot/runtime and j.l.invoke as it spans direct calls and MH calls. But I think on balance it lands better here.)
>>> The test sets up direct interface method calls for which invokespecial is generated by javac, and similarly it creates MethodHandles with invokespecial semantics. The should-not-throw cases are trivial. The should-throw cases involve MH wizardry.
>>> The test is broken into three parts to check the behaviour on first use (when the method has to be initially resolved); on second use (to test we don't use the cpcache in a way that is invalid); and again after forcing JIT compilation of the calls.
>>> The test is run 5 times to exercise the interpreter (yes the multiple runs internal to the test are redundant in this case, but it's much simpler to just run it all than try to work out what needs to be run); the three variants of using C1, plus a C2 only run.
>>> ---
>>> Testing:
>>> - the new test of course
>>> - hotspot/runtime/*
>>> - hotspot/compiler/jsr292
>>> - jdk/java/lang/invoke
>>> - hs tiers 1 and 2
>>> - jdk tiers 1, 2 and 3
>>> Plus some related closed tests.
>>> Thanks,
>>> David
>>> -----
>
From kim.barrett at oracle.com Thu Apr 26 22:55:52 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 26 Apr 2018 18:55:52 -0400
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
readdir_r(DIR*, dirent*, dirent**)' is deprecated
In-Reply-To: <CABi63P4-Grx7KNXrfRkZX9gGFkEida4Kzz2Eh2GsoLF+xT9WvQ@mail.gmail.com>
References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
<D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
<CABi63P4-Grx7KNXrfRkZX9gGFkEida4Kzz2Eh2GsoLF+xT9WvQ@mail.gmail.com>
Message-ID: <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com>
> On Apr 25, 2018, at 10:51 AM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>
> On 24 April 2018 at 20:17, Kim Barrett <kim.barrett at oracle.com> wrote:
>>> On Apr 23, 2018, at 3:51 AM, Michal Vala <mvala at redhat.com> wrote:
>>>
>>> Hi,
>>>
>>> following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm posting updated patch replacing deprecated readdir_r with readdir. Bug ID is JDK-8179887 [2].
>>>
>>> webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
>>>
>>> I'm asking for the review and eventually sponsorship.
>>
>
> The patch looks good to me.
>
>> The change to os::readdir in os_linux.inline.hpp looks fine.
>>
>> I was going to suggest that rather than changing perfMemory_linux.cpp to use os::readdir in an
>> unusual and platform-specific way, it should instead just call ::readdir directly. However, neither
>> of those is right, and that part of the change should not be made; see
>> https://bugs.openjdk.java.net/browse/JDK-8134540
>> Much nearly duplicated code for PerfMemory support
>>
>
> I think, in the circumstances, Michal's solution is the best option at
> this point.
> 8134540 looks like a more long-term change currently scheduled for 12 (is
> anyone currently working on it?), whereas this fix could go into 11 and remove
> a couple of unneeded memory allocations.
>
>> Looking a bit deeper, there might be some additional follow-on that could be done, eliminating
>> the second argument to os::readdir.
>> windows: unused
>> bsd: freebsd also deprecated readdir_r, I think for similar reasons.
>> solaris: doc is clear about thread safety issue being about sharing the DIR*
>> aix: I haven?t looked at it, but would guess it?s similar.
>>
>> In other words, don?t operate on the DIR* from multiple threads simultaneously, and just use
>> ::readdir on non-Windows. That would all be for another RFE though.
>>
>>
>
> This also seems like a more in-depth separate change and not one that
> can be performed
> by any of us alone, as we don't test all these platforms. As it
> stands, Michal's change affects
> Linux and Linux alone, and the addition of the use of NULL will make
> it clearer that moving
> to an os:readdir is feasible on that platform.
I disagree, and still think the perfMemory_linux.cpp change should be
removed.
(1) The change to perfMemory_linux.cpp is entirely unnecessary to
address the problem this bug is about.
(2) It violates the (implied) protocol for os::readdir. If
Linux-specific code wants to invoke Linux-specific behavior, it should
do so by calling a Linux-specific API, not abuse an intended to be
portable API.
(3) It minorly interferes with some desirable future work. If there
were some significant benefit to doing so, I wouldn't give this much
weight, but I don't see a significant benefit.
(4) The only benefit is saving some rare short-term memory
allocations. I don't think that's worth the above costs.
Note that the Windows version of os::readdir also ignores the second
argument, but all callers provide it anyway.
I've opened a new CR for general os::readdir cleanup.
https://bugs.openjdk.java.net/browse/JDK-8202353
From vladimir.kozlov at oracle.com Fri Apr 27 01:15:30 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 26 Apr 2018 18:15:30 -0700
Subject: [11] RFR(XS) 8202273: [AOT] Graal does not support the CMS collector
Message-ID: <48a55052-8864-7164-63a8-351e14416efa@oracle.com>
http://cr.openjdk.java.net/~kvn/8202273/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8202273
Added new test group to avoid running AOT and JVMCI tests with CMS.
--
Thanks,
Vladimir
From tobias.hartmann at oracle.com Fri Apr 27 06:42:56 2018
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 27 Apr 2018 08:42:56 +0200
Subject: (M) RFR: 8200167: Validate more special case invocations
In-Reply-To: <4e8bbf0c-0e04-a74f-74a3-4b60ba47e48e@oracle.com>
References: <27391c2a-fd5c-8133-8e31-b8b45db157ce@oracle.com>
<a943a81b-e2da-57f2-92bd-1ef3d6fc7f72@oracle.com>
<2907289a-2915-118c-f3c0-1327798f6f80@oracle.com>
<4e8bbf0c-0e04-a74f-74a3-4b60ba47e48e@oracle.com>
Message-ID: <6af38c48-7567-3698-e4d8-8a39ee31ce48@oracle.com>
Hi David,
On 27.04.2018 00:04, David Holmes wrote:
>> src/hotspot/share/c1/c1_Canonicalizer.cpp
>> ...
>> ??void Canonicalizer::do_CheckCast????? (CheckCast*?????? x) {
>> -? if (x->klass()->is_loaded()) {
>> +? if (x->klass()->is_loaded() && !x->is_invokespecial_receiver_check())
>>
>> It seems like it's not something specific to invokespecial, but a generic problem in how interface
>> casts are handled in C1: it's not correct to eliminate the cast if obj->declared_type() is an
>> interface. I assume that's what happens in your case. FTR I'm fine with handling it separately.
>
> The above came from Tobias. If you think there is a more general issue here then we should file a
> separate bug and formulate a test case.
To clarify, I've quickly debugged this problem before going on vacation and rather than a full fix,
the intention of the above change was to quickly verify that the problem is indeed an incorrectly
eliminated receiver cast.
I'm also fine with handling this in a separate bug or to push this as a quick fix and file a follow
up bug for further investigation if other changes are necessary.
Thanks,
Tobias
From mvala at redhat.com Fri Apr 27 08:56:09 2018
From: mvala at redhat.com (Michal Vala)
Date: Fri, 27 Apr 2018 10:56:09 +0200
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
readdir_r(DIR*, dirent*, dirent**)' is deprecated
In-Reply-To: <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com>
References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
<D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
<CABi63P4-Grx7KNXrfRkZX9gGFkEida4Kzz2Eh2GsoLF+xT9WvQ@mail.gmail.com>
<403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com>
Message-ID: <aec74ecb-aeb3-4342-8ca2-1a70a56e92d3@redhat.com>
On 04/27/2018 12:55 AM, Kim Barrett wrote:
>> On Apr 25, 2018, at 10:51 AM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>>
>> On 24 April 2018 at 20:17, Kim Barrett <kim.barrett at oracle.com> wrote:
>>>> On Apr 23, 2018, at 3:51 AM, Michal Vala <mvala at redhat.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm posting updated patch replacing deprecated readdir_r with readdir. Bug ID is JDK-8179887 [2].
>>>>
>>>> webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
>>>>
>>>> I'm asking for the review and eventually sponsorship.
>>>
>>
>> The patch looks good to me.
>>
>>> The change to os::readdir in os_linux.inline.hpp looks fine.
>>>
>>> I was going to suggest that rather than changing perfMemory_linux.cpp to use os::readdir in an
>>> unusual and platform-specific way, it should instead just call ::readdir directly. However, neither
>>> of those is right, and that part of the change should not be made; see
>>> https://bugs.openjdk.java.net/browse/JDK-8134540
>>> Much nearly duplicated code for PerfMemory support
>>>
>>
>> I think, in the circumstances, Michal's solution is the best option at
>> this point.
>> 8134540 looks like a more long-term change currently scheduled for 12 (is
>> anyone currently working on it?), whereas this fix could go into 11 and remove
>> a couple of unneeded memory allocations.
>>
>>> Looking a bit deeper, there might be some additional follow-on that could be done, eliminating
>>> the second argument to os::readdir.
>>> windows: unused
>>> bsd: freebsd also deprecated readdir_r, I think for similar reasons.
>>> solaris: doc is clear about thread safety issue being about sharing the DIR*
>>> aix: I haven?t looked at it, but would guess it?s similar.
>>>
>>> In other words, don?t operate on the DIR* from multiple threads simultaneously, and just use
>>> ::readdir on non-Windows. That would all be for another RFE though.
>>>
>>>
>>
>> This also seems like a more in-depth separate change and not one that
>> can be performed
>> by any of us alone, as we don't test all these platforms. As it
>> stands, Michal's change affects
>> Linux and Linux alone, and the addition of the use of NULL will make
>> it clearer that moving
>> to an os:readdir is feasible on that platform.
>
> I disagree, and still think the perfMemory_linux.cpp change should be
> removed.
>
> (1) The change to perfMemory_linux.cpp is entirely unnecessary to
> address the problem this bug is about.
>
> (2) It violates the (implied) protocol for os::readdir. If
> Linux-specific code wants to invoke Linux-specific behavior, it should
> do so by calling a Linux-specific API, not abuse an intended to be
> portable API.
>
> (3) It minorly interferes with some desirable future work. If there
> were some significant benefit to doing so, I wouldn't give this much
> weight, but I don't see a significant benefit.
>
> (4) The only benefit is saving some rare short-term memory
> allocations. I don't think that's worth the above costs.
>
> Note that the Windows version of os::readdir also ignores the second
> argument, but all callers provide it anyway.
>
> I've opened a new CR for general os::readdir cleanup.
> https://bugs.openjdk.java.net/browse/JDK-8202353
>
Ok, if we agree on os_linux.inline.hpp part, I think it should go in. Rest can
be solved in JDK-8202353, which should imho include also removal of second
argument of os::readdir, once it's unused.
For now, proposed patch looks like this:
--- old/src/hotspot/os/linux/os_linux.inline.hpp 2018-04-20 09:16:34.498343185 +0200
+++ new/src/hotspot/os/linux/os_linux.inline.hpp 2018-04-20 09:16:34.214342670 +0200
@@ -98,26 +98,8 @@
inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf)
{
-// readdir_r has been deprecated since glibc 2.24.
-// See https://sourceware.org/bugzilla/show_bug.cgi?id=19056 for more details.
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
-
- dirent* p;
- int status;
assert(dirp != NULL, "just checking");
-
- // NOTE: Linux readdir_r (on RH 6.2 and 7.2 at least) is NOT like the POSIX
- // version. Here is the doc for this function:
- // http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_262.html
-
- if((status = ::readdir_r(dirp, dbuf, &p)) != 0) {
- errno = status;
- return NULL;
- } else
- return p;
-
-#pragma GCC diagnostic pop
+ return ::readdir(dirp);
}
inline int os::closedir(DIR *dirp) {
--
Michal Vala
OpenJDK QE
Red Hat Czech
From christoph.langer at sap.com Fri Apr 27 09:53:36 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 27 Apr 2018 09:53:36 +0000
Subject: RFR (XS) 8202367: AIX build broken after JDK-8201543 (Modularize C1
GC barriers)
Message-ID: <128aabc15c144e41be7487fee84dda7a@sap.com>
Hi,
please review a small fix for the AIX build that's broken after JDK-8201543 was pushed. We needs the include gc/shared/cardTable.hpp in gc/shared/c1/cardTableBarrierSetC1.cpp, otherwise the compiler complains about the usage of CardTable like this:
"/usr/work/d062122/OpenJDK/jdk/src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp", line 70.34: 1540-0062 (S) The incomplete class "CardTable" must not be used as a qualifier.
This is the proposed patch:
diff -r 25e6d8bb5a6e src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp
--- a/src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp Fri Apr 27 11:00:57 2018 +0200
+++ b/src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp Fri Apr 27 11:44:16 2018 +0200
@@ -24,6 +24,7 @@
#include "precompiled.hpp"
#include "gc/shared/c1/cardTableBarrierSetC1.hpp"
+#include "gc/shared/cardTable.hpp"
#include "gc/shared/cardTableBarrierSet.hpp"
#include "utilities/macros.hpp"
Bug: https://bugs.openjdk.java.net/browse/JDK-8202367
Thanks
Christoph
From erik.osterlund at oracle.com Fri Apr 27 09:57:26 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Fri, 27 Apr 2018 11:57:26 +0200
Subject: RFR (XS) 8202367: AIX build broken after JDK-8201543 (Modularize
C1 GC barriers)
In-Reply-To: <128aabc15c144e41be7487fee84dda7a@sap.com>
References: <128aabc15c144e41be7487fee84dda7a@sap.com>
Message-ID: <5AE2F406.3010108@oracle.com>
Hi,
Looks good.
Thanks,
/Erik
On 2018-04-27 11:53, Langer, Christoph wrote:
>
> Hi,
>
> please review a small fix for the AIX build that?s broken after
> JDK-8201543 was pushed. We needs the include gc/shared/cardTable.hpp
> in gc/shared/c1/cardTableBarrierSetC1.cpp, otherwise the compiler
> complains about the usage of CardTable like this:
>
> "/usr/work/d062122/OpenJDK/jdk/src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp",
> line 70.34: 1540-0062 (S) The incomplete class "CardTable" must not be
> used as a qualifier.
>
> This is the proposed patch:
>
> diff -r 25e6d8bb5a6e
> src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp
>
> --- a/src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp Fri Apr
> 27 11:00:57 2018 +0200
>
> +++ b/src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp Fri Apr
> 27 11:44:16 2018 +0200
>
> @@ -24,6 +24,7 @@
>
> #include "precompiled.hpp"
>
> #include "gc/shared/c1/cardTableBarrierSetC1.hpp"
>
> +#include "gc/shared/cardTable.hpp"
>
> #include "gc/shared/cardTableBarrierSet.hpp"
>
> #include "utilities/macros.hpp"
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202367
> <https://bugs.openjdk.java.net/browse/JDK-8202367>
>
> Thanks
>
> Christoph
>
From shade at redhat.com Fri Apr 27 09:55:44 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 27 Apr 2018 11:55:44 +0200
Subject: RFR (XS) 8202367: AIX build broken after JDK-8201543 (Modularize
C1 GC barriers)
In-Reply-To: <128aabc15c144e41be7487fee84dda7a@sap.com>
References: <128aabc15c144e41be7487fee84dda7a@sap.com>
Message-ID: <6022bb6c-d28c-31d4-0cbf-78522527dfca@redhat.com>
On 04/27/2018 11:53 AM, Langer, Christoph wrote:
> Hi,
>
> please review a small fix for the AIX build that's broken after JDK-8201543 was pushed. We needs the include gc/shared/cardTable.hpp in gc/shared/c1/cardTableBarrierSetC1.cpp, otherwise the compiler complains about the usage of CardTable like this:
> "/usr/work/d062122/OpenJDK/jdk/src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp", line 70.34: 1540-0062 (S) The incomplete class "CardTable" must not be used as a qualifier.
>
> This is the proposed patch:
>
> diff -r 25e6d8bb5a6e src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp
> --- a/src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp Fri Apr 27 11:00:57 2018 +0200
> +++ b/src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp Fri Apr 27 11:44:16 2018 +0200
> @@ -24,6 +24,7 @@
>
> #include "precompiled.hpp"
> #include "gc/shared/c1/cardTableBarrierSetC1.hpp"
> +#include "gc/shared/cardTable.hpp"
> #include "gc/shared/cardTableBarrierSet.hpp"
> #include "utilities/macros.hpp"
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202367
Looks good and trivial to me.
-Aleksey
From martin.doerr at sap.com Fri Apr 27 11:10:29 2018
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 27 Apr 2018 11:10:29 +0000
Subject: RFR (XS) 8202367: AIX build broken after JDK-8201543 (Modularize
C1 GC barriers)
In-Reply-To: <128aabc15c144e41be7487fee84dda7a@sap.com>
References: <128aabc15c144e41be7487fee84dda7a@sap.com>
Message-ID: <cf16abb2aebc4de5a27808f0838b2fb2@sap.com>
Hi Christoph,
looks good. Thanks for fixing.
Best regards,
Martin
-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Langer, Christoph
Sent: Freitag, 27. April 2018 11:54
To: hotspot-dev at openjdk.java.net
Cc: Baesken, Matthias <matthias.baesken at sap.com>
Subject: RFR (XS) 8202367: AIX build broken after JDK-8201543 (Modularize C1 GC barriers)
Hi,
please review a small fix for the AIX build that's broken after JDK-8201543 was pushed. We needs the include gc/shared/cardTable.hpp in gc/shared/c1/cardTableBarrierSetC1.cpp, otherwise the compiler complains about the usage of CardTable like this:
"/usr/work/d062122/OpenJDK/jdk/src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp", line 70.34: 1540-0062 (S) The incomplete class "CardTable" must not be used as a qualifier.
This is the proposed patch:
diff -r 25e6d8bb5a6e src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp
--- a/src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp Fri Apr 27 11:00:57 2018 +0200
+++ b/src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp Fri Apr 27 11:44:16 2018 +0200
@@ -24,6 +24,7 @@
#include "precompiled.hpp"
#include "gc/shared/c1/cardTableBarrierSetC1.hpp"
+#include "gc/shared/cardTable.hpp"
#include "gc/shared/cardTableBarrierSet.hpp"
#include "utilities/macros.hpp"
Bug: https://bugs.openjdk.java.net/browse/JDK-8202367
Thanks
Christoph
From christoph.langer at sap.com Fri Apr 27 12:13:40 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 27 Apr 2018 12:13:40 +0000
Subject: RFR (XS) 8202367: AIX build broken after JDK-8201543 (Modularize
C1 GC barriers)
In-Reply-To: <cf16abb2aebc4de5a27808f0838b2fb2@sap.com>
References: <128aabc15c144e41be7487fee84dda7a@sap.com>
<cf16abb2aebc4de5a27808f0838b2fb2@sap.com>
Message-ID: <ca9b3dc085494840bc11b6d5ebe502b0@sap.com>
Thanks, guys, for reviewing so quickly. I have pushed it.
> -----Original Message-----
> From: Doerr, Martin
> Sent: Freitag, 27. April 2018 13:10
> To: Langer, Christoph <christoph.langer at sap.com>; hotspot-
> dev at openjdk.java.net
> Cc: Baesken, Matthias <matthias.baesken at sap.com>
> Subject: RE: RFR (XS) 8202367: AIX build broken after JDK-8201543
> (Modularize C1 GC barriers)
>
> Hi Christoph,
>
> looks good. Thanks for fixing.
>
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of Langer, Christoph
> Sent: Freitag, 27. April 2018 11:54
> To: hotspot-dev at openjdk.java.net
> Cc: Baesken, Matthias <matthias.baesken at sap.com>
> Subject: RFR (XS) 8202367: AIX build broken after JDK-8201543 (Modularize
> C1 GC barriers)
>
> Hi,
>
> please review a small fix for the AIX build that's broken after JDK-8201543
> was pushed. We needs the include gc/shared/cardTable.hpp in
> gc/shared/c1/cardTableBarrierSetC1.cpp, otherwise the compiler complains
> about the usage of CardTable like this:
> "/usr/work/d062122/OpenJDK/jdk/src/hotspot/share/gc/shared/c1/cardTab
> leBarrierSetC1.cpp", line 70.34: 1540-0062 (S) The incomplete class
> "CardTable" must not be used as a qualifier.
>
> This is the proposed patch:
>
> diff -r 25e6d8bb5a6e
> src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp
> --- a/src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp Fri Apr 27
> 11:00:57 2018 +0200
> +++ b/src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp Fri Apr 27
> 11:44:16 2018 +0200
> @@ -24,6 +24,7 @@
>
> #include "precompiled.hpp"
> #include "gc/shared/c1/cardTableBarrierSetC1.hpp"
> +#include "gc/shared/cardTable.hpp"
> #include "gc/shared/cardTableBarrierSet.hpp"
> #include "utilities/macros.hpp"
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202367
>
> Thanks
> Christoph
From erik.gahlin at oracle.com Fri Apr 27 13:25:17 2018
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Fri, 27 Apr 2018 15:25:17 +0200
Subject: RFR(XL): 8199712: Flight Recorder
In-Reply-To: <0e2f481f-0c7c-5dfa-c37b-1b453b3b2d8d@oracle.com>
References: <5AE0612F.8060200@oracle.com>
<0e2f481f-0c7c-5dfa-c37b-1b453b3b2d8d@oracle.com>
Message-ID: <5AE324BD.4010109@oracle.com>
Hi Magnus,
Sorry about not including build-dev. See comments inline.
>
> On 2018-04-25 13:06, Erik Gahlin wrote:
>> Greetings,
>>
>> Could I have a review of 8199712: Flight Recorder
>>
>> As mentioned in the preview [1] the tracing backend has been removed.
>> Event metadata has been consolidated into a single XML file and event
>> classes are now generated by GenerateJfrFiles.java.
>>
>> Tests have been run on Linux-x64, Windows-x64 and MaxOSX-x64.
>>
>> For details about the feature, see the JEP:
>> https://bugs.openjdk.java.net/browse/JDK-8193393
>>
>> Webrev:
>> http://cr.openjdk.java.net/~egahlin/8199712.0/
> Hi Erik,
>
> When posting build changes (files in "make/*"), please always include
> build-dev. Thanks! :-)
>
> This review is for build changes only.
>
> * make/RunTestsPrebuiltSpec.gmk: This file has only a copyright year
> change. It can be reverted.
>
Will fix.
> * make/copy/Copy-jdk.jfr.gmk:
> COPY_HOTSPOT_TRACE_FILES should be renamed to something like
> COPY_JFR_METADATA.
>
Will fix.
> The second part is better off rewritten using SetupCopyFiles.
>
> Something like this, written on-the-fly, so might not work. (Email me
> privately if it does not work and you need help.)
>
> JFR_CONF_DIR := $(TOPDIR)/src/jdk.jfr/share/conf/jfr
>
> $(eval $(call SetupCopyFiles, COPY_JFR_CONF, \
> DEST := $(LIB_DST_DIR)/jfr, \
> FILES := $(wildcard $(JFR_CONF_DIR)/*.jfc), \
> FLATTEN := true, \
> ))
>
> TARGETS += $(COPY_JFR_CONF)
>
Will look into it.
> * make/autoconf/hotspot.m4:
> It's a bit unfortunate with the --enable-jfr option. Ideally, this
> should be handled only as a JVM feature (--with-jvm-features=jfr). Try
> this piece of code instead: (Not tested, but should work.)
>
> diff --git a/make/autoconf/hotspot.m4 b/make/autoconf/hotspot.m4
> --- a/make/autoconf/hotspot.m4
> +++ b/make/autoconf/hotspot.m4
> @@ -26,7 +26,7 @@
> # All valid JVM features, regardless of platform
> VALID_JVM_FEATURES="compiler1 compiler2 zero minimal dtrace jvmti
> jvmci \
> graal vm-structs jni-check services management all-gcs nmt cds \
> - static-build link-time-opt aot"
> + static-build link-time-opt aot jfr"
>
> # All valid JVM variants
> VALID_JVM_VARIANTS="server client minimal core zero custom"
> @@ -313,6 +313,11 @@
> AC_MSG_ERROR([Specified JVM feature 'vm-structs' requires feature
> 'all-gcs'])
> fi
>
> + # Enable JFR by default, except on linux-sparcv9 and on minimal.
> + if test "x$OPENJDK_TARGET_OS" != xlinux || test
> "x$OPENJDK_TARGET_CPU" != xsparcv9; then
> + NON_MINIMAL_FEATURES="$NON_MINIMAL_FEATURES jfr"
> + fi
> +
> # Turn on additional features based on other parts of configure
> if test "x$INCLUDE_DTRACE" = "xtrue"; then
> JVM_FEATURES="$JVM_FEATURES dtrace"
>
Will try it.
Thanks
Erik
> Otherwise, build changes look good!
>
> /Magnus
>
>
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8199712
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031359.html
>>
>> Thanks
>> Erik and Markus
>
From daniel.daugherty at oracle.com Fri Apr 27 13:55:02 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 27 Apr 2018 09:55:02 -0400
Subject: [11] RFR(XS) 8202273: [AOT] Graal does not support the CMS
collector
In-Reply-To: <48a55052-8864-7164-63a8-351e14416efa@oracle.com>
References: <48a55052-8864-7164-63a8-351e14416efa@oracle.com>
Message-ID: <18946fe7-6c07-dc47-c6d8-91652b912ee5@oracle.com>
On 4/26/18 9:15 PM, Vladimir Kozlov wrote:
> http://cr.openjdk.java.net/~kvn/8202273/webrev.00/
test/hotspot/jtreg/TEST.groups
??? No comments. (hotspot_compiler_all_gcs is used by the task
??? definitions from the closed side).
Thumbs up.
Dan
> https://bugs.openjdk.java.net/browse/JDK-8202273
>
> Added new test group to avoid running AOT and JVMCI tests with CMS.
>
From ChrisPhi at LGonQn.Org Fri Apr 27 14:19:35 2018
From: ChrisPhi at LGonQn.Org (Chris Phillips)
Date: Fri, 27 Apr 2018 10:19:35 -0400
Subject: [11] Request for sponsor to putback fix for JDK-8201509: Zero : S390
31bit (S390 and not _LP64) atomic_copy64 inline assembler is wrong
Message-ID: <0e2abe6a-38ac-88db-f87f-7413e8b162ff@LGonQn.Org>
Hi,
I'd like find a JDK11 committer to sponsor and putback this
fix :
JDK-8201509: Zero : S390 31bit (S390 and not _LP64) atomic_copy64 inline
assembler is wrong
Bug:
https://bugs.openjdk.java.net/browse/JDK-8201509
WebRev:
http://cr.openjdk.java.net/~chrisphi/JDK-8201509/webrev.3
Changeset:
http://cr.openjdk.java.net/~chrisphi/JDK-8201509/webrev.3/jdk.changeset
Review thread:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2018April/031626.html
Testing: Builds itself on s390 31bit with some other local patches to
avoid type mismatches.
Chris
From shade at redhat.com Fri Apr 27 14:34:17 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 27 Apr 2018 16:34:17 +0200
Subject: [11] Request for sponsor to putback fix for JDK-8201509: Zero :
S390 31bit (S390 and not _LP64) atomic_copy64 inline assembler is wrong
In-Reply-To: <0e2abe6a-38ac-88db-f87f-7413e8b162ff@LGonQn.Org>
References: <0e2abe6a-38ac-88db-f87f-7413e8b162ff@LGonQn.Org>
Message-ID: <7b4722bd-7653-c9a2-721c-da103c270ee8@redhat.com>
I'll do it.
In future, you don't need to start another thread for requests like these, you can just ask for the
sponsor in the same RFR thread at hotspot-dev@
-Aleksey
On 04/27/2018 04:19 PM, Chris Phillips wrote:
> Hi,
>
> I'd like find a JDK11 committer to sponsor and putback this
> fix :
>
> JDK-8201509: Zero : S390 31bit (S390 and not _LP64) atomic_copy64 inline
> assembler is wrong
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8201509
>
> WebRev:
> http://cr.openjdk.java.net/~chrisphi/JDK-8201509/webrev.3
> Changeset:
> http://cr.openjdk.java.net/~chrisphi/JDK-8201509/webrev.3/jdk.changeset
>
> Review thread:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018April/031626.html
>
> Testing: Builds itself on s390 31bit with some other local patches to
> avoid type mismatches.
>
> Chris
>
From vladimir.kozlov at oracle.com Fri Apr 27 15:20:59 2018
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 27 Apr 2018 08:20:59 -0700
Subject: [11] RFR(XS) 8202273: [AOT] Graal does not support the CMS
collector
In-Reply-To: <18946fe7-6c07-dc47-c6d8-91652b912ee5@oracle.com>
References: <48a55052-8864-7164-63a8-351e14416efa@oracle.com>
<18946fe7-6c07-dc47-c6d8-91652b912ee5@oracle.com>
Message-ID: <d84536be-b43a-a560-a890-16f8184531ab@oracle.com>
Thank you, Dan, for reviews.
Vladimir
On 4/27/18 6:55 AM, Daniel D. Daugherty wrote:
> On 4/26/18 9:15 PM, Vladimir Kozlov wrote:
>> http://cr.openjdk.java.net/~kvn/8202273/webrev.00/
>
> test/hotspot/jtreg/TEST.groups
> ??? No comments. (hotspot_compiler_all_gcs is used by the task
> ??? definitions from the closed side).
>
> Thumbs up.
>
> Dan
>
>
>
>> https://bugs.openjdk.java.net/browse/JDK-8202273
>>
>> Added new test group to avoid running AOT and JVMCI tests with CMS.
>>
>
From thomas.stuefe at gmail.com Fri Apr 27 16:26:39 2018
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 27 Apr 2018 18:26:39 +0200
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
readdir_r(DIR*, dirent*, dirent**)' is deprecated
In-Reply-To: <aec74ecb-aeb3-4342-8ca2-1a70a56e92d3@redhat.com>
References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
<D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
<CABi63P4-Grx7KNXrfRkZX9gGFkEida4Kzz2Eh2GsoLF+xT9WvQ@mail.gmail.com>
<403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com>
<aec74ecb-aeb3-4342-8ca2-1a70a56e92d3@redhat.com>
Message-ID: <CAA-vtUzkFi-oKySpBqk7ne-NJ6AiMcz5e1FcSEqcWfoPDt9dUw@mail.gmail.com>
This patch looks fine.
I also welcome Kim's proposal of reverting back to readdir(). We
should do this for JDK libraries too, there are still open issues
(e.g. https://bugs.openjdk.java.net/browse/JDK-8166372).
Best Regards, Thomas
On Fri, Apr 27, 2018 at 10:56 AM, Michal Vala <mvala at redhat.com> wrote:
>
>
> On 04/27/2018 12:55 AM, Kim Barrett wrote:
>>>
>>> On Apr 25, 2018, at 10:51 AM, Andrew Hughes <gnu.andrew at redhat.com>
>>> wrote:
>>>
>>> On 24 April 2018 at 20:17, Kim Barrett <kim.barrett at oracle.com> wrote:
>>>>>
>>>>> On Apr 23, 2018, at 3:51 AM, Michal Vala <mvala at redhat.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm
>>>>> posting updated patch replacing deprecated readdir_r with readdir. Bug ID is
>>>>> JDK-8179887 [2].
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
>>>>>
>>>>> I'm asking for the review and eventually sponsorship.
>>>>
>>>>
>>>
>>> The patch looks good to me.
>>>
>>>> The change to os::readdir in os_linux.inline.hpp looks fine.
>>>>
>>>> I was going to suggest that rather than changing perfMemory_linux.cpp to
>>>> use os::readdir in an
>>>> unusual and platform-specific way, it should instead just call ::readdir
>>>> directly. However, neither
>>>> of those is right, and that part of the change should not be made; see
>>>> https://bugs.openjdk.java.net/browse/JDK-8134540
>>>> Much nearly duplicated code for PerfMemory support
>>>>
>>>
>>> I think, in the circumstances, Michal's solution is the best option at
>>> this point.
>>> 8134540 looks like a more long-term change currently scheduled for 12 (is
>>> anyone currently working on it?), whereas this fix could go into 11 and
>>> remove
>>> a couple of unneeded memory allocations.
>>>
>>>> Looking a bit deeper, there might be some additional follow-on that
>>>> could be done, eliminating
>>>> the second argument to os::readdir.
>>>> windows: unused
>>>> bsd: freebsd also deprecated readdir_r, I think for similar reasons.
>>>> solaris: doc is clear about thread safety issue being about sharing the
>>>> DIR*
>>>> aix: I haven?t looked at it, but would guess it?s similar.
>>>>
>>>> In other words, don?t operate on the DIR* from multiple threads
>>>> simultaneously, and just use
>>>> ::readdir on non-Windows. That would all be for another RFE though.
>>>>
>>>>
>>>
>>> This also seems like a more in-depth separate change and not one that
>>> can be performed
>>> by any of us alone, as we don't test all these platforms. As it
>>> stands, Michal's change affects
>>> Linux and Linux alone, and the addition of the use of NULL will make
>>> it clearer that moving
>>> to an os:readdir is feasible on that platform.
>>
>>
>> I disagree, and still think the perfMemory_linux.cpp change should be
>> removed.
>>
>> (1) The change to perfMemory_linux.cpp is entirely unnecessary to
>> address the problem this bug is about.
>>
>> (2) It violates the (implied) protocol for os::readdir. If
>> Linux-specific code wants to invoke Linux-specific behavior, it should
>> do so by calling a Linux-specific API, not abuse an intended to be
>> portable API.
>>
>> (3) It minorly interferes with some desirable future work. If there
>> were some significant benefit to doing so, I wouldn't give this much
>> weight, but I don't see a significant benefit.
>>
>> (4) The only benefit is saving some rare short-term memory
>> allocations. I don't think that's worth the above costs.
>>
>> Note that the Windows version of os::readdir also ignores the second
>> argument, but all callers provide it anyway.
>>
>> I've opened a new CR for general os::readdir cleanup.
>> https://bugs.openjdk.java.net/browse/JDK-8202353
>>
>
> Ok, if we agree on os_linux.inline.hpp part, I think it should go in. Rest
> can be solved in JDK-8202353, which should imho include also removal of
> second argument of os::readdir, once it's unused.
>
> For now, proposed patch looks like this:
>
> --- old/src/hotspot/os/linux/os_linux.inline.hpp 2018-04-20
> 09:16:34.498343185 +0200
> +++ new/src/hotspot/os/linux/os_linux.inline.hpp 2018-04-20
> 09:16:34.214342670 +0200
> @@ -98,26 +98,8 @@
>
> inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf)
> {
> -// readdir_r has been deprecated since glibc 2.24.
> -// See https://sourceware.org/bugzilla/show_bug.cgi?id=19056 for more
> details.
> -#pragma GCC diagnostic push
> -#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> -
> - dirent* p;
> - int status;
> assert(dirp != NULL, "just checking");
> -
> - // NOTE: Linux readdir_r (on RH 6.2 and 7.2 at least) is NOT like the
> POSIX
> - // version. Here is the doc for this function:
> - // http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_262.html
> -
> - if((status = ::readdir_r(dirp, dbuf, &p)) != 0) {
> - errno = status;
> - return NULL;
> - } else
> - return p;
> -
> -#pragma GCC diagnostic pop
> + return ::readdir(dirp);
> }
>
> inline int os::closedir(DIR *dirp) {
>
>
>
>
> --
> Michal Vala
> OpenJDK QE
> Red Hat Czech
From edward.nevill at gmail.com Fri Apr 27 16:39:29 2018
From: edward.nevill at gmail.com (Edward Nevill)
Date: Fri, 27 Apr 2018 17:39:29 +0100
Subject: RFR 8201786: Modularize interpreter GC barriers: leftovers for
ARM32
In-Reply-To: <4d22aacb-aa0d-4423-1a22-775e2be7eeaf@redhat.com>
References: <4d22aacb-aa0d-4423-1a22-775e2be7eeaf@redhat.com>
Message-ID: <1524847169.9114.6.camel@gmail.com>
On Thu, 2018-04-26 at 17:55 +0200, Aleksey Shipilev wrote:
> http://cr.openjdk.java.net/~shade/8201786/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8201786
>
> This finishes up the work for interpreter GC barriers modularization
> [1] for ARM32. My interest is
> having a clean Epsilon GC patch, and this is the only remaining bit.
> The change is mostly about
> moving the code around, but in some cases we have to replace the
> calls to "naked" stores with the
> appropriate BSAsm calls too. There is a fair amount of symmetry with
> the x86 implementation, you may
> want to cross-reference that during reviews.
>
> Unfortunately, I have no way to test this thing thoroughly, except
> for running simple apps on Raspi
> 3 with the cross-compiled build. The largest app I tried was Wildfly
> Swarm demo with both Serial GC
> (which covers CardTableBS) and G1 (which covers G1BS). More testing
> is appreciated!
>
Hi Aleksey,
I have done a release build on a Samsung Chromebook (armv7l) and also
on an arm v8 system (in a 32 bit chroot). I also did a slowdebug build
on the arm v8 system.
I have run jtreg hotspot test (less the jcstress tests) on arm v8 with
the following results
Test results: passed: 1,493; failed: 45; error: 100
There were no fatal errors in any of the tests.
What other test/options can I run that would be useful to you? I have
jtreg & jcstress but I can download other tests as necessary.
All the best,
Ed.
From kim.barrett at oracle.com Fri Apr 27 16:50:04 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 27 Apr 2018 12:50:04 -0400
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
readdir_r(DIR*, dirent*, dirent**)' is deprecated
In-Reply-To: <aec74ecb-aeb3-4342-8ca2-1a70a56e92d3@redhat.com>
References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
<D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
<CABi63P4-Grx7KNXrfRkZX9gGFkEida4Kzz2Eh2GsoLF+xT9WvQ@mail.gmail.com>
<403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com>
<aec74ecb-aeb3-4342-8ca2-1a70a56e92d3@redhat.com>
Message-ID: <AA869CB2-1921-4DDC-A1FE-28394880F294@oracle.com>
> On Apr 27, 2018, at 4:56 AM, Michal Vala <mvala at redhat.com> wrote:
>
>
>
> On 04/27/2018 12:55 AM, Kim Barrett wrote:
>>> On Apr 25, 2018, at 10:51 AM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>>>
>>> On 24 April 2018 at 20:17, Kim Barrett <kim.barrett at oracle.com> wrote:
>>>>> On Apr 23, 2018, at 3:51 AM, Michal Vala <mvala at redhat.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm posting updated patch replacing deprecated readdir_r with readdir. Bug ID is JDK-8179887 [2].
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
>>>>>
>>>>> I'm asking for the review and eventually sponsorship.
>>>>
>>>
>>> The patch looks good to me.
>>>
>>>> The change to os::readdir in os_linux.inline.hpp looks fine.
>>>>
>>>> I was going to suggest that rather than changing perfMemory_linux.cpp to use os::readdir in an
>>>> unusual and platform-specific way, it should instead just call ::readdir directly. However, neither
>>>> of those is right, and that part of the change should not be made; see
>>>> https://bugs.openjdk.java.net/browse/JDK-8134540
>>>> Much nearly duplicated code for PerfMemory support
>>>>
>>>
>>> I think, in the circumstances, Michal's solution is the best option at
>>> this point.
>>> 8134540 looks like a more long-term change currently scheduled for 12 (is
>>> anyone currently working on it?), whereas this fix could go into 11 and remove
>>> a couple of unneeded memory allocations.
>>>
>>>> Looking a bit deeper, there might be some additional follow-on that could be done, eliminating
>>>> the second argument to os::readdir.
>>>> windows: unused
>>>> bsd: freebsd also deprecated readdir_r, I think for similar reasons.
>>>> solaris: doc is clear about thread safety issue being about sharing the DIR*
>>>> aix: I haven?t looked at it, but would guess it?s similar.
>>>>
>>>> In other words, don?t operate on the DIR* from multiple threads simultaneously, and just use
>>>> ::readdir on non-Windows. That would all be for another RFE though.
>>>>
>>>>
>>>
>>> This also seems like a more in-depth separate change and not one that
>>> can be performed
>>> by any of us alone, as we don't test all these platforms. As it
>>> stands, Michal's change affects
>>> Linux and Linux alone, and the addition of the use of NULL will make
>>> it clearer that moving
>>> to an os:readdir is feasible on that platform.
>> I disagree, and still think the perfMemory_linux.cpp change should be
>> removed.
>> (1) The change to perfMemory_linux.cpp is entirely unnecessary to
>> address the problem this bug is about.
>> (2) It violates the (implied) protocol for os::readdir. If
>> Linux-specific code wants to invoke Linux-specific behavior, it should
>> do so by calling a Linux-specific API, not abuse an intended to be
>> portable API.
>> (3) It minorly interferes with some desirable future work. If there
>> were some significant benefit to doing so, I wouldn't give this much
>> weight, but I don't see a significant benefit.
>> (4) The only benefit is saving some rare short-term memory
>> allocations. I don't think that's worth the above costs.
>> Note that the Windows version of os::readdir also ignores the second
>> argument, but all callers provide it anyway.
>> I've opened a new CR for general os::readdir cleanup.
>> https://bugs.openjdk.java.net/browse/JDK-8202353
>
> Ok, if we agree on os_linux.inline.hpp part, I think it should go in. Rest can be solved in JDK-8202353, which should imho include also removal of second argument of os::readdir, once it's unused.
>
> For now, proposed patch looks like this:
>
> --- old/src/hotspot/os/linux/os_linux.inline.hpp 2018-04-20 09:16:34.498343185 +0200
> +++ new/src/hotspot/os/linux/os_linux.inline.hpp 2018-04-20 09:16:34.214342670 +0200
> @@ -98,26 +98,8 @@
>
> inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf)
> {
> -// readdir_r has been deprecated since glibc 2.24.
> -// See https://sourceware.org/bugzilla/show_bug.cgi?id=19056 for more details.
> -#pragma GCC diagnostic push
> -#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> -
> - dirent* p;
> - int status;
> assert(dirp != NULL, "just checking");
> -
> - // NOTE: Linux readdir_r (on RH 6.2 and 7.2 at least) is NOT like the POSIX
> - // version. Here is the doc for this function:
> - // http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_262.html
> -
> - if((status = ::readdir_r(dirp, dbuf, &p)) != 0) {
> - errno = status;
> - return NULL;
> - } else
> - return p;
> -
> -#pragma GCC diagnostic pop
> + return ::readdir(dirp);
> }
>
> inline int os::closedir(DIR *dirp) {
This looks good.
From shade at redhat.com Fri Apr 27 16:56:17 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 27 Apr 2018 18:56:17 +0200
Subject: RFR 8201786: Modularize interpreter GC barriers: leftovers for
ARM32
In-Reply-To: <1524847169.9114.6.camel@gmail.com>
References: <4d22aacb-aa0d-4423-1a22-775e2be7eeaf@redhat.com>
<1524847169.9114.6.camel@gmail.com>
Message-ID: <668e8a59-cba1-a2ce-48a0-cf9cfcde032b@redhat.com>
On 04/27/2018 06:39 PM, Edward Nevill wrote:
> On Thu, 2018-04-26 at 17:55 +0200, Aleksey Shipilev wrote:
>> http://cr.openjdk.java.net/~shade/8201786/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8201786
>
> I have done a release build on a Samsung Chromebook (armv7l) and also
> on an arm v8 system (in a 32 bit chroot). I also did a slowdebug build
> on the arm v8 system.
Thank you!
> I have run jtreg hotspot test (less the jcstress tests) on arm v8 with
> the following results
>
> Test results: passed: 1,493; failed: 45; error: 100
>
> There were no fatal errors in any of the tests.
It is hard to interpret these numbers. Does this mean there are 45 new failures and 100 new errors?
> What other test/options can I run that would be useful to you? I have
> jtreg & jcstress but I can download other tests as necessary.
I think general hotspot_gc jtreg tests are sufficient.
Thanks,
-Aleksey
From boris.ulasevich at bell-sw.com Fri Apr 27 18:49:42 2018
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Fri, 27 Apr 2018 21:49:42 +0300
Subject: RFR 8201786: Modularize interpreter GC barriers: leftovers for
ARM32
In-Reply-To: <4d22aacb-aa0d-4423-1a22-775e2be7eeaf@redhat.com>
References: <4d22aacb-aa0d-4423-1a22-775e2be7eeaf@redhat.com>
Message-ID: <d87ff827-97f9-5abe-b0db-e7c7b3d4af4f@bell-sw.com>
Hi Alexey,
Thank you for doing this job!
I have checked your change with [JCK vm+lang subset] X [G1|SerialGC] on
Raspi 2 - Passed Ok.
Boris
26.04.2018 18:55, Aleksey Shipilev ?????:
> http://cr.openjdk.java.net/~shade/8201786/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8201786
>
> This finishes up the work for interpreter GC barriers modularization [1] for ARM32. My interest is
> having a clean Epsilon GC patch, and this is the only remaining bit. The change is mostly about
> moving the code around, but in some cases we have to replace the calls to "naked" stores with the
> appropriate BSAsm calls too. There is a fair amount of symmetry with the x86 implementation, you may
> want to cross-reference that during reviews.
>
> Unfortunately, I have no way to test this thing thoroughly, except for running simple apps on Raspi
> 3 with the cross-compiled build. The largest app I tried was Wildfly Swarm demo with both Serial GC
> (which covers CardTableBS) and G1 (which covers G1BS). More testing is appreciated!
>
> Testing: arm32-hflt cross-build, some apps with Serial/G1 on Raspi 3
>
> Thanks,
> -Aleksey
>
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8201786
>
From daniel.daugherty at oracle.com Fri Apr 27 19:25:43 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 27 Apr 2018 15:25:43 -0400
Subject: URGENT RFR(XS): 8202386 [BACKOUT] fix for 8200235
Message-ID: <5b2927f5-4703-39d7-35f4-0894cf6bb59e@oracle.com>
Greetings,
Recent testing has revealed an issue with the following fix:
??? JDK-8200235 Generalize jniFastGetField jobject/jweak resolve
??? https://bugs.openjdk.java.net/browse/JDK-8200235
The following bug is tracking the new failure mode:
??? JDK-8202381 (Solaris) SIGBUS in # V [libjvm.so+0xcee494]
jni_GetIntField+0x224
??? https://bugs.openjdk.java.net/browse/JDK-8202381
The following bug is being used to backout the fix for JDK-8200235:
??? JDK-8202386 [BACKOUT] fix for 8200235
??? https://bugs.openjdk.java.net/browse/JDK-8202386
Here's the backout webrev:
http://cr.openjdk.java.net/~dcubed/8202386-webrev/0_for_jdk_jdk/
The backout was generated by:
??? $ hg log -v -r 4745598b307f
??? changeset:?? 49898:4745598b307f
??? user:??????? eosterlund
??? date:??????? Thu Apr 26 11:56:24 2018 +0200
??? files:
src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp
src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp
src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp
src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp
src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp
src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp
src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp
src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp
src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
??? description:
??? 8200235: Generalize jniFastGetField jobject/jweak resolve
??? Reviewed-by: kbarrett, dholmes
??? $ hg backout 4745598b307f
??? 9 files updated, 0 files merged, 0 files removed, 0 files unresolved
??? changeset 4745598b307f backed out, don't forget to commit.
? ? $ hg commit
? ? $ hg log -v -r tip
??? changeset:?? 49917:a1765a10c340
??? tag:???????? tip
??? user:??????? dcubed
??? date:??????? Fri Apr 27 14:56:20 2018 -0400
??? files:
src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp
src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp
src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp
src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp
src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp
src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp
src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp
src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp
src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
??? description:
??? Merge
I sanity checked the backout with:
$ hg diff -r 49897 `cat file.list` | wc
?????? 0?????? 0?????? 0
which compares the changeset before 49898:4745598b307f
with the current tip. All is good.
Dan
From jesper.wilhelmsson at oracle.com Fri Apr 27 19:34:31 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Fri, 27 Apr 2018 21:34:31 +0200
Subject: URGENT RFR(XS): 8202386 [BACKOUT] fix for 8200235
In-Reply-To: <5b2927f5-4703-39d7-35f4-0894cf6bb59e@oracle.com>
References: <5b2927f5-4703-39d7-35f4-0894cf6bb59e@oracle.com>
Message-ID: <C87E84DE-E729-436D-84FF-FB594DEC54AB@oracle.com>
Looks good!
/Jesper
> On 27 Apr 2018, at 21:25, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>
> Greetings,
>
> Recent testing has revealed an issue with the following fix:
>
> JDK-8200235 Generalize jniFastGetField jobject/jweak resolve
> https://bugs.openjdk.java.net/browse/JDK-8200235
>
> The following bug is tracking the new failure mode:
>
> JDK-8202381 (Solaris) SIGBUS in # V [libjvm.so+0xcee494] jni_GetIntField+0x224
> https://bugs.openjdk.java.net/browse/JDK-8202381
>
> The following bug is being used to backout the fix for JDK-8200235:
>
> JDK-8202386 [BACKOUT] fix for 8200235
> https://bugs.openjdk.java.net/browse/JDK-8202386
>
>
> Here's the backout webrev:
>
> http://cr.openjdk.java.net/~dcubed/8202386-webrev/0_for_jdk_jdk/
>
> The backout was generated by:
>
> $ hg log -v -r 4745598b307f
> changeset: 49898:4745598b307f
> user: eosterlund
> date: Thu Apr 26 11:56:24 2018 +0200
> files: src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
> description:
> 8200235: Generalize jniFastGetField jobject/jweak resolve
> Reviewed-by: kbarrett, dholmes
>
> $ hg backout 4745598b307f
> 9 files updated, 0 files merged, 0 files removed, 0 files unresolved
> changeset 4745598b307f backed out, don't forget to commit.
>
> $ hg commit
>
> $ hg log -v -r tip
> changeset: 49917:a1765a10c340
> tag: tip
> user: dcubed
> date: Fri Apr 27 14:56:20 2018 -0400
> files: src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
> description:
> Merge
>
> I sanity checked the backout with:
>
>
> $ hg diff -r 49897 `cat file.list` | wc
> 0 0 0
>
> which compares the changeset before 49898:4745598b307f
> with the current tip. All is good.
>
> Dan
>
From daniel.daugherty at oracle.com Fri Apr 27 19:35:04 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 27 Apr 2018 15:35:04 -0400
Subject: URGENT RFR(XS): 8202386 [BACKOUT] fix for 8200235
In-Reply-To: <C87E84DE-E729-436D-84FF-FB594DEC54AB@oracle.com>
References: <5b2927f5-4703-39d7-35f4-0894cf6bb59e@oracle.com>
<C87E84DE-E729-436D-84FF-FB594DEC54AB@oracle.com>
Message-ID: <88d29261-fd42-2f11-3759-4b48be4f6ce9@oracle.com>
Thanks Jesper!
Dan
On 4/27/18 3:34 PM, jesper.wilhelmsson at oracle.com wrote:
> Looks good!
> /Jesper
>
>> On 27 Apr 2018, at 21:25, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>>
>> Greetings,
>>
>> Recent testing has revealed an issue with the following fix:
>>
>> JDK-8200235 Generalize jniFastGetField jobject/jweak resolve
>> https://bugs.openjdk.java.net/browse/JDK-8200235
>>
>> The following bug is tracking the new failure mode:
>>
>> JDK-8202381 (Solaris) SIGBUS in # V [libjvm.so+0xcee494] jni_GetIntField+0x224
>> https://bugs.openjdk.java.net/browse/JDK-8202381
>>
>> The following bug is being used to backout the fix for JDK-8200235:
>>
>> JDK-8202386 [BACKOUT] fix for 8200235
>> https://bugs.openjdk.java.net/browse/JDK-8202386
>>
>>
>> Here's the backout webrev:
>>
>> http://cr.openjdk.java.net/~dcubed/8202386-webrev/0_for_jdk_jdk/
>>
>> The backout was generated by:
>>
>> $ hg log -v -r 4745598b307f
>> changeset: 49898:4745598b307f
>> user: eosterlund
>> date: Thu Apr 26 11:56:24 2018 +0200
>> files: src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
>> description:
>> 8200235: Generalize jniFastGetField jobject/jweak resolve
>> Reviewed-by: kbarrett, dholmes
>>
>> $ hg backout 4745598b307f
>> 9 files updated, 0 files merged, 0 files removed, 0 files unresolved
>> changeset 4745598b307f backed out, don't forget to commit.
>>
>> $ hg commit
>>
>> $ hg log -v -r tip
>> changeset: 49917:a1765a10c340
>> tag: tip
>> user: dcubed
>> date: Fri Apr 27 14:56:20 2018 -0400
>> files: src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
>> description:
>> Merge
>>
>> I sanity checked the backout with:
>>
>>
>> $ hg diff -r 49897 `cat file.list` | wc
>> 0 0 0
>>
>> which compares the changeset before 49898:4745598b307f
>> with the current tip. All is good.
>>
>> Dan
>>
From george.triantafillou at oracle.com Fri Apr 27 19:37:44 2018
From: george.triantafillou at oracle.com (George Triantafillou)
Date: Fri, 27 Apr 2018 15:37:44 -0400
Subject: URGENT RFR(XS): 8202386 [BACKOUT] fix for 8200235
In-Reply-To: <5b2927f5-4703-39d7-35f4-0894cf6bb59e@oracle.com>
References: <5b2927f5-4703-39d7-35f4-0894cf6bb59e@oracle.com>
Message-ID: <602db8d3-f25f-1383-ac6f-87af71c1dfd5@oracle.com>
Dan,
Looks good.
-George
On 4/27/2018 3:25 PM, Daniel D. Daugherty wrote:
> Greetings,
>
> Recent testing has revealed an issue with the following fix:
>
> ??? JDK-8200235 Generalize jniFastGetField jobject/jweak resolve
> ??? https://bugs.openjdk.java.net/browse/JDK-8200235
>
> The following bug is tracking the new failure mode:
>
> ??? JDK-8202381 (Solaris) SIGBUS in # V [libjvm.so+0xcee494]
> jni_GetIntField+0x224
> ??? https://bugs.openjdk.java.net/browse/JDK-8202381
>
> The following bug is being used to backout the fix for JDK-8200235:
>
> ??? JDK-8202386 [BACKOUT] fix for 8200235
> ??? https://bugs.openjdk.java.net/browse/JDK-8202386
>
>
> Here's the backout webrev:
>
> http://cr.openjdk.java.net/~dcubed/8202386-webrev/0_for_jdk_jdk/
>
> The backout was generated by:
>
> ??? $ hg log -v -r 4745598b307f
> ??? changeset:?? 49898:4745598b307f
> ??? user:??????? eosterlund
> ??? date:??????? Thu Apr 26 11:56:24 2018 +0200
> ??? files:
> src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp
> src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp
> src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp
> src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp
> src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp
> src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp
> src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp
> src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp
> src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
> ??? description:
> ??? 8200235: Generalize jniFastGetField jobject/jweak resolve
> ??? Reviewed-by: kbarrett, dholmes
>
> ??? $ hg backout 4745598b307f
> ??? 9 files updated, 0 files merged, 0 files removed, 0 files unresolved
> ??? changeset 4745598b307f backed out, don't forget to commit.
>
> ? ? $ hg commit
>
> ? ? $ hg log -v -r tip
> ??? changeset:?? 49917:a1765a10c340
> ??? tag:???????? tip
> ??? user:??????? dcubed
> ??? date:??????? Fri Apr 27 14:56:20 2018 -0400
> ??? files:
> src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp
> src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp
> src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp
> src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp
> src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp
> src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp
> src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp
> src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp
> src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
> ??? description:
> ??? Merge
>
> I sanity checked the backout with:
>
>
> $ hg diff -r 49897 `cat file.list` | wc
> ?????? 0?????? 0?????? 0
>
> which compares the changeset before 49898:4745598b307f
> with the current tip. All is good.
>
> Dan
>
From daniel.daugherty at oracle.com Fri Apr 27 19:38:50 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 27 Apr 2018 15:38:50 -0400
Subject: URGENT RFR(XS): 8202386 [BACKOUT] fix for 8200235
In-Reply-To: <602db8d3-f25f-1383-ac6f-87af71c1dfd5@oracle.com>
References: <5b2927f5-4703-39d7-35f4-0894cf6bb59e@oracle.com>
<602db8d3-f25f-1383-ac6f-87af71c1dfd5@oracle.com>
Message-ID: <221d3afc-9e3c-9dda-0425-0356554981ba@oracle.com>
Thanks George!
Dan
On 4/27/18 3:37 PM, George Triantafillou wrote:
> Dan,
>
> Looks good.
>
> -George
>
> On 4/27/2018 3:25 PM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> Recent testing has revealed an issue with the following fix:
>>
>> ??? JDK-8200235 Generalize jniFastGetField jobject/jweak resolve
>> ??? https://bugs.openjdk.java.net/browse/JDK-8200235
>>
>> The following bug is tracking the new failure mode:
>>
>> ??? JDK-8202381 (Solaris) SIGBUS in # V [libjvm.so+0xcee494]
>> jni_GetIntField+0x224
>> ??? https://bugs.openjdk.java.net/browse/JDK-8202381
>>
>> The following bug is being used to backout the fix for JDK-8200235:
>>
>> ??? JDK-8202386 [BACKOUT] fix for 8200235
>> ??? https://bugs.openjdk.java.net/browse/JDK-8202386
>>
>>
>> Here's the backout webrev:
>>
>> http://cr.openjdk.java.net/~dcubed/8202386-webrev/0_for_jdk_jdk/
>>
>> The backout was generated by:
>>
>> ??? $ hg log -v -r 4745598b307f
>> ??? changeset:?? 49898:4745598b307f
>> ??? user:??????? eosterlund
>> ??? date:??????? Thu Apr 26 11:56:24 2018 +0200
>> ??? files:
>> src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp
>> src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp
>> src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp
>> src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp
>> src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp
>> src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp
>> src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp
>> src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp
>> src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
>> ??? description:
>> ??? 8200235: Generalize jniFastGetField jobject/jweak resolve
>> ??? Reviewed-by: kbarrett, dholmes
>>
>> ??? $ hg backout 4745598b307f
>> ??? 9 files updated, 0 files merged, 0 files removed, 0 files unresolved
>> ??? changeset 4745598b307f backed out, don't forget to commit.
>>
>> ? ? $ hg commit
>>
>> ? ? $ hg log -v -r tip
>> ??? changeset:?? 49917:a1765a10c340
>> ??? tag:???????? tip
>> ??? user:??????? dcubed
>> ??? date:??????? Fri Apr 27 14:56:20 2018 -0400
>> ??? files:
>> src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp
>> src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp
>> src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp
>> src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp
>> src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp
>> src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp
>> src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp
>> src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp
>> src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
>> ??? description:
>> ??? Merge
>>
>> I sanity checked the backout with:
>>
>>
>> $ hg diff -r 49897 `cat file.list` | wc
>> ?????? 0?????? 0?????? 0
>>
>> which compares the changeset before 49898:4745598b307f
>> with the current tip. All is good.
>>
>> Dan
>>
>
From gerald.thornbrugh at oracle.com Fri Apr 27 19:38:57 2018
From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh)
Date: Fri, 27 Apr 2018 13:38:57 -0600
Subject: URGENT RFR(XS): 8202386 [BACKOUT] fix for 8200235
In-Reply-To: <5b2927f5-4703-39d7-35f4-0894cf6bb59e@oracle.com>
References: <5b2927f5-4703-39d7-35f4-0894cf6bb59e@oracle.com>
Message-ID: <1B042123-86CE-4CC2-85DB-437E3E92093A@oracle.com>
Hi Dan,
Looks like a good backout, thumbs up!
Jerry
> On Apr 27, 2018, at 1:25 PM, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>
> Greetings,
>
> Recent testing has revealed an issue with the following fix:
>
> JDK-8200235 Generalize jniFastGetField jobject/jweak resolve
> https://bugs.openjdk.java.net/browse/JDK-8200235
>
> The following bug is tracking the new failure mode:
>
> JDK-8202381 (Solaris) SIGBUS in # V [libjvm.so+0xcee494] jni_GetIntField+0x224
> https://bugs.openjdk.java.net/browse/JDK-8202381
>
> The following bug is being used to backout the fix for JDK-8200235:
>
> JDK-8202386 [BACKOUT] fix for 8200235
> https://bugs.openjdk.java.net/browse/JDK-8202386
>
>
> Here's the backout webrev:
>
> http://cr.openjdk.java.net/~dcubed/8202386-webrev/0_for_jdk_jdk/
>
> The backout was generated by:
>
> $ hg log -v -r 4745598b307f
> changeset: 49898:4745598b307f
> user: eosterlund
> date: Thu Apr 26 11:56:24 2018 +0200
> files: src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
> description:
> 8200235: Generalize jniFastGetField jobject/jweak resolve
> Reviewed-by: kbarrett, dholmes
>
> $ hg backout 4745598b307f
> 9 files updated, 0 files merged, 0 files removed, 0 files unresolved
> changeset 4745598b307f backed out, don't forget to commit.
>
> $ hg commit
>
> $ hg log -v -r tip
> changeset: 49917:a1765a10c340
> tag: tip
> user: dcubed
> date: Fri Apr 27 14:56:20 2018 -0400
> files: src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
> description:
> Merge
>
> I sanity checked the backout with:
>
>
> $ hg diff -r 49897 `cat file.list` | wc
> 0 0 0
>
> which compares the changeset before 49898:4745598b307f
> with the current tip. All is good.
>
> Dan
>
From daniel.daugherty at oracle.com Fri Apr 27 19:39:39 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 27 Apr 2018 15:39:39 -0400
Subject: URGENT RFR(XS): 8202386 [BACKOUT] fix for 8200235
In-Reply-To: <1B042123-86CE-4CC2-85DB-437E3E92093A@oracle.com>
References: <5b2927f5-4703-39d7-35f4-0894cf6bb59e@oracle.com>
<1B042123-86CE-4CC2-85DB-437E3E92093A@oracle.com>
Message-ID: <b7811de8-779f-a754-e3df-c7fec87f530a@oracle.com>
Thanks Jerry!
Dan
On 4/27/18 3:38 PM, Gerald Thornbrugh wrote:
> Hi Dan,
>
> Looks like a good backout, thumbs up!
>
> Jerry
>> On Apr 27, 2018, at 1:25 PM, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>>
>> Greetings,
>>
>> Recent testing has revealed an issue with the following fix:
>>
>> JDK-8200235 Generalize jniFastGetField jobject/jweak resolve
>> https://bugs.openjdk.java.net/browse/JDK-8200235
>>
>> The following bug is tracking the new failure mode:
>>
>> JDK-8202381 (Solaris) SIGBUS in # V [libjvm.so+0xcee494] jni_GetIntField+0x224
>> https://bugs.openjdk.java.net/browse/JDK-8202381
>>
>> The following bug is being used to backout the fix for JDK-8200235:
>>
>> JDK-8202386 [BACKOUT] fix for 8200235
>> https://bugs.openjdk.java.net/browse/JDK-8202386
>>
>>
>> Here's the backout webrev:
>>
>> http://cr.openjdk.java.net/~dcubed/8202386-webrev/0_for_jdk_jdk/
>>
>> The backout was generated by:
>>
>> $ hg log -v -r 4745598b307f
>> changeset: 49898:4745598b307f
>> user: eosterlund
>> date: Thu Apr 26 11:56:24 2018 +0200
>> files: src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
>> description:
>> 8200235: Generalize jniFastGetField jobject/jweak resolve
>> Reviewed-by: kbarrett, dholmes
>>
>> $ hg backout 4745598b307f
>> 9 files updated, 0 files merged, 0 files removed, 0 files unresolved
>> changeset 4745598b307f backed out, don't forget to commit.
>>
>> $ hg commit
>>
>> $ hg log -v -r tip
>> changeset: 49917:a1765a10c340
>> tag: tip
>> user: dcubed
>> date: Fri Apr 27 14:56:20 2018 -0400
>> files: src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
>> description:
>> Merge
>>
>> I sanity checked the backout with:
>>
>>
>> $ hg diff -r 49897 `cat file.list` | wc
>> 0 0 0
>>
>> which compares the changeset before 49898:4745598b307f
>> with the current tip. All is good.
>>
>> Dan
>>
From kim.barrett at oracle.com Fri Apr 27 19:44:27 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 27 Apr 2018 15:44:27 -0400
Subject: URGENT RFR(XS): 8202386 [BACKOUT] fix for 8200235
In-Reply-To: <5b2927f5-4703-39d7-35f4-0894cf6bb59e@oracle.com>
References: <5b2927f5-4703-39d7-35f4-0894cf6bb59e@oracle.com>
Message-ID: <696DE3CF-FA3E-41F8-838B-94CFC84577B1@oracle.com>
Looks good.
> On Apr 27, 2018, at 3:25 PM, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>
> Greetings,
>
> Recent testing has revealed an issue with the following fix:
>
> JDK-8200235 Generalize jniFastGetField jobject/jweak resolve
> https://bugs.openjdk.java.net/browse/JDK-8200235
>
> The following bug is tracking the new failure mode:
>
> JDK-8202381 (Solaris) SIGBUS in # V [libjvm.so+0xcee494] jni_GetIntField+0x224
> https://bugs.openjdk.java.net/browse/JDK-8202381
>
> The following bug is being used to backout the fix for JDK-8200235:
>
> JDK-8202386 [BACKOUT] fix for 8200235
> https://bugs.openjdk.java.net/browse/JDK-8202386
>
>
> Here's the backout webrev:
>
> http://cr.openjdk.java.net/~dcubed/8202386-webrev/0_for_jdk_jdk/
>
> The backout was generated by:
>
> $ hg log -v -r 4745598b307f
> changeset: 49898:4745598b307f
> user: eosterlund
> date: Thu Apr 26 11:56:24 2018 +0200
> files: src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
> description:
> 8200235: Generalize jniFastGetField jobject/jweak resolve
> Reviewed-by: kbarrett, dholmes
>
> $ hg backout 4745598b307f
> 9 files updated, 0 files merged, 0 files removed, 0 files unresolved
> changeset 4745598b307f backed out, don't forget to commit.
>
> $ hg commit
>
> $ hg log -v -r tip
> changeset: 49917:a1765a10c340
> tag: tip
> user: dcubed
> date: Fri Apr 27 14:56:20 2018 -0400
> files: src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
> description:
> Merge
>
> I sanity checked the backout with:
>
>
> $ hg diff -r 49897 `cat file.list` | wc
> 0 0 0
>
> which compares the changeset before 49898:4745598b307f
> with the current tip. All is good.
>
> Dan
From daniel.daugherty at oracle.com Fri Apr 27 19:46:23 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 27 Apr 2018 15:46:23 -0400
Subject: URGENT RFR(XS): 8202386 [BACKOUT] fix for 8200235
In-Reply-To: <696DE3CF-FA3E-41F8-838B-94CFC84577B1@oracle.com>
References: <5b2927f5-4703-39d7-35f4-0894cf6bb59e@oracle.com>
<696DE3CF-FA3E-41F8-838B-94CFC84577B1@oracle.com>
Message-ID: <422fb38d-5c5d-1a0a-f076-daadd61177cf@oracle.com>
Thanks Kim!
Thanks folks. I have enough reviewers... So far only Linux builds
have completed in my Mach5 job... waiting... waiting...
Dan
On 4/27/18 3:44 PM, Kim Barrett wrote:
> Looks good.
>
>> On Apr 27, 2018, at 3:25 PM, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>>
>> Greetings,
>>
>> Recent testing has revealed an issue with the following fix:
>>
>> JDK-8200235 Generalize jniFastGetField jobject/jweak resolve
>> https://bugs.openjdk.java.net/browse/JDK-8200235
>>
>> The following bug is tracking the new failure mode:
>>
>> JDK-8202381 (Solaris) SIGBUS in # V [libjvm.so+0xcee494] jni_GetIntField+0x224
>> https://bugs.openjdk.java.net/browse/JDK-8202381
>>
>> The following bug is being used to backout the fix for JDK-8200235:
>>
>> JDK-8202386 [BACKOUT] fix for 8200235
>> https://bugs.openjdk.java.net/browse/JDK-8202386
>>
>>
>> Here's the backout webrev:
>>
>> http://cr.openjdk.java.net/~dcubed/8202386-webrev/0_for_jdk_jdk/
>>
>> The backout was generated by:
>>
>> $ hg log -v -r 4745598b307f
>> changeset: 49898:4745598b307f
>> user: eosterlund
>> date: Thu Apr 26 11:56:24 2018 +0200
>> files: src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
>> description:
>> 8200235: Generalize jniFastGetField jobject/jweak resolve
>> Reviewed-by: kbarrett, dholmes
>>
>> $ hg backout 4745598b307f
>> 9 files updated, 0 files merged, 0 files removed, 0 files unresolved
>> changeset 4745598b307f backed out, don't forget to commit.
>>
>> $ hg commit
>>
>> $ hg log -v -r tip
>> changeset: 49917:a1765a10c340
>> tag: tip
>> user: dcubed
>> date: Fri Apr 27 14:56:20 2018 -0400
>> files: src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
>> description:
>> Merge
>>
>> I sanity checked the backout with:
>>
>>
>> $ hg diff -r 49897 `cat file.list` | wc
>> 0 0 0
>>
>> which compares the changeset before 49898:4745598b307f
>> with the current tip. All is good.
>>
>> Dan
>
From mvala at redhat.com Fri Apr 27 20:26:56 2018
From: mvala at redhat.com (Michal Vala)
Date: Fri, 27 Apr 2018 22:26:56 +0200
Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int
readdir_r(DIR*, dirent*, dirent**)' is deprecated
In-Reply-To: <AA869CB2-1921-4DDC-A1FE-28394880F294@oracle.com>
References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com>
<D3E193F3-4249-4925-8020-7CEE710C6BAF@oracle.com>
<CABi63P4-Grx7KNXrfRkZX9gGFkEida4Kzz2Eh2GsoLF+xT9WvQ@mail.gmail.com>
<403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com>
<aec74ecb-aeb3-4342-8ca2-1a70a56e92d3@redhat.com>
<AA869CB2-1921-4DDC-A1FE-28394880F294@oracle.com>
Message-ID: <3197d649-2c9e-299c-db40-b6715aea8b92@redhat.com>
On 04/27/2018 06:50 PM, Kim Barrett wrote:
>> On Apr 27, 2018, at 4:56 AM, Michal Vala <mvala at redhat.com> wrote:
>>
>>
>>
>> On 04/27/2018 12:55 AM, Kim Barrett wrote:
>>>> On Apr 25, 2018, at 10:51 AM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>>>>
>>>> On 24 April 2018 at 20:17, Kim Barrett <kim.barrett at oracle.com> wrote:
>>>>>> On Apr 23, 2018, at 3:51 AM, Michal Vala <mvala at redhat.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> following discussion "RFR: build pragma error with gcc 4.4.7"[1], I'm posting updated patch replacing deprecated readdir_r with readdir. Bug ID is JDK-8179887 [2].
>>>>>>
>>>>>> webrev: http://cr.openjdk.java.net/~andrew/8179887/webrev/
>>>>>>
>>>>>> I'm asking for the review and eventually sponsorship.
>>>>>
>>>>
>>>> The patch looks good to me.
>>>>
>>>>> The change to os::readdir in os_linux.inline.hpp looks fine.
>>>>>
>>>>> I was going to suggest that rather than changing perfMemory_linux.cpp to use os::readdir in an
>>>>> unusual and platform-specific way, it should instead just call ::readdir directly. However, neither
>>>>> of those is right, and that part of the change should not be made; see
>>>>> https://bugs.openjdk.java.net/browse/JDK-8134540
>>>>> Much nearly duplicated code for PerfMemory support
>>>>>
>>>>
>>>> I think, in the circumstances, Michal's solution is the best option at
>>>> this point.
>>>> 8134540 looks like a more long-term change currently scheduled for 12 (is
>>>> anyone currently working on it?), whereas this fix could go into 11 and remove
>>>> a couple of unneeded memory allocations.
>>>>
>>>>> Looking a bit deeper, there might be some additional follow-on that could be done, eliminating
>>>>> the second argument to os::readdir.
>>>>> windows: unused
>>>>> bsd: freebsd also deprecated readdir_r, I think for similar reasons.
>>>>> solaris: doc is clear about thread safety issue being about sharing the DIR*
>>>>> aix: I haven?t looked at it, but would guess it?s similar.
>>>>>
>>>>> In other words, don?t operate on the DIR* from multiple threads simultaneously, and just use
>>>>> ::readdir on non-Windows. That would all be for another RFE though.
>>>>>
>>>>>
>>>>
>>>> This also seems like a more in-depth separate change and not one that
>>>> can be performed
>>>> by any of us alone, as we don't test all these platforms. As it
>>>> stands, Michal's change affects
>>>> Linux and Linux alone, and the addition of the use of NULL will make
>>>> it clearer that moving
>>>> to an os:readdir is feasible on that platform.
>>> I disagree, and still think the perfMemory_linux.cpp change should be
>>> removed.
>>> (1) The change to perfMemory_linux.cpp is entirely unnecessary to
>>> address the problem this bug is about.
>>> (2) It violates the (implied) protocol for os::readdir. If
>>> Linux-specific code wants to invoke Linux-specific behavior, it should
>>> do so by calling a Linux-specific API, not abuse an intended to be
>>> portable API.
>>> (3) It minorly interferes with some desirable future work. If there
>>> were some significant benefit to doing so, I wouldn't give this much
>>> weight, but I don't see a significant benefit.
>>> (4) The only benefit is saving some rare short-term memory
>>> allocations. I don't think that's worth the above costs.
>>> Note that the Windows version of os::readdir also ignores the second
>>> argument, but all callers provide it anyway.
>>> I've opened a new CR for general os::readdir cleanup.
>>> https://bugs.openjdk.java.net/browse/JDK-8202353
>>
>> Ok, if we agree on os_linux.inline.hpp part, I think it should go in. Rest can be solved in JDK-8202353, which should imho include also removal of second argument of os::readdir, once it's unused.
>>
>> For now, proposed patch looks like this:
>>
>> --- old/src/hotspot/os/linux/os_linux.inline.hpp 2018-04-20 09:16:34.498343185 +0200
>> +++ new/src/hotspot/os/linux/os_linux.inline.hpp 2018-04-20 09:16:34.214342670 +0200
>> @@ -98,26 +98,8 @@
>>
>> inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf)
>> {
>> -// readdir_r has been deprecated since glibc 2.24.
>> -// See https://sourceware.org/bugzilla/show_bug.cgi?id=19056 for more details.
>> -#pragma GCC diagnostic push
>> -#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
>> -
>> - dirent* p;
>> - int status;
>> assert(dirp != NULL, "just checking");
>> -
>> - // NOTE: Linux readdir_r (on RH 6.2 and 7.2 at least) is NOT like the POSIX
>> - // version. Here is the doc for this function:
>> - // http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_262.html
>> -
>> - if((status = ::readdir_r(dirp, dbuf, &p)) != 0) {
>> - errno = status;
>> - return NULL;
>> - } else
>> - return p;
>> -
>> -#pragma GCC diagnostic pop
>> + return ::readdir(dirp);
>> }
>>
>> inline int os::closedir(DIR *dirp) {
>
> This looks good.
>
Thanks!
Someone to sponsor this please?
--
Michal Vala
OpenJDK QE
Red Hat Czech
From igor.ignatyev at oracle.com Fri Apr 27 21:50:33 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 27 Apr 2018 14:50:33 -0700
Subject: RFR(L) : 8199643 : [TESTBUG] Open source common VM testbase code
Message-ID: <CB612F9B-CBA7-458E-B8AC-39B50E695A08@oracle.com>
http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html
> 58155 lines changed: 58155 ins; 0 del; 0 mod;
Hi all,
could you please review this webrev which open sources code shared by many tests from so-called VM testbase?
this patch doesn't include any tests, it's rather a preparation step to simplify actual open sourcing of the tests, which will be done later by separate RFEs[*]. the files are intentionally put into a separate directory (test/hotspot/jtreg/vmTestbase) to emphasize that these tests were a part of one "product", most of the code doesn't meet openjdk coding guidelines (or any other coding guidelines for that matter), might be highly coupled and duplicate some existing test and/or test libraries from jtreg test bases. in a long term, we are planning to rework all these tests and make them more like other regular jtreg tests.
I'd like to highlight that the code in this webrev isn't new, VM testbase tests have been using it for a long time and these tests have been by Oracle for internal hotspot testing for a long period if time. however as this patch adds "new" native code, I'd really like platforms' maintainers to closely review all .h/.c files (esp. libProcessUtils.c and all the files used by it) as they were never built/executed on platforms other than the ones supported by Oracle.
JBS: https://bugs.openjdk.java.net/browse/JDK-8199643
webrev: http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html
testing:
- all tests which depend on this code
- build linux-x64, windows-x64, mac-x64, solaris-sparcv9 including open-only variants
[*] JBS:(labels = test-opensource and component = hotspot)
https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%20test-opensource%20and%20component%20%3D%20hotspot
Thanks,
-- Igor
From edward.nevill at gmail.com Fri Apr 27 22:01:52 2018
From: edward.nevill at gmail.com (Edward Nevill)
Date: Fri, 27 Apr 2018 23:01:52 +0100
Subject: RFR 8201786: Modularize interpreter GC barriers: leftovers for
ARM32
In-Reply-To: <668e8a59-cba1-a2ce-48a0-cf9cfcde032b@redhat.com>
References: <4d22aacb-aa0d-4423-1a22-775e2be7eeaf@redhat.com>
<1524847169.9114.6.camel@gmail.com>
<668e8a59-cba1-a2ce-48a0-cf9cfcde032b@redhat.com>
Message-ID: <1524866512.9114.10.camel@gmail.com>
On Fri, 2018-04-27 at 18:56 +0200, Aleksey Shipilev wrote:
> On 04/27/2018 06:39 PM, Edward Nevill wrote:
> > On Thu, 2018-04-26 at 17:55 +0200, Aleksey Shipilev wrote:
> > > http://cr.openjdk.java.net/~shade/8201786/webrev.01/
> > > https://bugs.openjdk.java.net/browse/JDK-8201786
> >
>
> > I have run jtreg hotspot test (less the jcstress tests) on arm v8
> > with
> > the following results
> >
> > Test results: passed: 1,493; failed: 45; error: 100
> >
> > There were no fatal errors in any of the tests.
>
> It is hard to interpret these numbers. Does this mean there are 45
> new failures and 100 new errors?
Well, this is the problem with jtreg. A regression suite should have 0
failures.
I have rerun the original, pre patched source on hotspot jtreg and get
the following results
Test results: passed: 1,493; failed: 45; error: 100
So, all we can say is that it is no worse after your patch.
All the best,
Ed.
From igor.ignatyev at oracle.com Fri Apr 27 22:06:09 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 27 Apr 2018 15:06:09 -0700
Subject: RFR(L) : 8199643 : [TESTBUG] Open source common VM testbase code
In-Reply-To: <CB612F9B-CBA7-458E-B8AC-39B50E695A08@oracle.com>
References: <CB612F9B-CBA7-458E-B8AC-39B50E695A08@oracle.com>
Message-ID: <413B3056-A7D2-4AB8-A8AB-D43F23CD846C@oracle.com>
pasted a wrong link, here is the right one -- http://cr.openjdk.java.net/~iignatyev/8199643/webrev.00/index.html <http://cr.openjdk.java.net/~iignatyev/8199643/webrev.00/index.html>
-- Igor
> On Apr 27, 2018, at 2:50 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>
> http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html
>> 58155 lines changed: 58155 ins; 0 del; 0 mod;
>
> Hi all,
>
> could you please review this webrev which open sources code shared by many tests from so-called VM testbase?
>
> this patch doesn't include any tests, it's rather a preparation step to simplify actual open sourcing of the tests, which will be done later by separate RFEs[*]. the files are intentionally put into a separate directory (test/hotspot/jtreg/vmTestbase) to emphasize that these tests were a part of one "product", most of the code doesn't meet openjdk coding guidelines (or any other coding guidelines for that matter), might be highly coupled and duplicate some existing test and/or test libraries from jtreg test bases. in a long term, we are planning to rework all these tests and make them more like other regular jtreg tests.
>
> I'd like to highlight that the code in this webrev isn't new, VM testbase tests have been using it for a long time and these tests have been by Oracle for internal hotspot testing for a long period if time. however as this patch adds "new" native code, I'd really like platforms' maintainers to closely review all .h/.c files (esp. libProcessUtils.c and all the files used by it) as they were never built/executed on platforms other than the ones supported by Oracle.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8199643
> webrev: http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html
> testing:
> - all tests which depend on this code
> - build linux-x64, windows-x64, mac-x64, solaris-sparcv9 including open-only variants
>
> [*] JBS:(labels = test-opensource and component = hotspot)
> https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%20test-opensource%20and%20component%20%3D%20hotspot
>
> Thanks,
> -- Igor
From david.holmes at oracle.com Fri Apr 27 23:19:56 2018
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 28 Apr 2018 09:19:56 +1000
Subject: jdk-submit is offline until Monday
Message-ID: <035f244f-175b-6b03-c69b-4e9773881248@oracle.com>
Just a heads up that due to scheduled maintenance the systems used by
jdk-submit will be offline until Monday morning Pacific Time US.
David
From david.holmes at oracle.com Fri Apr 27 23:27:28 2018
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 28 Apr 2018 09:27:28 +1000
Subject: jdk-submit is offline until Monday
In-Reply-To: <035f244f-175b-6b03-c69b-4e9773881248@oracle.com>
References: <035f244f-175b-6b03-c69b-4e9773881248@oracle.com>
Message-ID: <7339b969-0f20-652c-b4d6-88b88ade5006@oracle.com>
I should have added that the CI testing system is also offline, so any
pushes won't hit our internal testing until sometime Monday.
David
On 28/04/2018 9:19 AM, David Holmes wrote:
> Just a heads up that due to scheduled maintenance the systems used by
> jdk-submit will be offline until Monday morning Pacific Time US.
>
> David
From dms at samersoff.net Sat Apr 28 07:59:31 2018
From: dms at samersoff.net (Dmitry Samersoff)
Date: Sat, 28 Apr 2018 10:59:31 +0300
Subject: RFR(XL): 8199712: Flight Recorder
In-Reply-To: <5AE0612F.8060200@oracle.com>
References: <5AE0612F.8060200@oracle.com>
Message-ID: <9a5f2a18-f7d4-d1ad-6618-b92bb7d71dd9@samersoff.net>
Erik,
globals.cpp:1051 these changes seems to be unnecessary.
-Dmitry
On 25.04.2018 14:06, Erik Gahlin wrote:
> Greetings,
>
> Could I have a review of 8199712: Flight Recorder
>
> As mentioned in the preview [1] the tracing backend has been removed.
> Event metadata has been consolidated into a single XML file and event
> classes are now generated by GenerateJfrFiles.java.
>
> Tests have been run on Linux-x64, Windows-x64 and MaxOSX-x64.
>
> For details about the feature, see the JEP:
> https://bugs.openjdk.java.net/browse/JDK-8193393
>
> Webrev:
> http://cr.openjdk.java.net/~egahlin/8199712.0/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8199712
>
> [1]
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031359.html
>
> Thanks
> Erik and Markus
--
Dmitry Samersoff
http://devnull.samersoff.net
* There will come soft rains ...
From erik.gahlin at oracle.com Sat Apr 28 08:17:56 2018
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Sat, 28 Apr 2018 10:17:56 +0200
Subject: RFR(XL): 8199712: Flight Recorder
In-Reply-To: <9a5f2a18-f7d4-d1ad-6618-b92bb7d71dd9@samersoff.net>
References: <5AE0612F.8060200@oracle.com>
<9a5f2a18-f7d4-d1ad-6618-b92bb7d71dd9@samersoff.net>
Message-ID: <A42BBFAD-E12C-4D7D-A76E-6FE01ABCE8E7@oracle.com>
Yes, If we don?t include JFR, we should get the stubs
Will fix.
Erik
> On 28 Apr 2018, at 09:59, Dmitry Samersoff <dms at samersoff.net> wrote:
>
> Erik,
>
> globals.cpp:1051 these changes seems to be unnecessary.
>
> -Dmitry
>
> On 25.04.2018 14:06, Erik Gahlin wrote:
>> Greetings,
>>
>> Could I have a review of 8199712: Flight Recorder
>>
>> As mentioned in the preview [1] the tracing backend has been removed.
>> Event metadata has been consolidated into a single XML file and event
>> classes are now generated by GenerateJfrFiles.java.
>>
>> Tests have been run on Linux-x64, Windows-x64 and MaxOSX-x64.
>>
>> For details about the feature, see the JEP:
>> https://bugs.openjdk.java.net/browse/JDK-8193393
>>
>> Webrev:
>> http://cr.openjdk.java.net/~egahlin/8199712.0/
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8199712
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031359.html
>>
>> Thanks
>> Erik and Markus
>
>
> --
> Dmitry Samersoff
> http://devnull.samersoff.net
> * There will come soft rains ...
>
From gerald.thornbrugh at oracle.com Sat Apr 28 14:34:26 2018
From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh)
Date: Sat, 28 Apr 2018 08:34:26 -0600
Subject: RFR(L) : 8199643 : [TESTBUG] Open source common VM testbase code
In-Reply-To: <CB612F9B-CBA7-458E-B8AC-39B50E695A08@oracle.com>
References: <CB612F9B-CBA7-458E-B8AC-39B50E695A08@oracle.com>
Message-ID: <314774c1-c43f-47f1-f6ad-8a5f4732e624@oracle.com>
Hi Igor,
Your changes look good to me.
Thanks!
Jerry
> http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html
>> 58155 lines changed: 58155 ins; 0 del; 0 mod;
> Hi all,
>
> could you please review this webrev which open sources code shared by many tests from so-called VM testbase?
>
> this patch doesn't include any tests, it's rather a preparation step to simplify actual open sourcing of the tests, which will be done later by separate RFEs[*]. the files are intentionally put into a separate directory (test/hotspot/jtreg/vmTestbase) to emphasize that these tests were a part of one "product", most of the code doesn't meet openjdk coding guidelines (or any other coding guidelines for that matter), might be highly coupled and duplicate some existing test and/or test libraries from jtreg test bases. in a long term, we are planning to rework all these tests and make them more like other regular jtreg tests.
>
> I'd like to highlight that the code in this webrev isn't new, VM testbase tests have been using it for a long time and these tests have been by Oracle for internal hotspot testing for a long period if time. however as this patch adds "new" native code, I'd really like platforms' maintainers to closely review all .h/.c files (esp. libProcessUtils.c and all the files used by it) as they were never built/executed on platforms other than the ones supported by Oracle.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8199643
> webrev: http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html
> testing:
> - all tests which depend on this code
> - build linux-x64, windows-x64, mac-x64, solaris-sparcv9 including open-only variants
>
> [*] JBS:(labels = test-opensource and component = hotspot)
> https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%20test-opensource%20and%20component%20%3D%20hotspot
>
> Thanks,
> -- Igor
From shade at redhat.com Mon Apr 30 09:05:00 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 30 Apr 2018 11:05:00 +0200
Subject: RFR 8202379: ARM32 is broken after JDK-8201543 (Modularize C1 GC
barriers)
Message-ID: <2f5d4f30-dfb5-4959-c032-e27d747ee07e@redhat.com>
Bug:
https://bugs.openjdk.java.net/browse/JDK-8202379
Fix:
http://cr.openjdk.java.net/~shade/8202379/webrev.01/
Testing: arm32 build, Raspi 3 runs (some selected jcstress tests)
Thanks,
-Aleksey
From aph at redhat.com Mon Apr 30 09:09:28 2018
From: aph at redhat.com (Andrew Haley)
Date: Mon, 30 Apr 2018 10:09:28 +0100
Subject: RFR 8202379: ARM32 is broken after JDK-8201543 (Modularize C1 GC
barriers)
In-Reply-To: <2f5d4f30-dfb5-4959-c032-e27d747ee07e@redhat.com>
References: <2f5d4f30-dfb5-4959-c032-e27d747ee07e@redhat.com>
Message-ID: <1914516d-ec4b-1c45-194a-3107371fb1f9@redhat.com>
On 04/30/2018 10:05 AM, Aleksey Shipilev wrote:
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8202379
>
> Fix:
> http://cr.openjdk.java.net/~shade/8202379/webrev.01/
>
> Testing: arm32 build, Raspi 3 runs (some selected jcstress tests)
Looks OK, thanks.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
From shade at redhat.com Mon Apr 30 09:34:28 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 30 Apr 2018 11:34:28 +0200
Subject: RFR 8201786: Modularize interpreter GC barriers: leftovers for
ARM32
In-Reply-To: <1524866512.9114.10.camel@gmail.com>
References: <4d22aacb-aa0d-4423-1a22-775e2be7eeaf@redhat.com>
<1524847169.9114.6.camel@gmail.com>
<668e8a59-cba1-a2ce-48a0-cf9cfcde032b@redhat.com>
<1524866512.9114.10.camel@gmail.com>
Message-ID: <828a25d9-d4b1-ec05-71e3-ceddef4b7a24@redhat.com>
On 04/28/2018 12:01 AM, Edward Nevill wrote:
>>>> http://cr.openjdk.java.net/~shade/8201786/webrev.01/
> So, all we can say is that it is no worse after your patch.
Good!
On 04/27/2018 08:49 PM, Boris Ulasevich wrote:
> I have checked your change with [JCK vm+lang subset] X [G1|SerialGC] on Raspi 2 - Passed Ok.
Thanks for testing, Edward and Boris!
Rebased the patch for current jdk/jdk (trivial header definition clash resolved):
http://cr.openjdk.java.net/~shade/8201786/webrev.02/
I need JDK-8202379 to go in first, because current arm32 is broken:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031909.html
Thanks,
-Aleksey
From shade at redhat.com Mon Apr 30 10:20:07 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 30 Apr 2018 12:20:07 +0200
Subject: RFR 8202418: Remove explicit CMS checks in
CardTableBarrierSetAssembler: ARM32 leftovers
Message-ID: <a6c0a5b1-e65c-38f5-7103-568c8de6f86b@redhat.com>
Bug:
https://bugs.openjdk.java.net/browse/JDK-8202418
Fix:
http://cr.openjdk.java.net/~shade/8202418/webrev.01/
Testing: arm32-hflt build, adhoc smoke tests with Serial/G1/CMS on Raspi 3
Thanks,
-Aleksey
From erik.osterlund at oracle.com Mon Apr 30 10:28:14 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Mon, 30 Apr 2018 12:28:14 +0200
Subject: RFR 8202418: Remove explicit CMS checks in
CardTableBarrierSetAssembler: ARM32 leftovers
In-Reply-To: <a6c0a5b1-e65c-38f5-7103-568c8de6f86b@redhat.com>
References: <a6c0a5b1-e65c-38f5-7103-568c8de6f86b@redhat.com>
Message-ID: <5AE6EFBE.4070706@oracle.com>
Hi Aleksey,
Looks good.
Thanks,
/Erik
On 2018-04-30 12:20, Aleksey Shipilev wrote:
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8202418
>
> Fix:
> http://cr.openjdk.java.net/~shade/8202418/webrev.01/
>
> Testing: arm32-hflt build, adhoc smoke tests with Serial/G1/CMS on Raspi 3
>
> Thanks,
> -Aleksey
>
From erik.osterlund at oracle.com Mon Apr 30 13:32:03 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Mon, 30 Apr 2018 15:32:03 +0200
Subject: RFR: 8202381: (Solaris) SIGBUS in # V [libjvm.so+0xcee494]
jni_GetIntField+0x224
Message-ID: <5AE71AD3.9090000@oracle.com>
Hi,
It looks like I broke jniFastGetField on SPARC with my changes to
modularize this feature (8200235). Sorry about that. And the backout of
that (8202386) didn't go in due to maintenance. So here is a patch to
fix the problem instead.
Webrev:
http://cr.openjdk.java.net/~eosterlund/8202381/webrev.00/
Bug ID:
https://bugs.openjdk.java.net/browse/JDK-8202381
My (long version) analysis on the architectures (that I made changes to)
of what is going on:
== SPARC ==
This is where the SIGBUS happened. We used to get the jobject/jweak in
O1, clear the jweak tag in O1, and resolve the handle by loading from O1
to O5. This was in fact already broken, since 8176100 "[REDO][REDO] G1
Needs pre barrier on dereference of weak JNI handles". The registers
used to pass the arguments into the C function (O0, O1 and O2) must not
be touched throughout the call, despite being caller saved, as we have
not saved the register window. By clearing the jweak in O1, the wrong
access functions are used in the slow path if the speculative load is
invalidated, either due to the second safepoint counter not being able
to the first sampled safepoint counter, or the load of the int popping
in to the signal handler. I made this problem worse in my 8200235 patch
by not just clearing O1, but also resolving into O1, which clobbered the
register even further. This caused intermittent failures in the
following sequence of events: 1) the safepoint counter is read, and we
are not in a safepoint, 2) the jobject/jweak is resolved, clobbering O1,
3) a safepoint is triggered, 4) after resolving the jobject/jweak, the
safepoint counter is sampled again with a new number, causing a call to
the slow path where O1 no longer contains the jobject/jweak.
In my proposed changes, this was remedied by moving O1 to O5 first, then
clearing the jweak value (in O5), then resolving (in O5) and then
performing the speculative load with all passed C arguments untouched in
their O1, O2 and O3 registers, as required for the fallback code.
== x86_64 ==
On x86_64, the passed in jobject/jweak is already moved to a separate
scratch register. Therefore, the problem of clearing the jweak tag in
the jobject does not apply here. However, rscratch1 was the register I
picked as a temporary register for resolving. After reading this code
more carefully, I realize this is the r10 register, which coincides with
the register used to remember the old counter. So using that temporary
register is not safe. I chose a new register instead: r8. This is, like
the other registers used in this code, a caller saved register, that
does not intersect with the input registers of the function arguments.
That makes it safe to use in this context. I added DEBUG_ONLY code for
clobbering this temporary register on x86_64, to make sure we more
easily catch such problems.
== AArch64 ==
On AArch64, the jobject/jweak is already in r3 when cleared (which does
not intersect with the registers used in the C calling convention, and
is caller saved). Therefore, the clearing of the jweak tag there is
correct, and so is the resolution. The temporary register used is r8,
which is used as a temporary register by surrounding code in this
context (and is caller saved).
Apart from this, I also added a jni_env parameter to
try_resolve_jobject_in_native, which just passes c_rarg0 containing the
jni environment, without doing anything to it. We need to read from this
register in ZGC, and I would prefer not to hardcode in the backend that
c_rarg0 always refers to the jni environment in this context.
There are still remaining problems in ARM that the jweak tag is cleared
in r1, which will cause the slow path to resolve jweaks as jobjects.
However, I would like to not address that issue in this fix, as my
original changes did not touch that ARM code. I would like to instead
file a bug for that to be solved by another brave soul who wants to
change the jniFastGetField code in the ARM port.
Testing:
I ran the httpclient tests (that failed because of this) with
--test-repeat 100, and ran that 3 times. No problems discovered. I am
also finishing up hs-tier1-3 and jdk-tier1-3.
Thanks,
/Erik
From matthias.baesken at sap.com Mon Apr 30 14:52:44 2018
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 30 Apr 2018 14:52:44 +0000
Subject: [RFR] 8202427: Enhance os::print_memory_info on Windows
Message-ID: <ddd3699066954666810b8232d864a43b@sap.com>
On Windows,
the os::print_memory_info misses a few memory-related infos that might be interesting :
- current and peak WorkingSet size (= physical memory assigned to the process)
- current and peak commit charge (also known as "private bytes" in Windows tools)
- on 32bit Windows :
user-mode portion/free user mode portion of virtual address-space (Total/AvailVirtual) because it shows how close do we get to the 2-4 GB per process border.
- the current naming of "swap/free-swap" memory is a bit misleading;
in the Windows world swap is a special page file used for UWP apps.
(see Windows Internals : "The swap file" (chapter 5 Memory management)
Windows 8 added another page file called a swap file. It is ... exclusively used for UWP (Universal Windows Platform) apps.
Our output (ullTotalPageFile and ullAvailPageFile) is NOT about the UWP related values, it is about page file sizes
(so calling it TotalPageFile/AvailPageFile in "Windows-speak" or just virtual memory might be more appropriate).
https://msdn.microsoft.com/de-de/library/windows/desktop/aa366770(v=vs.85).aspx
documents it in the following way:
ullTotalPageFile:
The current committed memory limit for the system or the current process, whichever is smaller,...
ullAvailPageFile :
The maximum amount of memory the current process can commit, in bytes. This value is equal to or smaller than the system-wide available commit value
Aditionally I suggest having output of the various memory-values in M (megabyte) as well , the k (kilobyte) output sometimes gives very high and unreadable numbers).
Could you please review my change ?
Bug :
https://bugs.openjdk.java.net/browse/JDK-8202427
Change :
http://cr.openjdk.java.net/~mbaesken/webrevs/8202427.0/
Thanks, Matthias
From zgu at redhat.com Mon Apr 30 15:32:29 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 30 Apr 2018 11:32:29 -0400
Subject: RFR(XXS) 8201542: Remove unused _gc_timer field in GCMemoryManager
Message-ID: <186a0988-2eab-6734-24af-f1c8c2a8590f@redhat.com>
Please review this trivial cleanup to remove unused _gc_timer in
GCMemoryManager.
Bug: https://bugs.openjdk.java.net/browse/JDK-8201542
Webrev: http://cr.openjdk.java.net/~zgu/8201542/webrev.00/
Test:
hotspot_servicebility on Linux x64 (fastdebug and release)
Thanks,
-Zhengyu
From daniel.daugherty at oracle.com Mon Apr 30 15:36:14 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 30 Apr 2018 11:36:14 -0400
Subject: RFR: 8202381: (Solaris) SIGBUS in # V [libjvm.so+0xcee494]
jni_GetIntField+0x224
In-Reply-To: <5AE71AD3.9090000@oracle.com>
References: <5AE71AD3.9090000@oracle.com>
Message-ID: <efb3ed09-b8a3-6d26-596e-cae55d3c685d@oracle.com>
On 4/30/18 9:32 AM, Erik ?sterlund wrote:
> Hi,
>
> It looks like I broke jniFastGetField on SPARC with my changes to
> modularize this feature (8200235). Sorry about that. And the backout
> of that (8202386) didn't go in due to maintenance. So here is a patch
> to fix the problem instead.
>
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8202381/webrev.00/
src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp
src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp
src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp
??? Addition of the placeholder 'jni_env'; you went to the trouble
??? of changing 'robj' -> 'obj' on the other platforms, but not here
??? which is inconsistent.
src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp
src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp
??? Addition of the placeholder 'jni_env'; why rename 'robj' -> 'obj'?
src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp
??? Addition of the placeholder 'jni_env'; why rename 'robj' -> 'obj'?
??? L74: ? // Both O5 and G3 are clobbered by
try_resolve_jobject_in_native.
??????? You are passing 'G3' as 'tmp'. I don't see where/how in
??????? try_resolve_jobject_in_native() that the 'tmp' parameter gets
??????? clobbered.
src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp
src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp
??? Addition of the placeholder 'jni_env'; why rename 'robj' -> 'obj'?
src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
??? L50: static const Register rtmp????????? = r8;
??????? Nit: These seem to be sorted by register number and not by
???????????? variable name.
??? Addition of the placeholder 'jni_env'; why rename 'robj' -> 'obj'?
Thumbs up on the technical part of this change. My comments are
just about style and about the comments. You should make sure
that you get a review from either Kim or David H. since they
were on the original review team for JDK-8200235.
Dan
>
> Bug ID:
> https://bugs.openjdk.java.net/browse/JDK-8202381
>
> My (long version) analysis on the architectures (that I made changes
> to) of what is going on:
>
> == SPARC ==
>
> This is where the SIGBUS happened. We used to get the jobject/jweak in
> O1, clear the jweak tag in O1, and resolve the handle by loading from
> O1 to O5. This was in fact already broken, since 8176100 "[REDO][REDO]
> G1 Needs pre barrier on dereference of weak JNI handles". The
> registers used to pass the arguments into the C function (O0, O1 and
> O2) must not be touched throughout the call, despite being caller
> saved, as we have not saved the register window. By clearing the jweak
> in O1, the wrong access functions are used in the slow path if the
> speculative load is invalidated, either due to the second safepoint
> counter not being able to the first sampled safepoint counter, or the
> load of the int popping in to the signal handler. I made this problem
> worse in my 8200235 patch by not just clearing O1, but also resolving
> into O1, which clobbered the register even further. This caused
> intermittent failures in the following sequence of events: 1) the
> safepoint counter is read, and we are not in a safepoint, 2) the
> jobject/jweak is resolved, clobbering O1, 3) a safepoint is triggered,
> 4) after resolving the jobject/jweak, the safepoint counter is sampled
> again with a new number, causing a call to the slow path where O1 no
> longer contains the jobject/jweak.
>
> In my proposed changes, this was remedied by moving O1 to O5 first,
> then clearing the jweak value (in O5), then resolving (in O5) and then
> performing the speculative load with all passed C arguments untouched
> in their O1, O2 and O3 registers, as required for the fallback code.
>
> == x86_64 ==
>
> On x86_64, the passed in jobject/jweak is already moved to a separate
> scratch register. Therefore, the problem of clearing the jweak tag in
> the jobject does not apply here. However, rscratch1 was the register I
> picked as a temporary register for resolving. After reading this code
> more carefully, I realize this is the r10 register, which coincides
> with the register used to remember the old counter. So using that
> temporary register is not safe. I chose a new register instead: r8.
> This is, like the other registers used in this code, a caller saved
> register, that does not intersect with the input registers of the
> function arguments. That makes it safe to use in this context. I added
> DEBUG_ONLY code for clobbering this temporary register on x86_64, to
> make sure we more easily catch such problems.
>
> == AArch64 ==
>
> On AArch64, the jobject/jweak is already in r3 when cleared (which
> does not intersect with the registers used in the C calling
> convention, and is caller saved). Therefore, the clearing of the jweak
> tag there is correct, and so is the resolution. The temporary register
> used is r8, which is used as a temporary register by surrounding code
> in this context (and is caller saved).
>
> Apart from this, I also added a jni_env parameter to
> try_resolve_jobject_in_native, which just passes c_rarg0 containing
> the jni environment, without doing anything to it. We need to read
> from this register in ZGC, and I would prefer not to hardcode in the
> backend that c_rarg0 always refers to the jni environment in this
> context.
>
> There are still remaining problems in ARM that the jweak tag is
> cleared in r1, which will cause the slow path to resolve jweaks as
> jobjects. However, I would like to not address that issue in this fix,
> as my original changes did not touch that ARM code. I would like to
> instead file a bug for that to be solved by another brave soul who
> wants to change the jniFastGetField code in the ARM port.
>
> Testing:
> I ran the httpclient tests (that failed because of this) with
> --test-repeat 100, and ran that 3 times. No problems discovered. I am
> also finishing up hs-tier1-3 and jdk-tier1-3.
>
> Thanks,
> /Erik
From shade at redhat.com Mon Apr 30 15:36:02 2018
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 30 Apr 2018 17:36:02 +0200
Subject: RFR(XXS) 8201542: Remove unused _gc_timer field in GCMemoryManager
In-Reply-To: <186a0988-2eab-6734-24af-f1c8c2a8590f@redhat.com>
References: <186a0988-2eab-6734-24af-f1c8c2a8590f@redhat.com>
Message-ID: <f9ddd57b-aed5-6864-3eaf-95cd8bfad7f8@redhat.com>
On 04/30/2018 05:32 PM, Zhengyu Gu wrote:
> Please review this trivial cleanup to remove unused _gc_timer in GCMemoryManager.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201542
> Webrev: http://cr.openjdk.java.net/~zgu/8201542/webrev.00/
Looks good to me.
-Aleksey
From mikhailo.seledtsov at oracle.com Mon Apr 30 15:39:25 2018
From: mikhailo.seledtsov at oracle.com (mikhailo)
Date: Mon, 30 Apr 2018 08:39:25 -0700
Subject: RFR(L) : 8199643 : [TESTBUG] Open source common VM testbase code
In-Reply-To: <314774c1-c43f-47f1-f6ad-8a5f4732e624@oracle.com>
References: <CB612F9B-CBA7-458E-B8AC-39B50E695A08@oracle.com>
<314774c1-c43f-47f1-f6ad-8a5f4732e624@oracle.com>
Message-ID: <6cb0912c-7063-d12a-4d98-ddd3500d564c@oracle.com>
Changes look good to me,
Thank you,
Misha
On 04/28/2018 07:34 AM, Gerald Thornbrugh wrote:
> Hi Igor,
>
> Your changes look good to me.
>
> Thanks!
>
> Jerry
>
>> http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html
>>> 58155 lines changed: 58155 ins; 0 del; 0 mod;
>> Hi all,
>>
>> could you please review this webrev which open sources code shared by
>> many tests from so-called VM testbase?
>>
>> this patch doesn't include any tests, it's rather a preparation step
>> to simplify actual open sourcing of the tests, which will be done
>> later by separate RFEs[*]. the files are intentionally put into a
>> separate directory (test/hotspot/jtreg/vmTestbase) to emphasize that
>> these tests were a part of one "product", most of the code doesn't
>> meet openjdk coding guidelines (or any other coding guidelines for
>> that matter), might be highly coupled and duplicate some existing
>> test and/or test libraries from jtreg test bases. in a long term, we
>> are planning to rework all these tests and make them more like other
>> regular jtreg tests.
>>
>> I'd like to highlight that the code in this webrev isn't new, VM
>> testbase tests have been using it for a long time and these tests
>> have been by Oracle for internal hotspot testing for a long period if
>> time. however as this patch adds "new" native code, I'd really like
>> platforms' maintainers to closely review all .h/.c files (esp.
>> libProcessUtils.c and all the files used by it) as they were never
>> built/executed on platforms other than the ones supported by Oracle.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8199643
>> webrev:
>> http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html
>> testing:
>> ? - all tests which depend on this code
>> ? - build linux-x64, windows-x64, mac-x64, solaris-sparcv9 including
>> open-only variants
>>
>> [*] JBS:(labels = test-opensource and component = hotspot)
>> https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%20test-opensource%20and%20component%20%3D%20hotspot
>>
>>
>> Thanks,
>> -- Igor
>
From erik.osterlund at oracle.com Mon Apr 30 15:53:20 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Mon, 30 Apr 2018 17:53:20 +0200
Subject: RFR: 8202381: (Solaris) SIGBUS in # V [libjvm.so+0xcee494]
jni_GetIntField+0x224
In-Reply-To: <efb3ed09-b8a3-6d26-596e-cae55d3c685d@oracle.com>
References: <5AE71AD3.9090000@oracle.com>
<efb3ed09-b8a3-6d26-596e-cae55d3c685d@oracle.com>
Message-ID: <5AE73BF0.1050801@oracle.com>
Hi Dan,
On 2018-04-30 17:36, Daniel D. Daugherty wrote:
> On 4/30/18 9:32 AM, Erik ?sterlund wrote:
>> Hi,
>>
>> It looks like I broke jniFastGetField on SPARC with my changes to
>> modularize this feature (8200235). Sorry about that. And the backout
>> of that (8202386) didn't go in due to maintenance. So here is a patch
>> to fix the problem instead.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8202381/webrev.00/
>
> src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp
> src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp
> src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp
> Addition of the placeholder 'jni_env'; you went to the trouble
> of changing 'robj' -> 'obj' on the other platforms, but not here
> which is inconsistent.
Fixed. I changed it here too.
Full:
http://cr.openjdk.java.net/~eosterlund/8202381/webrev.01/
Incremental:
http://cr.openjdk.java.net/~eosterlund/8202381/webrev.00_01/
> src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp
> src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp
> Addition of the placeholder 'jni_env'; why rename 'robj' -> 'obj'?
>
> src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp
> Addition of the placeholder 'jni_env'; why rename 'robj' -> 'obj'?
>
I changed the name because no other register in these files have the r
prefix for the register variables (as they do in the jniFastGetField
files), and I simply could not keep my fingers from fixing that
inconsistency.
On SPARC, unlike x86_64, the temporary register (G3) gets immediately
clobbered after calling the try_resolve_jobject_in_native function.
Therefore, I did not bother clobbering it afterwards as it will already
be clobbered. On x86_64 on the other hand, the temporary register (r8)
is not clobbered by the rest of the code, so I decided to explicitly
clobber it so that any mistakes here become more easily reproducible.
> L74: // Both O5 and G3 are clobbered by
> try_resolve_jobject_in_native.
> You are passing 'G3' as 'tmp'. I don't see where/how in
> try_resolve_jobject_in_native() that the 'tmp' parameter gets
> clobbered.
>
It is used by ZGC only to materialize a mask for catching stale pointers.
> src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp
> src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp
> Addition of the placeholder 'jni_env'; why rename 'robj' -> 'obj'?
>
> src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
> L50: static const Register rtmp = r8;
> Nit: These seem to be sorted by register number and not by
> variable name.
>
Fixed the sorting.
> Addition of the placeholder 'jni_env'; why rename 'robj' -> 'obj'?
As mentioned, the robj -> obj change was for consistency with the other
code in these barrier set files.
>
> Thumbs up on the technical part of this change. My comments are
> just about style and about the comments. You should make sure
> that you get a review from either Kim or David H. since they
> were on the original review team for JDK-8200235.
Thanks for the Review Dan!
Thanks,
/Erik
> Dan
>
>
>>
>> Bug ID:
>> https://bugs.openjdk.java.net/browse/JDK-8202381
>>
>> My (long version) analysis on the architectures (that I made changes
>> to) of what is going on:
>>
>> == SPARC ==
>>
>> This is where the SIGBUS happened. We used to get the jobject/jweak
>> in O1, clear the jweak tag in O1, and resolve the handle by loading
>> from O1 to O5. This was in fact already broken, since 8176100
>> "[REDO][REDO] G1 Needs pre barrier on dereference of weak JNI
>> handles". The registers used to pass the arguments into the C
>> function (O0, O1 and O2) must not be touched throughout the call,
>> despite being caller saved, as we have not saved the register window.
>> By clearing the jweak in O1, the wrong access functions are used in
>> the slow path if the speculative load is invalidated, either due to
>> the second safepoint counter not being able to the first sampled
>> safepoint counter, or the load of the int popping in to the signal
>> handler. I made this problem worse in my 8200235 patch by not just
>> clearing O1, but also resolving into O1, which clobbered the register
>> even further. This caused intermittent failures in the following
>> sequence of events: 1) the safepoint counter is read, and we are not
>> in a safepoint, 2) the jobject/jweak is resolved, clobbering O1, 3) a
>> safepoint is triggered, 4) after resolving the jobject/jweak, the
>> safepoint counter is sampled again with a new number, causing a call
>> to the slow path where O1 no longer contains the jobject/jweak.
>>
>> In my proposed changes, this was remedied by moving O1 to O5 first,
>> then clearing the jweak value (in O5), then resolving (in O5) and
>> then performing the speculative load with all passed C arguments
>> untouched in their O1, O2 and O3 registers, as required for the
>> fallback code.
>>
>> == x86_64 ==
>>
>> On x86_64, the passed in jobject/jweak is already moved to a separate
>> scratch register. Therefore, the problem of clearing the jweak tag in
>> the jobject does not apply here. However, rscratch1 was the register
>> I picked as a temporary register for resolving. After reading this
>> code more carefully, I realize this is the r10 register, which
>> coincides with the register used to remember the old counter. So
>> using that temporary register is not safe. I chose a new register
>> instead: r8. This is, like the other registers used in this code, a
>> caller saved register, that does not intersect with the input
>> registers of the function arguments. That makes it safe to use in
>> this context. I added DEBUG_ONLY code for clobbering this temporary
>> register on x86_64, to make sure we more easily catch such problems.
>>
>> == AArch64 ==
>>
>> On AArch64, the jobject/jweak is already in r3 when cleared (which
>> does not intersect with the registers used in the C calling
>> convention, and is caller saved). Therefore, the clearing of the
>> jweak tag there is correct, and so is the resolution. The temporary
>> register used is r8, which is used as a temporary register by
>> surrounding code in this context (and is caller saved).
>>
>> Apart from this, I also added a jni_env parameter to
>> try_resolve_jobject_in_native, which just passes c_rarg0 containing
>> the jni environment, without doing anything to it. We need to read
>> from this register in ZGC, and I would prefer not to hardcode in the
>> backend that c_rarg0 always refers to the jni environment in this
>> context.
>>
>> There are still remaining problems in ARM that the jweak tag is
>> cleared in r1, which will cause the slow path to resolve jweaks as
>> jobjects. However, I would like to not address that issue in this
>> fix, as my original changes did not touch that ARM code. I would like
>> to instead file a bug for that to be solved by another brave soul who
>> wants to change the jniFastGetField code in the ARM port.
>>
>> Testing:
>> I ran the httpclient tests (that failed because of this) with
>> --test-repeat 100, and ran that 3 times. No problems discovered. I am
>> also finishing up hs-tier1-3 and jdk-tier1-3.
>>
>> Thanks,
>> /Erik
>
From daniel.daugherty at oracle.com Mon Apr 30 15:57:45 2018
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 30 Apr 2018 11:57:45 -0400
Subject: RFR: 8202381: (Solaris) SIGBUS in # V [libjvm.so+0xcee494]
jni_GetIntField+0x224
In-Reply-To: <5AE73BF0.1050801@oracle.com>
References: <5AE71AD3.9090000@oracle.com>
<efb3ed09-b8a3-6d26-596e-cae55d3c685d@oracle.com>
<5AE73BF0.1050801@oracle.com>
Message-ID: <836854b7-7c3d-7dee-5147-f71865699c47@oracle.com>
On 4/30/18 11:53 AM, Erik ?sterlund wrote:
> Hi Dan,
>
> On 2018-04-30 17:36, Daniel D. Daugherty wrote:
>> On 4/30/18 9:32 AM, Erik ?sterlund wrote:
>>> Hi,
>>>
>>> It looks like I broke jniFastGetField on SPARC with my changes to
>>> modularize this feature (8200235). Sorry about that. And the backout
>>> of that (8202386) didn't go in due to maintenance. So here is a
>>> patch to fix the problem instead.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~eosterlund/8202381/webrev.00/
>>
>> src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp
>> src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp
>> src/hotspot/cpu/aarch64/jniFastGetField_aarch64.cpp
>> ??? Addition of the placeholder 'jni_env'; you went to the trouble
>> ??? of changing 'robj' -> 'obj' on the other platforms, but not here
>> ??? which is inconsistent.
>
> Fixed. I changed it here too.
>
> Full:
> http://cr.openjdk.java.net/~eosterlund/8202381/webrev.01/
>
> Incremental:
> http://cr.openjdk.java.net/~eosterlund/8202381/webrev.00_01/
>
>> src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.cpp
>> src/hotspot/cpu/sparc/gc/shared/barrierSetAssembler_sparc.hpp
>> ??? Addition of the placeholder 'jni_env'; why rename 'robj' -> 'obj'?
>>
>> src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp
>> ??? Addition of the placeholder 'jni_env'; why rename 'robj' -> 'obj'?
>>
>
> I changed the name because no other register in these files have the r
> prefix for the register variables (as they do in the jniFastGetField
> files), and I simply could not keep my fingers from fixing that
> inconsistency.
Sounds good. Thanks for explaining.
> On SPARC, unlike x86_64, the temporary register (G3) gets immediately
> clobbered after calling the try_resolve_jobject_in_native function.
How/where? I just don't see it, but my SPARC assembly is rusty...
> Therefore, I did not bother clobbering it afterwards as it will
> already be clobbered. On x86_64 on the other hand, the temporary
> register (r8) is not clobbered by the rest of the code, so I decided
> to explicitly clobber it so that any mistakes here become more easily
> reproducible.
Yup. I liked that change.
>
>> ??? L74:?? // Both O5 and G3 are clobbered by
>> try_resolve_jobject_in_native.
>> ??????? You are passing 'G3' as 'tmp'. I don't see where/how in
>> ??????? try_resolve_jobject_in_native() that the 'tmp' parameter gets
>> ??????? clobbered.
>>
>
> It is used by ZGC only to materialize a mask for catching stale pointers.
So G3 only gets clobbered with ZGC (which is not yet in this code base)?
>
>> src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp
>> src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp
>> ??? Addition of the placeholder 'jni_env'; why rename 'robj' -> 'obj'?
>>
>> src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
>> ??? L50: static const Register rtmp????????? = r8;
>> ??????? Nit: These seem to be sorted by register number and not by
>> ???????????? variable name.
>>
>
> Fixed the sorting.
>
>> ??? Addition of the placeholder 'jni_env'; why rename 'robj' -> 'obj'?
>
> As mentioned, the robj -> obj change was for consistency with the
> other code in these barrier set files.
>
>>
>> Thumbs up on the technical part of this change. My comments are
>> just about style and about the comments. You should make sure
>> that you get a review from either Kim or David H. since they
>> were on the original review team for JDK-8200235.
>
> Thanks for the Review Dan!
You're welcome. It would be good to get this fix in today if at all
possible... Once your fix is in, we can close my BACKOUT bug as "will
not fix"...
Dan
>
> Thanks,
> /Erik
>
>> Dan
>>
>>
>>>
>>> Bug ID:
>>> https://bugs.openjdk.java.net/browse/JDK-8202381
>>>
>>> My (long version) analysis on the architectures (that I made changes
>>> to) of what is going on:
>>>
>>> == SPARC ==
>>>
>>> This is where the SIGBUS happened. We used to get the jobject/jweak
>>> in O1, clear the jweak tag in O1, and resolve the handle by loading
>>> from O1 to O5. This was in fact already broken, since 8176100
>>> "[REDO][REDO] G1 Needs pre barrier on dereference of weak JNI
>>> handles". The registers used to pass the arguments into the C
>>> function (O0, O1 and O2) must not be touched throughout the call,
>>> despite being caller saved, as we have not saved the register
>>> window. By clearing the jweak in O1, the wrong access functions are
>>> used in the slow path if the speculative load is invalidated, either
>>> due to the second safepoint counter not being able to the first
>>> sampled safepoint counter, or the load of the int popping in to the
>>> signal handler. I made this problem worse in my 8200235 patch by not
>>> just clearing O1, but also resolving into O1, which clobbered the
>>> register even further. This caused intermittent failures in the
>>> following sequence of events: 1) the safepoint counter is read, and
>>> we are not in a safepoint, 2) the jobject/jweak is resolved,
>>> clobbering O1, 3) a safepoint is triggered, 4) after resolving the
>>> jobject/jweak, the safepoint counter is sampled again with a new
>>> number, causing a call to the slow path where O1 no longer contains
>>> the jobject/jweak.
>>>
>>> In my proposed changes, this was remedied by moving O1 to O5 first,
>>> then clearing the jweak value (in O5), then resolving (in O5) and
>>> then performing the speculative load with all passed C arguments
>>> untouched in their O1, O2 and O3 registers, as required for the
>>> fallback code.
>>>
>>> == x86_64 ==
>>>
>>> On x86_64, the passed in jobject/jweak is already moved to a
>>> separate scratch register. Therefore, the problem of clearing the
>>> jweak tag in the jobject does not apply here. However, rscratch1 was
>>> the register I picked as a temporary register for resolving. After
>>> reading this code more carefully, I realize this is the r10
>>> register, which coincides with the register used to remember the old
>>> counter. So using that temporary register is not safe. I chose a new
>>> register instead: r8. This is, like the other registers used in this
>>> code, a caller saved register, that does not intersect with the
>>> input registers of the function arguments. That makes it safe to use
>>> in this context. I added DEBUG_ONLY code for clobbering this
>>> temporary register on x86_64, to make sure we more easily catch such
>>> problems.
>>>
>>> == AArch64 ==
>>>
>>> On AArch64, the jobject/jweak is already in r3 when cleared (which
>>> does not intersect with the registers used in the C calling
>>> convention, and is caller saved). Therefore, the clearing of the
>>> jweak tag there is correct, and so is the resolution. The temporary
>>> register used is r8, which is used as a temporary register by
>>> surrounding code in this context (and is caller saved).
>>>
>>> Apart from this, I also added a jni_env parameter to
>>> try_resolve_jobject_in_native, which just passes c_rarg0 containing
>>> the jni environment, without doing anything to it. We need to read
>>> from this register in ZGC, and I would prefer not to hardcode in the
>>> backend that c_rarg0 always refers to the jni environment in this
>>> context.
>>>
>>> There are still remaining problems in ARM that the jweak tag is
>>> cleared in r1, which will cause the slow path to resolve jweaks as
>>> jobjects. However, I would like to not address that issue in this
>>> fix, as my original changes did not touch that ARM code. I would
>>> like to instead file a bug for that to be solved by another brave
>>> soul who wants to change the jniFastGetField code in the ARM port.
>>>
>>> Testing:
>>> I ran the httpclient tests (that failed because of this) with
>>> --test-repeat 100, and ran that 3 times. No problems discovered. I
>>> am also finishing up hs-tier1-3 and jdk-tier1-3.
>>>
>>> Thanks,
>>> /Erik
>>
>
From zgu at redhat.com Mon Apr 30 16:25:21 2018
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 30 Apr 2018 12:25:21 -0400
Subject: RFR(XXS) 8201542: Remove unused _gc_timer field in GCMemoryManager
In-Reply-To: <f9ddd57b-aed5-6864-3eaf-95cd8bfad7f8@redhat.com>
References: <186a0988-2eab-6734-24af-f1c8c2a8590f@redhat.com>
<f9ddd57b-aed5-6864-3eaf-95cd8bfad7f8@redhat.com>
Message-ID: <95d4097c-47b3-9faf-bdcd-1b2885194373@redhat.com>
Hi Aleksey,
Thanks for the review.
-Zhengyu
On 04/30/2018 11:36 AM, Aleksey Shipilev wrote:
> On 04/30/2018 05:32 PM, Zhengyu Gu wrote:
>> Please review this trivial cleanup to remove unused _gc_timer in GCMemoryManager.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201542
>> Webrev: http://cr.openjdk.java.net/~zgu/8201542/webrev.00/
>
> Looks good to me.
>
> -Aleksey
>
From kim.barrett at oracle.com Mon Apr 30 18:31:31 2018
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 30 Apr 2018 14:31:31 -0400
Subject: RFR: 8202381: (Solaris) SIGBUS in # V [libjvm.so+0xcee494]
jni_GetIntField+0x224
In-Reply-To: <5AE73BF0.1050801@oracle.com>
References: <5AE71AD3.9090000@oracle.com>
<efb3ed09-b8a3-6d26-596e-cae55d3c685d@oracle.com>
<5AE73BF0.1050801@oracle.com>
Message-ID: <4FE8E55A-0661-49CC-8DC1-CED5B1DE9986@oracle.com>
> On Apr 30, 2018, at 11:53 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>
> Fixed. I changed it here too.
>
> Full:
> http://cr.openjdk.java.net/~eosterlund/8202381/webrev.01/
>
> Incremental:
> http://cr.openjdk.java.net/~eosterlund/8202381/webrev.00_01/
Changes look good.
However, I noticed a couple of issues that are probably out of scope
for getting JDK-8202381 fixed in a timely fashion. Please file a
followup RFR or two to address these.
------------------------------------------------------------------------------
try_resolve_jobject_in_native slowpath is non-const reference. Seems
like it should be const. Sorry I missed this in the review of
JDK-8200235.
------------------------------------------------------------------------------
src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp
JNI_FastGetField::generate_fast_get_long_field
JNIFastGetField::generate_fast_get_float_field
src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
JNI_FastGetField::generate_fast_get_float_field0
Seems like these functions should also be using
try_resolve_jobject_in_native. Sorry I missed this in the review of
JDK-8200235.
I didn't look at other platforms to see if there are similar issues
elsewhere.
------------------------------------------------------------------------------
From igor.ignatyev at oracle.com Mon Apr 30 19:03:22 2018
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 30 Apr 2018 12:03:22 -0700
Subject: RFR(L) : 8199643 : [TESTBUG] Open source common VM testbase code
In-Reply-To: <6cb0912c-7063-d12a-4d98-ddd3500d564c@oracle.com>
References: <CB612F9B-CBA7-458E-B8AC-39B50E695A08@oracle.com>
<314774c1-c43f-47f1-f6ad-8a5f4732e624@oracle.com>
<6cb0912c-7063-d12a-4d98-ddd3500d564c@oracle.com>
Message-ID: <76919AD8-E0EF-4DEB-BA0D-3761A8D26695@oracle.com>
Jerry, Misha,
thank you for your review.
adding build-dev alias as the patch includes makefiles changes.
-- Igor
> On Apr 30, 2018, at 8:39 AM, mikhailo <mikhailo.seledtsov at oracle.com> wrote:
>
> Changes look good to me,
>
> Thank you,
>
> Misha
>
>
> On 04/28/2018 07:34 AM, Gerald Thornbrugh wrote:
>> Hi Igor,
>>
>> Your changes look good to me.
>>
>> Thanks!
>>
>> Jerry
>>
>>> http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html
>>>> 58155 lines changed: 58155 ins; 0 del; 0 mod;
>>> Hi all,
>>>
>>> could you please review this webrev which open sources code shared by many tests from so-called VM testbase?
>>>
>>> this patch doesn't include any tests, it's rather a preparation step to simplify actual open sourcing of the tests, which will be done later by separate RFEs[*]. the files are intentionally put into a separate directory (test/hotspot/jtreg/vmTestbase) to emphasize that these tests were a part of one "product", most of the code doesn't meet openjdk coding guidelines (or any other coding guidelines for that matter), might be highly coupled and duplicate some existing test and/or test libraries from jtreg test bases. in a long term, we are planning to rework all these tests and make them more like other regular jtreg tests.
>>>
>>> I'd like to highlight that the code in this webrev isn't new, VM testbase tests have been using it for a long time and these tests have been by Oracle for internal hotspot testing for a long period if time. however as this patch adds "new" native code, I'd really like platforms' maintainers to closely review all .h/.c files (esp. libProcessUtils.c and all the files used by it) as they were never built/executed on platforms other than the ones supported by Oracle.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8199643
>>> webrev: http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html
>>> testing:
>>> - all tests which depend on this code
>>> - build linux-x64, windows-x64, mac-x64, solaris-sparcv9 including open-only variants
>>>
>>> [*] JBS:(labels = test-opensource and component = hotspot)
>>> https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%20test-opensource%20and%20component%20%3D%20hotspot
>>>
>>> Thanks,
>>> -- Igor
>>
>
From erik.joelsson at oracle.com Mon Apr 30 19:22:28 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 30 Apr 2018 12:22:28 -0700
Subject: RFR(L) : 8199643 : [TESTBUG] Open source common VM testbase code
In-Reply-To: <76919AD8-E0EF-4DEB-BA0D-3761A8D26695@oracle.com>
References: <CB612F9B-CBA7-458E-B8AC-39B50E695A08@oracle.com>
<314774c1-c43f-47f1-f6ad-8a5f4732e624@oracle.com>
<6cb0912c-7063-d12a-4d98-ddd3500d564c@oracle.com>
<76919AD8-E0EF-4DEB-BA0D-3761A8D26695@oracle.com>
Message-ID: <8fc744b0-a594-4dcf-53df-bc1b5800908b@oracle.com>
Build changes look good.
/Erik
On 2018-04-30 12:03, Igor Ignatyev wrote:
> Jerry, Misha,
>
> thank you for your review.
>
> adding build-dev alias as the patch includes makefiles changes.
>
> -- Igor
>
>> On Apr 30, 2018, at 8:39 AM, mikhailo <mikhailo.seledtsov at oracle.com> wrote:
>>
>> Changes look good to me,
>>
>> Thank you,
>>
>> Misha
>>
>>
>> On 04/28/2018 07:34 AM, Gerald Thornbrugh wrote:
>>> Hi Igor,
>>>
>>> Your changes look good to me.
>>>
>>> Thanks!
>>>
>>> Jerry
>>>
>>>> http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html
>>>>> 58155 lines changed: 58155 ins; 0 del; 0 mod;
>>>> Hi all,
>>>>
>>>> could you please review this webrev which open sources code shared by many tests from so-called VM testbase?
>>>>
>>>> this patch doesn't include any tests, it's rather a preparation step to simplify actual open sourcing of the tests, which will be done later by separate RFEs[*]. the files are intentionally put into a separate directory (test/hotspot/jtreg/vmTestbase) to emphasize that these tests were a part of one "product", most of the code doesn't meet openjdk coding guidelines (or any other coding guidelines for that matter), might be highly coupled and duplicate some existing test and/or test libraries from jtreg test bases. in a long term, we are planning to rework all these tests and make them more like other regular jtreg tests.
>>>>
>>>> I'd like to highlight that the code in this webrev isn't new, VM testbase tests have been using it for a long time and these tests have been by Oracle for internal hotspot testing for a long period if time. however as this patch adds "new" native code, I'd really like platforms' maintainers to closely review all .h/.c files (esp. libProcessUtils.c and all the files used by it) as they were never built/executed on platforms other than the ones supported by Oracle.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8199643
>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html
>>>> testing:
>>>> - all tests which depend on this code
>>>> - build linux-x64, windows-x64, mac-x64, solaris-sparcv9 including open-only variants
>>>>
>>>> [*] JBS:(labels = test-opensource and component = hotspot)
>>>> https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%20test-opensource%20and%20component%20%3D%20hotspot
>>>>
>>>> Thanks,
>>>> -- Igor
From gerard.ziemski at oracle.com Mon Apr 30 19:23:11 2018
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Mon, 30 Apr 2018 14:23:11 -0500
Subject: RFR(L) 8195099: Low latency hashtable for read-mostly scenarios
In-Reply-To: <1cc85bdc-98cb-115d-a904-4cf1c94259b2@oracle.com>
References: <1cc85bdc-98cb-115d-a904-4cf1c94259b2@oracle.com>
Message-ID: <0CCE37A8-A9AA-414E-9898-5B875B647BE6@oracle.com>
hi Robbin,
Still reviewing, but I have a couple of questions and some feedback I wanted to ask/share with you so far:
#1 Where does the choice of "12" for _task_size_log2 come from in:
BucketsOperation(ConcurrentHashTable<VALUE, CONFIG, F>* cht)
: _cht(cht), _next_to_claim(0), _task_size_log2(12),
_stop_task(0), _size_log2(0) {}
Shouldn't "12" be a constant?
#2 Where does "8192" come from in:
// SpinYield would be unfair here
while (!this->trylock()) {
if ((++i) == 8192) {
Shouldn't "8192" be a constant?
#3 How come "_first" doesn't need to be volatile to be used in Atomic::cmpxchg ?
Node* _first;
...
if (Atomic::cmpxchg(node, &_first, expect) == expect) {
#4 Inconsistent parameter names - in:
template <typename LOOKUP_FUNC, typename VALUE_FUNC>
bool get_insert_lazy(Thread* thread, LOOKUP_FUNC& lookup, VALUE_FUNC& val_f,
bool* grow_hint = NULL) {
return get_insert_lazy(thread, lookup, val_f, noOp, grow_hint);
}
We use "val_f" with "_f? suffix, so we should have "lookup_f", not "lookup" (many other instances) and "found_f", not "foundf" in
template <typename LOOKUP_FUNC, typename FOUND_FUNC>
bool get(Thread* thread, LOOKUP_FUNC& lookup, FOUND_FUNC& foundf,
bool* grow_hint = NULL);
#5 I wasn't familiar with CRTP, so I read up on it, but I still don't see the CRTP in BaseConfig - which is the base class and which is derived? In particular I don't see "class Derived : public Base<Derived>" pattern here?
More to come?
btw. I edited the subject of the email slightly by adding the bug number to it, so it?s easy to search for.
cheers
> On Apr 26, 2018, at 2:38 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>
>
> Hi all, please review.
>
> The lower latency of the new gcs have higher demands on runtime data-structure
> in terms of latency. This is a concurrent hashtable using the global-counter
> (8195099).
>
> Webrev:
> http://cr.openjdk.java.net/~rehn/8195098/v0/webrev/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8195098
>
> * Readers never blocks or spins.
> * Inserts do CAS from a read-side, need to re-CAS during re-size/deletion in targeted bucket or insert collision. (inserts are conceptually a reader)
> * Deletes locks the targeted bucket, all other buckets are free for operations.
> * Re-size locks one bucket at the time, all other buckets are free for operations.
>
> It does concurrent re-size by doubling size and use one more bit from hash.
> That means a bucket in the old table contains nodes to either one of two buckets
> in the new table. Each node in the chain is sorted into one of the two buckets
> with concurrent readers. Shrinking just take two node chains and put them
> together in the corresponding bucket. To keep track of what is visible to the
> concurrent readers it's uses a global-counter, needed during re-size and for
> deletes.
>
> A gtest is provided which passes on our platforms, we also have a prototype of the stringtable using this which passes tier 1-5 on our platforms.
>
> Various people have pre-reviewed various parts, thanks! And a special thanks to
> Coleen for a lot of reviewing!
>
> Thanks, Robbin
From erik.osterlund at oracle.com Mon Apr 30 19:46:45 2018
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Mon, 30 Apr 2018 21:46:45 +0200
Subject: RFR: 8202381: (Solaris) SIGBUS in # V [libjvm.so+0xcee494]
jni_GetIntField+0x224
In-Reply-To: <4FE8E55A-0661-49CC-8DC1-CED5B1DE9986@oracle.com>
References: <5AE71AD3.9090000@oracle.com>
<efb3ed09-b8a3-6d26-596e-cae55d3c685d@oracle.com>
<5AE73BF0.1050801@oracle.com>
<4FE8E55A-0661-49CC-8DC1-CED5B1DE9986@oracle.com>
Message-ID: <44b99677-71d4-2403-3473-0d378451798f@oracle.com>
Hi Kim,
On 2018-04-30 20:31, Kim Barrett wrote:
>> On Apr 30, 2018, at 11:53 AM, Erik ?sterlund <erik.osterlund at oracle.com> wrote:
>>
>> Fixed. I changed it here too.
>>
>> Full:
>> http://cr.openjdk.java.net/~eosterlund/8202381/webrev.01/
>>
>> Incremental:
>> http://cr.openjdk.java.net/~eosterlund/8202381/webrev.00_01/
> Changes look good.
Thanks for the review.
> However, I noticed a couple of issues that are probably out of scope
> for getting JDK-8202381 fixed in a timely fashion. Please file a
> followup RFR or two to address these.
>
> ------------------------------------------------------------------------------
> try_resolve_jobject_in_native slowpath is non-const reference. Seems
> like it should be const. Sorry I missed this in the review of
> JDK-8200235.
>
> ------------------------------------------------------------------------------
> src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp
> JNI_FastGetField::generate_fast_get_long_field
> JNIFastGetField::generate_fast_get_float_field
>
> src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp
> JNI_FastGetField::generate_fast_get_float_field0
>
> Seems like these functions should also be using
> try_resolve_jobject_in_native. Sorry I missed this in the review of
> JDK-8200235.
>
> I didn't look at other platforms to see if there are similar issues
> elsewhere.
>
> ------------------------------------------------------------------------------
I will file a follow-up RFR for this.
Thanks,
/Erik
From yumin.qi at gmail.com Mon Apr 30 20:30:50 2018
From: yumin.qi at gmail.com (yumin qi)
Date: Mon, 30 Apr 2018 13:30:50 -0700
Subject: RFR(XXS) 8201542: Remove unused _gc_timer field in GCMemoryManager
In-Reply-To: <186a0988-2eab-6734-24af-f1c8c2a8590f@redhat.com>
References: <186a0988-2eab-6734-24af-f1c8c2a8590f@redhat.com>
Message-ID: <CAOEheN7L6ixf+KUK7qyec89KREq-9xi_gqKpKW83OvLYEvcX=w@mail.gmail.com>
Looks good.
Thanks
Yumin
On Mon, Apr 30, 2018 at 8:32 AM, Zhengyu Gu <zgu at redhat.com> wrote:
> Please review this trivial cleanup to remove unused _gc_timer in
> GCMemoryManager.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201542
> Webrev: http://cr.openjdk.java.net/~zgu/8201542/webrev.00/
>
> Test:
> hotspot_servicebility on Linux x64 (fastdebug and release)
>
> Thanks,
>
> -Zhengyu
>
From vladimir.x.ivanov at oracle.com Mon Apr 30 21:26:26 2018
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 30 Apr 2018 14:26:26 -0700
Subject: RFR(L) : 8199643 : [TESTBUG] Open source common VM testbase code
In-Reply-To: <413B3056-A7D2-4AB8-A8AB-D43F23CD846C@oracle.com>
References: <CB612F9B-CBA7-458E-B8AC-39B50E695A08@oracle.com>
<413B3056-A7D2-4AB8-A8AB-D43F23CD846C@oracle.com>
Message-ID: <028d999d-28a4-ff9f-b1cb-b468f3331c41@oracle.com>
Looks good.
Best regards,
Vladimir Ivanov
On 4/27/18 15:06, Igor Ignatyev wrote:
> pasted a wrong link, here is the right one -- http://cr.openjdk.java.net/~iignatyev/8199643/webrev.00/index.html <http://cr.openjdk.java.net/~iignatyev/8199643/webrev.00/index.html>
>
> -- Igor
>
>> On Apr 27, 2018, at 2:50 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>
>> http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html
>>> 58155 lines changed: 58155 ins; 0 del; 0 mod;
>>
>> Hi all,
>>
>> could you please review this webrev which open sources code shared by many tests from so-called VM testbase?
>>
>> this patch doesn't include any tests, it's rather a preparation step to simplify actual open sourcing of the tests, which will be done later by separate RFEs[*]. the files are intentionally put into a separate directory (test/hotspot/jtreg/vmTestbase) to emphasize that these tests were a part of one "product", most of the code doesn't meet openjdk coding guidelines (or any other coding guidelines for that matter), might be highly coupled and duplicate some existing test and/or test libraries from jtreg test bases. in a long term, we are planning to rework all these tests and make them more like other regular jtreg tests.
>>
>> I'd like to highlight that the code in this webrev isn't new, VM testbase tests have been using it for a long time and these tests have been by Oracle for internal hotspot testing for a long period if time. however as this patch adds "new" native code, I'd really like platforms' maintainers to closely review all .h/.c files (esp. libProcessUtils.c and all the files used by it) as they were never built/executed on platforms other than the ones supported by Oracle.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8199643
>> webrev: http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html
>> testing:
>> - all tests which depend on this code
>> - build linux-x64, windows-x64, mac-x64, solaris-sparcv9 including open-only variants
>>
>> [*] JBS:(labels = test-opensource and component = hotspot)
>> https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%20test-opensource%20and%20component%20%3D%20hotspot
>>
>> Thanks,
>> -- Igor
>
From david.holmes at oracle.com Mon Apr 30 21:35:16 2018
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 1 May 2018 07:35:16 +1000
Subject: RFR(XXS) 8201542: Remove unused _gc_timer field in GCMemoryManager
In-Reply-To: <186a0988-2eab-6734-24af-f1c8c2a8590f@redhat.com>
References: <186a0988-2eab-6734-24af-f1c8c2a8590f@redhat.com>
Message-ID: <6126c73b-9166-d57c-b238-913da7240a1e@oracle.com>
Hi Zhengyu,
Your patch is based off the wrong repo - jdk/hs. Please update to jdk/jdk.
Thanks,
David
On 1/05/2018 1:32 AM, Zhengyu Gu wrote:
> Please review this trivial cleanup to remove unused _gc_timer in
> GCMemoryManager.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201542
> Webrev: http://cr.openjdk.java.net/~zgu/8201542/webrev.00/
>
> Test:
> ? hotspot_servicebility on Linux x64 (fastdebug and release)
>
> Thanks,
>
> -Zhengyu
From coleen.phillimore at oracle.com Mon Apr 30 22:18:53 2018
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 30 Apr 2018 18:18:53 -0400
Subject: RFR(L): Low latency hashtable for read-mostly scenarios
In-Reply-To: <1cc85bdc-98cb-115d-a904-4cf1c94259b2@oracle.com>
References: <1cc85bdc-98cb-115d-a904-4cf1c94259b2@oracle.com>
Message-ID: <00344c0b-6122-be48-53e8-4d9a99bb2b6b@oracle.com>
Robbin,
What is gi_bd in these names in the test?? Can you give them more
descriptive names?
cht_gi_bd_insert_new
cht_gi_bd_get_old
Are they get/insert bulk/delete?
I'm fine with the rest of the code.?? It's a huge project and it enables
concurrent string and symbol table cleanup, so this is a big enhancement.
thanks,
Coleen
On 4/26/18 3:38 AM, Robbin Ehn wrote:
>
> Hi all, please review.
>
> The lower latency of the new gcs have higher demands on runtime
> data-structure
> in terms of latency. This is a concurrent hashtable using the
> global-counter
> (8195099).
>
> Webrev:
> http://cr.openjdk.java.net/~rehn/8195098/v0/webrev/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8195098
>
> * Readers never blocks or spins.
> * Inserts do CAS from a read-side, need to re-CAS during
> re-size/deletion in targeted bucket or insert collision. (inserts are
> conceptually a reader)
> * Deletes locks the targeted bucket, all other buckets are free for
> operations.
> * Re-size locks one bucket at the time, all other buckets are free for
> operations.
>
> It does concurrent re-size by doubling size and use one more bit from
> hash.
> That means a bucket in the old table contains nodes to either one of
> two buckets
> in the new table. Each node in the chain is sorted into one of the two
> buckets
> with concurrent readers. Shrinking just take two node chains and put them
> together in the corresponding bucket. To keep track of what is visible
> to the
> concurrent readers it's uses a global-counter, needed during re-size
> and for
> deletes.
>
> A gtest is provided which passes on our platforms, we also have a
> prototype of the stringtable using this which passes tier 1-5 on our
> platforms.
>
> Various people have pre-reviewed various parts, thanks! And a special
> thanks to
> Coleen for a lot of reviewing!
>
> Thanks, Robbin