RFR (XL): 8152664 - Support non-continuous CodeBlobs in HotSpot

Thu Apr 7 15:50:24 UTC 2016

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?

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?

- 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?

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