March 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

Proposed patch for C2 volatile generation (resent)
by Andrew Dinn 17 Apr '15

17 Apr '15

Resending this because I think the original had a problem: Attached, for review, is a patch which -- I believe -- fixes generation of code for volatile reads and writes while at the same time retaining the existing code generation strategy for all other barrier output. I say 'I believe' because there is one corner case which I think might break things but I am not really sure whether this corner case can actually arise. Details are provided as comments in the code but I'll provide a summary here too. The status quo (volatile reads) ------------------------------- The current volatile generation code successfully translates a LoadX(mo_acquire) MemBarAcquire sequence either to ldr<x> dmb ishld or to ldar<x> My reading of the C2 shared code indicates that both these translations, in particular the second one, are always valid. We will only ever see the indicated node sequence as a result of a volatile read. There is never a case where a MemBarAcquire can directly follow an (acquire) ordered LoadX without it being generated from a volatile read. That's true even in the presence of optimizations. So, the current code essentially has two sets of rules selected according to whether UseBarriersForVolatile == true/false. The first set (UseBarriersForVolatile == true) translates all LoadX operations to a normal load and all MemBarAcquire operations to dmb. The second set (UseBarriersForVolatile == false) translates LoadX(mo_acquire) operations to an acquiring load when they are followed by a MemBarAcquire and elides generation of the dmb. A LoadX(mo_unorderd) is translated to a normal load . Actually, it goes further than that because the second set of rules also copes with the following sequence (DecodeNarrowPtr (LoadX(mo_acquire)) MemBarAcquire which is generated in the case where a compressed oop is loaded. n.b. I'm glossing over some of the details here -- there is a specific order of input/output linkage required for these patterns (simlarly in later cases but the patch is clear about what is needed). n.b.b. for reasons of consistency with other cases I have renamed the predicate used for the 2nd set of rules to unnecessary_membar_acquire. The status quo (volatile writes) -------------------------------- Currently, handling of volatile writes is not so healthy. A volatile write is /normally/ translated to a node sequence like the following MemBarRelease StoreX(mo_release) MemBarVolatile This is the node graph which results both when the store occurs because of a direct volatile write and when it is the result of an inlined unsafe access to a volatile field. The current rules translate that sequence to dmb ish str<x> dmb ish i.e. they add a redundant dmb after the store. This is achieved by translating all MemBarRelease nodes to a dmb ish, all MemBarVolatile nodes to a dmb ish and all StoreX nodes to a normal (non-releasing) store. Clearly, for a volatile store the trailing dmb is redundant. n.b. I'll get back to that /normally/ later once we have dealt with the basic case -- it's a wrinkle but not an intractable one. The reason for this appears to be a worry that volatile store are not the only source of MemBarRelease and MemBarVolatile nodes i.e. that this sequence may not be guaranteed to be present only because of a volatile store. For example, LibraryKit::inline_unsafe_access plants MemBarRelease and MemBarVolatile nodes into the node graph as do some other routines (e.g. exit node processing in parse1.cpp). Another potential worry is that the compiler might do optimizations which involve moving or eliding MemBar nodes. The proposed fix (pt 1) ----------------------- Even if the above concern is justified when the volatile write node pattern is seen there can be no harm in translating the first two nodes into a stlr<x>. If the above translation is valid then the following will be semantically equivalent and hence also valid: stlr<x> dmb ish So, just as with the volatile read case, it is quite straightforward to make the current rules apply only when UseBarriersForVolatile == false and to provide alternative rules enabled when UseBarriersForVolatile == false which, when they detect this pattern of nodes, plant an stlr<x> and elide the dmb. Predicate unnecessary_membar_release provided in the patch implements supports this transformation when UseBarriersForVolatile == false. The proposed fix (pt 1) ----------------------- This still leaves the tricky question as to whether and when it is possible to elide the trailing dmb. n.b. notice that whatever the setting for UseBarriersForVolatile we would always like to do this elision (assuming it is legitimate). We really only want stlr<x> or dmb ish stl<x> I believe it is always possible to elide the dmb when the above pattern is seen apart from one corner case explained below. From my reading of the C2 code we will never see this pattern in any of the other cases where MemBar nodes are introduced/optimized. The predicate unnecessary_membar_volatile provided in the patch is used to elide dmbs arising from MemBarVolatile nodes /irrespective/ of the setting of UseBarriersForVolatile. The corner case --------------- The corner case occurs in method LibraryKit::inline_unsafe_fence when inlining a call to Unsafe.fullFence. The inline subgraph for this call is a bare MemBarVolatile. This in itself is not a challenge -- a MemBarVolatile does not constitute the pattern we want to optimize. Nor indeed is it ever going to be able to be appended to a pair of MemBarRelease LoadX(mo_release) nodes to complete the target pattern since w enever see a bare pair of nodes in that form. However, it might cause a problem if the inlined Unsafe.fullFence directly follows a volatile store (whether directly planted or inlined). Imagine we have a method which has a volatile field write followed by a call to Unsafe.fullFence. We might expect to see an inlined node sequence generated like this: MemBarRelease StoreX(mo_release) MemBarVolatile MemBarVolatile The compiler () will optimize this to MemBarRelease StoreX(mo_release) MemBarVolatile If we omit the trailing dmb we still retain the correct semantics for the volatile store -- it cannto be seen before any prior stores. However, with no trailing dmb we do not get the behaviour required by the Unsafe.fullFence; we cannot be sure that a subsequent store will not visible before the releasing store. The wrinkle ----------- The volatile write pattern has a minor variant which sometimes arises with an inlined unsafe putX when the value being written is an object. If the heap_base input to the store is potentially NULL (it's type is lower in the type lattice that TypePtr::NULL_PTR) then the store normally bracketed by the MemBarRelease and MemBarVolatile is replaced by an if-then-else node sequence including a StoreP<mo_release> in each branch albeit with (slightly) differing inputs. The current predicates do not detect this pattern which means we still generate correct code but pay the cost of two dmbs when this case arises. We can make the predicate smarter if we want (if it really hurts performance) but I have simply ignored this for now. The (in)significance of the corner case? ---------------------------------------- I am not sure whether the corner case inlining pattern will ever actually happen. Firstly, I don't know if a bare inline of just the MemBarVolatile will ever occur for a fullFence without also inlining other code from the Unsafe call (i.e. a checkAccess). Maybe that code could also be optimized away? I am not sure. Secondly, even if it is possible for this to happen will it ever actually happen? Is there any code which relies on using an unsafe volatile put followed by an call to Unsafe.fullFence? I could find no actual uses of Unsafe.fullFence anywhere in the hotspot or jdk trees. Of course, I suppose someone could add a call to Unsafe.fullFence into some of their own code and then build that code into their own custom java.base image to provide it with access to Unsafe (or even make Unsafe visible again) and then run up against this problem. Do we have to worry about that? Testing ------- I have not been able to construct a test to check this specific corner case. If anyone else can provide pointers as to how to do that I'd be very grateful. I have run basic tests on the patched code and also run up netbeans successfully. I intend next to try it with the jcstress suite. Your input welcome :-) ---------------------- Meanwhile, I would be interested in all feedback on the proposed patch. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland)

