From sgehwolf at redhat.com Mon Nov 2 09:27:15 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 Nov 2015 10:27:15 +0100 Subject: Fwd: RFR (S) 8140650: (preliminary) Method::is_accessor should cover getters and setters for all types In-Reply-To: <56337D06.8000905@oracle.com> References: <5630EA62.6070004@oracle.com> <56337D06.8000905@oracle.com> Message-ID: <1446456435.3623.11.camel@redhat.com> Hi Aleksey, Thanks for bringing this to our attention! On Fri, 2015-10-30 at 17:21 +0300, Aleksey Shipilev wrote: > Hi, > > There is a suggested change that affects Zero: UseFastAccessorMethods is > used only in Zero after JDK-8003426. We would like to make the > is_accessor matcher a proper one, which raises some questions below: > > -------- Forwarded Message -------- > Subject: RFR (S) 8140650: (preliminary) Method::is_accessor should cover > getters and setters for all types > Date: Wed, 28 Oct 2015 18:31:46 +0300 > From: Aleksey Shipilev > To: hotspot-runtime-dev > > Hi, > > I have been reading the compiler code recently to check if > setters/getters are actually treated specially in inline policy. They > do, and inliner relies on Method::is_accessor to detect them. > > But then I realized that Method::is_accessor implementation only accepts > the specific shapes of getters, and completely ignores setters (contrary > to what is spelled in the "doc" comment!): > ? https://bugs.openjdk.java.net/browse/JDK-8140650 > > This makes compilers to ignore many trivial methods that we might > otherwise inline when all other inline hints have failed. With that in > mind, I did a proof-of-concept change, which passes JPRT and a new > compiler-specific regression test: > ? http://cr.openjdk.java.net/~shade/8140650/webrev.00/ > > I'll run more testing, after we figure the fate for interpreter.cpp > change. It is prompted by Zero's fast accessor implementation that only > accepts the specific getter shape. Now, we can go three routes: > ?a) Ignore the issue, and keep Method::is_simple_accessor; > ?b) Fix Zero's fast accessor to accept all the shapes. > ?c) Remove fast accessors from Zero (I see UseFastAccessorMethods is > marked as obsolete), and thus probably remove the notion of "accessor" > from interpreter completely (?); > > Current patch does (a), and I'm leaning to keep it that way, letting > Zero to handle more in future. If we care more about Zero, we might go > for (b) -- although it seems to deserve a separate follow-up RFE. And if > we don't, we can go for (c). > > Thoughts? It should be fine to go with (a) and also file a follow-up RFE for Zero in order to implement (b). I can take this task on if you wish. Please let me know about the RFE bug you file. Thanks, Severin From opotapenko at gmail.com Sun Nov 29 21:08:59 2015 From: opotapenko at gmail.com (Alex Potapenko) Date: Sun, 29 Nov 2015 23:08:59 +0200 Subject: [Zero-dev] Cross-compiled OpenJDK 8.0_72-b05 on uClibc-ng-1.0.9 platform: Segfault when starting bubbleupnpserver Message-ID: Hi, I cross-compiled OpenJDK 8u72b05 for ARMv7 platform, and it works fine with trivial examples (like 'Hello world'). However, trying to run bubbleupnp server leads to "fatal error: caught unhandled signal 11". The same error happened with older update I tried (8u60-b24). I've attached the crash log, wanted to attach core dump too, but it seams it isn't actually being created, even after issuing `ulimit -c unlimited` (can't find "core" or "core.${pid}" file anywhere on the router). I tried tweaking -Xms and -Xmx settings, but it doesn't seam to help. Any help is appreciated. Thanks in advance, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid29148.log Type: application/octet-stream Size: 54433 bytes Desc: not available URL: