July 2015 - aarch64-port-dev

Support large codecache for JDK8
by Andrew Dinn 26 Nov '15

26 Nov '15

Attached for review is a patch which adds large codecache support to jdk8 (jdk7 version will be next). It passes basic smoke tests (java hello, javac Hello.java, netbeans build and run simple project). Ok to push? regards, Andrew Dinn -----------

3 7

Re: [aarch64-port-dev ] RFR (S) 8131682: C1 should use multibyte nops everywhere
by Aleksey Shipilev 10 Aug '15

10 Aug '15

(explicitly cc'ing AArch64 and PPC folks) Thanks, -Aleksey On 22.07.2015 11:10, Aleksey Shipilev wrote: > Thanks for review, Dean! > > I'd like to hear the opinions of AArch64 and Power folks, since we > contaminate their assemblers a bit to gain access to x86 fat nops. > > -Aleksey > > On 21.07.2015 23:28, Dean Long wrote: >> This version looks good. >> >> dl >> >> On 7/20/2015 7:51 AM, Aleksey Shipilev wrote: >>> Hi Dean, >>> >>> Thanks for taking a look! >>> >>> Silly me, I should have left the call patching cases intact, because >>> you're right, we should be able to patch the nops partially while still >>> producing the correct instruction stream. Therefore, I reverted the >>> cases where we do nop-ing for *instruction* patching, and added the >>> comment there. >>> >>> Other places seem to use the nop sequences to provide the alignment, not >>> for the general patching. Especially interesting for us is the case of >>> aligning the patcheable immediate in the existing call. C2 does the nops >>> in these cases. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~shade/8131682/webrev.01/ >>> >>> Testing: >>> * JPRT -testset hotspot on open platforms; >>> * Targeted benchmarks, plus eyeballing the assembly; >>> >>> Thanks, >>> -Aleksey >>> >>> On 18.07.2015 10:51, Dean Long wrote: >>>> I think we should distinguish the different uses and treat them >>>> accordingly: >>>> >>>> 1) padding nops for patching, executed >>>> >>>> We need to be careful about inserting a fat nop here, if later patching >>>> overwrites only part of the fat nop, resulting in an illegal intruction. >>>> >>>> 2) padding nops for patching, never executed >>>> >>>> It should be safe insert a fat nop here, but there's no point if the >>>> nops are not reachable and never executed. >>>> >>>> >>>> 3) alignment nops, never patched, executed >>>> >>>> Fat nops are fine, but on some CPUs branching may be even better, so I >>>> suggest using align() for this, and letting align() decide what to >>>> generate. The change in check_icache() could use a version of align >>>> that takes the target offset as an argument: >>>> >>>> 348 align(CodeEntryAlignment,__ offset() + ic_cmp_size); >>>> >>>> 4) alignment nops, never patched, never executed >>>> >>>> Doesn't matter what we emit here, but we might as well make it >>>> understandable by humans using a debugger. >>>> >>>> >>>> I believe the patching nops in c1_CodeStubs_x86.cpp and >>>> c1_LIRAssembler.cpp are patched concurrently while the code is running, >>>> not at a safepoint, so it's not clear to me if it's safe to use fat nops >>>> on x86. I would consider those changes unsafe on x86 without further >>>> analysis of what happens during patching. >>>> >>>> dl >>>> >>>> On 7/17/2015 6:29 AM, Aleksey Shipilev wrote: >>>>> Hi there, >>>>> >>>>> C1 is not very good at inlining and intrisifying methods, and hence the >>>>> call performance is important there. One nit that we can see in the >>>>> generated code on x86 is that C1 uses the single-byte nops, even for >>>>> long nop strides. >>>>> >>>>> This improvement fixes that: >>>>> https://bugs.openjdk.java.net/browse/JDK-8131682 >>>>> http://cr.openjdk.java.net/~shade/8131682/webrev.00/ >>>>> >>>>> Testing: >>>>> - JPRT -testset hotspot on open platforms >>>>> - eyeballing the generated assembly with -XX:TieredStopAtLevel=1 >>>>> >>>>> (I understand the symmetric change is going to be needed in closed >>>>> parts, but let's polish the open part first). >>>>> >>>>> Thanks, >>>>> -Aleksey >>>>> >>> >> > >

6 10

Re: [aarch64-port-dev ] [9] RFR(S): 8130309: need to bailout cleanly if CompiledStaticCall::emit_to_interp_stub fails when codecache is out of space
by Tobias Hartmann 31 Jul '15