3 16

RFR: 8075860: aarch64: jdk9/dev fails to build
by Edward Nevill 02 Apr '15

02 Apr '15

Hi, The following webrev http://cr.openjdk.java.net/~enevill/8075860/webrev.00/ fixes issue https://bugs.openjdk.java.net/browse/JDK-8075860 aarch64 fails to build from jdk9/dev. It fails with an undefined symbol 'os::Linux::ucontext_set_pc' This was introduced in changset 7995:3eb61269f421 The change was not reflected in the aarch64 specific code. Could someone please review this change and if approved, push. Thanks, Ed.

3 3

Re: [aarch64-port-dev ] Fix for jdk9/dev build for aarch64
by Edward Nevill 25 Mar '15

25 Mar '15

Hi Andy, Thanks for this. Now that the aarch64 port has been merged to jdk9/dev all changes must be accompanied by an issue report in the JDK bug system at http://bugs.openjdk.java.net I have already created a report for this issue along with a patch at https://bugs.openjdk.java.net/browse/JDK-8075860 All the best, Ed. On Tue, 2015-03-24 at 22:46 -0500, Andrew Johnson wrote: > The following patch allows the build of openjdk jdk9/dev to complete > successfully: > > diff -r f68d656d1f5e src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp > --- a/src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp Mon Mar 23 > 11:44:41 2015 -0700 > +++ b/src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp Tue Mar 24 > 20:40:29 2015 -0700 > @@ -116,6 +116,14 @@ > #endif > } > > +void os::Linux::ucontext_set_pc(ucontext_t * uc, address pc) { > +#ifdef BUILTIN_SIM > + uc->uc_mcontext.gregs[REG_PC] = (intptr_t)pc; > +#else > + uc->uc_mcontext.pc = (intptr_t)pc; > +#endif > +} > + > intptr_t* os::Linux::ucontext_get_sp(ucontext_t * uc) { > #ifdef BUILTIN_SIM > return (intptr_t*)uc->uc_mcontext.gregs[REG_SP]; > >

