RFR (XL): 8152664 - Support non-continuous CodeBlobs in HotSpot
Rickard Bäckman
rickard.backman at oracle.com
Mon Apr 11 09:12:21 UTC 2016
On 04/07, Volker Simonis wrote:
> Hi Rickard,
>
> I'd also like to know what's the rational behind this quite large
> change. Do you expect some performance or memory consumption
> improvements or is this a prerequisite for another change which is
> still to come?
>
> The change itself currently doesn't work on ppc64 (neither on Linux
> nor on AIX). I get the following crash during the build when the newly
> built Hotspot is JIT-compiling java.lang.String::charAt on C1 :
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x00001000012a44d0, pid=35331, tid=35404
> #
> # JRE version: OpenJDK Runtime Environment (9.0) (slowdebug build
> 9-internal+0-2016-04-07-162501.d046063.jdk9-hs-comp)
> # Java VM: OpenJDK 64-Bit Server VM (slowdebug
> 9-internal+0-2016-04-07-162501.d046063.jdk9-hs-comp, mixed mode,
> tiered, compressed oo
> ps, serial gc, linux-ppc64le)
> # Problematic frame:
> # V [libjvm.so+0xf744d0] outputStream::do_vsnprintf_and_write(char
> const*, char*, bool)+0x40
> #
> # No core dump will be written. Core dumps have been disabled. To
> enable core dumping, try "ulimit -c unlimited" before starting Java
> again
> #
> # If you would like to submit a bug report, please visit:
> # http://bugreport.java.com/bugreport/crash.jsp
> #
>
> --------------- S U M M A R Y ------------
>
> Command Line: -Dapplication.home=/sapmnt/ld9510/a/d046063/output-jdk9-hs-comp-dbg/jdk
> -Xms8m -XX:+UseSerialGC -Xms32M -Xmx512M -Djdk.
> module.main=jdk.jlink jdk.jlink/jdk.tools.jmod.Main create
> --module-version 9-internal --os-name Linux --os-arch ppc64le
> --os-version
> 2.6 --modulepath /priv/d046063/output-jdk9-hs-comp-dbg/images/jmods
> --hash-dependencies .* --exclude **_the.* --libs
> /priv/d046063/output-jdk9-hs-comp-dbg/support/modules_libs-stripped/java.base
> --cmds /priv/d046063/output-jdk9-hs-comp-dbg/support/modules_cmds-stripped/java.base
> --config /priv/d046063/output-jdk9-hs-comp-dbg/support/modules_conf/java.base
> --class-path /priv/d046063/output-jdk9-hs-comp-dbg/jdk/modules/java.base
> /priv/d046063/output-jdk9-hs-comp-dbg/support/jmods/java.base.jmod
>
> Host: ld9510, POWER8E (raw), altivec supported, 48 cores, 61G, #
> Please check /etc/os-release for details about this release.
> Time: Thu Apr 7 16:28:55 2016 CEST elapsed time: 0 seconds (0d 0h 0m 0s)
>
> --------------- T H R E A D ---------------
>
> Current thread (0x000010000429c800): JavaThread "C1 CompilerThread10"
> daemon [_thread_in_vm, id=35404,
> stack(0x000010006a800000,0x000010006ac00000)]
>
>
> Current CompileTask:
> C1: 761 3 3 java.lang.String::charAt (25 bytes)
>
> Stack: [0x000010006a800000,0x000010006ac00000],
> sp=0x000010006abfc6c0, free space=4081k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V [libjvm.so+0xf744d0] outputStream::do_vsnprintf_and_write(char
> const*, char*, bool)+0x40
> V [libjvm.so+0xf74668] outputStream::print_cr(char const*, ...)+0x68
> V [libjvm.so+0x72189c] CodeBlob::print_on(outputStream*) const+0x50
> V [libjvm.so+0x723bdc] RuntimeBlob::print_on(outputStream*) const+0x40
> V [libjvm.so+0x721eb0] SingletonBlob::print_on(outputStream*) const+0x4c
> V [libjvm.so+0x106d51c] RelocIterator::initialize(CompiledMethod*,
> unsigned char*, unsigned char*)+0x170
> V [libjvm.so+0x5ae56c] RelocIterator::RelocIterator(CompiledMethod*,
> unsigned char*, unsigned char*)+0x78
> V [libjvm.so+0x10719dc]
> trampoline_stub_Relocation::get_trampoline_for(unsigned char*,
> nmethod*)+0x78
> V [libjvm.so+0xefb80c] NativeCall::get_trampoline()+0x110
> V [libjvm.so+0x1076914] Relocation::pd_call_destination(unsigned char*)+0x150
> V [libjvm.so+0x106f5fc]
> CallRelocation::fix_relocation_after_move(CodeBuffer const*,
> CodeBuffer*)+0x74
> V [libjvm.so+0x728898] CodeBuffer::relocate_code_to(CodeBuffer*) const+0x390
> V [libjvm.so+0x728404] CodeBuffer::copy_code_to(CodeBlob*)+0x134
> V [libjvm.so+0x722670] CodeBuffer::copy_code_and_locs_to(CodeBlob*)+0x84
> V [libjvm.so+0x71f834] CodeBlob::CodeBlob(char const*,
> CodeBlobLayout const&, CodeBuffer*, int, int, OopMapSet*, bool,
> int)+0x320
> V [libjvm.so+0x7c52c8] CompiledMethod::CompiledMethod(Method*, char
> const*, int, int, CodeBuffer*, int, int, OopMapSet*, bool)+0xd8
> V [libjvm.so+0xf01f58] nmethod::nmethod(Method*, int, int, int,
> CodeOffsets*, int, DebugInformationRecorder*, Dependencies*,
> CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*,
> ImplicitExceptionTable*, AbstractCompiler*, int)+0xe0
> V [libjvm.so+0xf01610] nmethod::new_nmethod(methodHandle const&,
> int, int, CodeOffsets*, int, DebugInformationRecorder*, Dependencies*,
> CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*,
> ImplicitExceptionTable*, AbstractCompiler*, int)+0x2c4
> V [libjvm.so+0x632970] ciEnv::register_method(ciMethod*, int,
> CodeOffsets*, int, CodeBuffer*, int, OopMapSet*,
> ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*,
> bool, bool, RTMState)+0x560
> V [libjvm.so+0x48ee00] Compilation::install_code(int)+0x264
> V [libjvm.so+0x48eff8] Compilation::compile_method()+0x184
> V [libjvm.so+0x48f7a8] Compilation::Compilation(AbstractCompiler*,
> ciEnv*, ciMethod*, int, BufferBlob*, DirectiveSet*)+0x288
> V [libjvm.so+0x4980d0] Compiler::compile_method(ciEnv*, ciMethod*,
> int, DirectiveSet*)+0xc8
> V [libjvm.so+0x7b188c]
> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x590
> V [libjvm.so+0x7b07bc] CompileBroker::compiler_thread_loop()+0x310
> V [libjvm.so+0x11a614c] compiler_thread_entry(JavaThread*, Thread*)+0xa0
> V [libjvm.so+0x119f3a8] JavaThread::thread_main_inner()+0x1b4
> V [libjvm.so+0x119f1a4] JavaThread::run()+0x1b8
> V [libjvm.so+0xf53d90] java_start(Thread*)+0x204
> C [libpthread.so.0+0x8a64] start_thread+0xf4
> C [libc.so.6+0x1032a0] clone+0x98
>
> I haven't identified the exact cause (will analyze it tomorrow) but
> the stack trace indicates that it is indeed related to your changes.
>
> Besides that I have some comments:
>
> codeBuffer.hpp:
>
> 472 CodeSection* insts() { return &_insts; }
> 475 const CodeSection* insts() const { return &_insts; }
>
> - do we really need both versions?
Really need? No. But there would be a ripple effect of removing const
from a couple of places. If you really disagree with having both of them
I can make it happen.
>
> codeBlob.hpp:
>
> 135 nmethod* as_nmethod_or_null() const { return
> is_nmethod() ? (nmethod*) this : NULL; }
> 136 nmethod* as_nmethod() const {
> assert(is_nmethod(), "must be nmethod"); return (nmethod*) this; }
> 137 CompiledMethod* as_compiled_method_or_null() const { return
> is_compiled() ? (CompiledMethod*) this : NULL; }
> 138 CompiledMethod* as_compiled_method() const {
> assert(is_compiled(), "must be compiled"); return (CompiledMethod*)
> this; }
> 139 CodeBlob* as_codeblob_or_null() const { return
> (CodeBlob*) this; }
>
> - I don't like this code. You make the getters 'const' which
> implicitely makes 'this' a "pointer to const" but then the returned
> pointer is a normal pointer to a non-const object and therefore you
> have to statically cast away the "pointer to const" (that's why you
> need the cast even in the case where you return a CodeBlob*). So
> either remove the const qualifier from the method declarations or make
> them return "pointers to const". And by the way, as_codeblob_or_null()
> doesn't seemed to be used anywhere in the code, why do we need it at
> all?
You are right. I removed const from these methods.
>
> - Why do we need the non-virtual methods is_nmethod() and
> is_compiled() to manually simulate virtual behavior. Why can't we
> simply make them virtual and implement them accordingly in nmathod and
> CompiledMethod?
When we made the changes and did performance measures we noticed that
there were now more calls to is_compiled() and is_nmethod() then there
used to be. In certain paths it made an impact on performance so we
tried this way instead. I can try both versions again and see if the
numbers matters.
>
> Regards,
> Volker
>
> On Thu, Apr 7, 2016 at 2:12 PM, Rickard Bäckman
> <rickard.backman at oracle.com> wrote:
> > Hi,
> >
> > can I please have review for this patch please?
> >
> > So far CodeBlobs have required all the data (metadata, oops, code, etc)
> > to be in one continuous blob With this patch we are looking to change
> > that. It's been done by changing offsets in CodeBlob to addresses,
> > making some methods virtual to allow different behavior and also
> > creating a couple of new classes. CompiledMethod now sits inbetween
> > CodeBlob and nmethod.
> >
> > CR: https://bugs.openjdk.java.net/browse/JDK-8152664
> > Webrev: http://cr.openjdk.java.net/~rbackman/8152664/
> >
> > Thanks
> > /R
/R
More information about the hotspot-dev
mailing list