31 Jul '15

Hi, after running some more tests, I noticed that my fix is incomplete. The problem is that checking for a failed expansion in 'Compile::fill_buffer' may be too late in case we emit additional instructions immediately after we failed to create the stub. For example, 'CallStaticJavaHandle' emits code to restore the stack pointer after 'Java_Static_Call' on Sparc (see sparc.ad): 9991 ins_encode(preserve_SP, Java_Static_Call(meth), restore_SP, call_epilog); If we don't bail out immediately after allocation of the stub failed, we crash in 'restore_SP' while trying to emit code into the now freed code blob. This problem exists on all platforms. Although we do not always emit code (for example on aarch64, -XX:VerifyStackAtCalls is currently unimplemented), I added checks for robustness / completeness. I also added checks to the corresponding C1 code. Here is the new webrev: http://cr.openjdk.java.net/~thartmann/8130309/webrev.01/ Thanks, Tobias On 21.07.2015 15:40, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > https://bugs.openjdk.java.net/browse/JDK-8130309 > http://cr.openjdk.java.net/~thartmann/8130309/webrev.00/ > > Problem: > While C2 is emitting code, an assert is hit because the emitted code size does not correspond to the size of the instruction. The problem is that the code cache is full and therefore the creation of a to-interpreter stub failed. Instead of bailing out we continue and hit the assert. > > More precisely, we emit code for a CallStaticJavaDirectNode on aarch64 and emit two stubs (see 'aarch64_enc_java_static_call' in aarch64.ad): > - MacroAssembler::emit_trampoline_stub() -> requires 64 bytes > - CompiledStaticCall::emit_to_interp_stub() -> requires 56 bytes > However, we only have 112 bytes of free space in the stub section of the code buffer and need to expand it. Since the code cache is full, the expansion fails and the corresponding code blob is freed. In CodeBuffer::free_blob() -> CodeBuffer::set_blob() we set addresses to 'badAddress' and therefore hit the assert. > > Solution: > Even if we have enough space in the instruction section, we should check for a failed expansion of the stub section and bail out immediately. I added the corresponding check and also removed an unnecessary call to 'start_a_stub' after we already failed. > > Testing: > - Failing test > - JPRT > > Thanks, > Tobias >

4 16

hg: aarch64-port/jdk8/nashorn: Remove jcheck
by adinn＠redhat.com 31 Jul '15

31 Jul '15

Changeset: db6228024490 Author: adinn Date: 2015-07-31 16:29 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/nashorn/rev/db6228024490 Remove jcheck - .jcheck/conf

1 0

hg: aarch64-port/jdk8/langtools: Remove jcheck
by adinn＠redhat.com 31 Jul '15

31 Jul '15

Changeset: 40a63630eb87 Author: adinn Date: 2015-07-31 16:29 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/langtools/rev/40a63630eb87 Remove jcheck - .jcheck/conf

1 0

hg: aarch64-port/jdk8/jdk: Remove jcheck
by adinn＠redhat.com 31 Jul '15

31 Jul '15

Changeset: 0b8920048898 Author: adinn Date: 2015-07-31 16:29 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/jdk/rev/0b8920048898 Remove jcheck - .jcheck/conf

1 0

hg: aarch64-port/jdk8/jaxp: Remove jcheck
by adinn＠redhat.com 31 Jul '15

31 Jul '15

Changeset: 57a7047f7875 Author: adinn Date: 2015-07-31 16:29 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/jaxp/rev/57a7047f7875 Remove jcheck - .jcheck/conf

1 0

hg: aarch64-port/jdk8/jaxws: Remove jcheck
by adinn＠redhat.com 31 Jul '15

31 Jul '15

Changeset: afbe78dc93b2 Author: adinn Date: 2015-07-31 16:29 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/jaxws/rev/afbe78dc93b2 Remove jcheck - .jcheck/conf

1 0

hg: aarch64-port/jdk8/hotspot: Remove jcheck
by adinn＠redhat.com 31 Jul '15

31 Jul '15

Changeset: 4c3f7e682e48 Author: adinn Date: 2015-07-31 16:29 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/4c3f7e682e48 Remove jcheck - .jcheck/conf

1 0

hg: aarch64-port/jdk8/corba: Remove jcheck
by adinn＠redhat.com 31 Jul '15

31 Jul '15

Changeset: a6046ed1e2d5 Author: adinn Date: 2015-07-31 16:29 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/corba/rev/a6046ed1e2d5 Remove jcheck - .jcheck/conf

1 0