3 4

RFR: 8075930: AARCH64: Use FP Register in C2
by Edward Nevill 25 Mar '15

25 Mar '15

Hi, The aarch64 C2 compiler makes no use of the FP register even though this register is saved on entry and restored on exit and is therefore always available for allocation. Recent testing on some micro benchmarks shows that this can have an adverse effect, both in terms of stack usage, and performance. The following webrev allows C2 to use the FP register. http://cr.openjdk.java.net/~enevill/8075930/webrev/ I have run JTreg hotspot and langtools before and after this change with the following results:- Before:- hotspot: passed: 539, failed: 186, error: 87 langtools: passed: 3193, error: 33 After:- hotspot: passed: 540, failed: 186: error: 86 langtools: passed: 3192, error: 34 Please review this change and if OK, push. Thanks, Ed.

1 0

[9] RFR(S): 8074869: C2 code generator can replace -0.0f with +0.0f on Linux
by Zoltán Majó 16 Mar '15

16 Mar '15

Hi, please review the following small patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8074869 Problem: On Linux, the C2 code generator can replace the value -0.0f with +0.0f (and also the value -0.0d with +0.0d). The reason is that in some *.ad files both the value -0.0f and +0.0f is treated as being +0.0f and can therefore be replaced with an immediate +0.0f embedded into an instruction. For example, in the sparc.ad file, the 'fpclass' function is used to decide if a float node's content is +0.0: predicate((n->getf() == 0) && (fpclass(n->getf()) == FP_PZERO)); On Solaris, 'fpclass' returns FP_PZERO if the parameter is +0.0f and FP_NZERO if the parameter is -0.0f. As a result, +0.0f and -0.0f are distinguished by the compiler. On Linux, however, 'fpclass' is not available and therefore 'fpclassify' is used. 'fpclassify' does not distinguish between ±0.0f, it returns FP_ZERO for both +0.0f and -0.0f. Solution: Instead of 'fpclass', use cast float->int and double->long to check if value is +0.0f and +0.0d, respectively. This logic is already use on some architectures, for example on x86_32 and on x86_64. As 'fpclass' is not used any more, remove its declarations from globalDefintions_*. The include of ieeefp.h must be kept as we rely on some other functionality from this header on solaris. Webrev: http://cr.openjdk.java.net/~zmajo/8074869/webrev.00/ Testing: - JPRT testing on all supported platforms (does *not* include aarch64 and ppc64) - manual testing on aarch64: All DaCapo benchmarks with the small input size. I used the default JVM flags and tested the VM w/ and w/o the fix. All benchmarks pass except eclipse. For eclipse, the same Java-level failure appears both w/ and w/o the fix, so I think the problem with eclipse is not due to these changes. I also tested with the "-Xcomp -XX:-TieredCompilation -server" flags. Eclipse fails in this case as well. Additionally, tradebeans and tradesoap fail with a Java-level failure. As the failure happens also with both builds (w/ and w/o the fix), I don't think the problem is caused by these changes either. - no testing on ppc64: I don't have access to a ppc64 machine. Could somebody with access to a ppc64 machine please build and test the VM with this patch (and then maybe confirm that it works)? Thank you and best regards, Zoltan

3 6

Re: [aarch64-port-dev ] [9] RFR(S): 8074869: C2 code generator can replace -0.0f with +0.0f on Linux
by Vladimir Kozlov 12 Mar '15

12 Mar '15

On 3/12/15 8:28 AM, Vitaly Davidovich wrote: > Hi Zoltan, > > Is -0.0{f,d} not replaced with an immediate because the immediate then increases instruction size? Just curious ... I did not get the question. If you look on usage of immD0/immF0 it is replaced with 0 (or G0) value which we can easy embed into instructions. It is not easy to use 0x80000000 such way. It will need to be loaded into register in separate instruction. But I think -0. is rare so it should not be a problem. Regards, Vladimir > > Thanks > > On Thu, Mar 12, 2015 at 8:43 AM, Zoltán Majó <zoltan.majo(a)oracle.com <mailto:zoltan.majo@oracle.com>> wrote: > > Hi, > > > please review the following small patch. > > Bug: https://bugs.openjdk.java.net/__browse/JDK-8074869 <https://bugs.openjdk.java.net/browse/JDK-8074869> > > > Problem: On Linux, the C2 code generator can replace the value -0.0f with +0.0f (and also the value -0.0d with > +0.0d). The reason is that in some *.ad files both the value -0.0f and +0.0f is treated as being +0.0f and can > therefore be replaced with an immediate +0.0f embedded into an instruction. > > For example, in the sparc.ad <http://sparc.ad> file, the 'fpclass' function is used to decide if a float node's > content is +0.0: > > predicate((n->getf() == 0) && (fpclass(n->getf()) == FP_PZERO)); > > On Solaris, 'fpclass' returns FP_PZERO if the parameter is +0.0f and FP_NZERO if the parameter is -0.0f. As a > result, +0.0f and -0.0f are distinguished by the compiler. > > On Linux, however, 'fpclass' is not available and therefore 'fpclassify' is used. 'fpclassify' does not distinguish > between ±0.0f, it returns FP_ZERO for both +0.0f and -0.0f. > > > Solution: Instead of 'fpclass', use cast float->int and double->long to check if value is +0.0f and +0.0d, > respectively. This logic is already use on some architectures, for example on x86_32 and on x86_64. > > As 'fpclass' is not used any more, remove its declarations from globalDefintions_*. The include of ieeefp.h must be > kept as we rely on some other functionality from this header on solaris. > > > Webrev: http://cr.openjdk.java.net/~__zmajo/8074869/webrev.00/ <http://cr.openjdk.java.net/~zmajo/8074869/webrev.00/> > > > Testing: > - JPRT testing on all supported platforms (does *not* include aarch64 and ppc64) > > - manual testing on aarch64: > > All DaCapo benchmarks with the small input size. I used the default JVM flags and tested the VM w/ and w/o the fix. > All benchmarks pass except eclipse. For eclipse, the same Java-level failure appears both w/ and w/o the fix, so I > think the problem with eclipse is not due to these changes. > > I also tested with the "-Xcomp -XX:-TieredCompilation -server" flags. Eclipse fails in this case as well. > Additionally, tradebeans and tradesoap fail with a Java-level failure. As the failure happens also with both builds > (w/ and w/o the fix), I don't think the problem is caused by these changes either. > > - no testing on ppc64: I don't have access to a ppc64 machine. Could somebody with access to a ppc64 machine please > build and test the VM with this patch (and then maybe confirm that it works)? > > > Thank you and best regards, > > > Zoltan > >

1 0

8069539: RSA acceleration
by Andrew Haley 12 Mar '15

12 Mar '15

This looks fairly straightforward to port to AArch64. http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-March/0173… Andrew.

1 0

hg: aarch64-port/jdk8/hotspot: 8071947: AARCH64: frame::safe_for_sender() computes incorrect sender_sp value for interpreted frames
by adinn＠redhat.com 05 Mar '15

05 Mar '15

Changeset: a747c1771e54 Author: aph Date: 2015-02-06 10:36 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/a747c1771e54 8071947: AARCH64: frame::safe_for_sender() computes incorrect sender_sp value for interpreted frames Summary: Apply the fix for 8068655 to the AArch64 sources. Reviewed-by: kvn ! src/cpu/aarch64/vm/frame_aarch64.cpp

1 0

hg: aarch64-port/jdk8/hotspot: 2 new changesets
by aph＠redhat.com 05 Mar '15

05 Mar '15

Changeset: 719def58024b Author: aph Date: 2015-03-05 09:34 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/719def58024b Delete jdk8u40-b25 tag. ! .hgtags Changeset: acb98552116e Author: aph Date: 2015-03-05 09:38 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/acb98552116e Added tag jdk8u40-b25 for changeset 719def58024b ! .hgtags

1 0