From volker.simonis at gmail.com Mon Mar 25 12:46:12 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 25 Mar 2013 20:46:12 +0100 Subject: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev [updated] In-Reply-To: <50FD1529.7010303@oracle.com> References: <50D4F1FA.7090008@LGonQn.Org> <50D5017B.20305@oracle.com> <50D53CDD.9090109@LGonQn.Org> <50D5F5EA.2020902@oracle.com> <50D5F8BF.1030000@LGonQn.Org> <50F92A5A.4090000@oracle.com> <50F97A4D.50606@LGonQn.Org> <50F9C5FD.4050706@oracle.com> <50FD1529.7010303@oracle.com> Message-ID: Hi, I've just realized that something must have gone wrong during the downport of 8000780 to hsx24 (probably because of the change of the content of the f1 and f2 fields in the ConstantPoolCacheEntry between hsx24 and hsx25). Unfortunately now both, '_invokedynamic' as well as '_invokehandle' don't work in the CC-interpreter anymore. The attached patch (against hsx24) fixes the problem and lets the Zero-VM pass the java/lang/invoke JTreg tests again. These changes are needed for making JSR292 work in the Zero-port in jdk7u with hsx24. Can somebody please open a bug for this issue and review the changes. (I can also submit a full RFR with webrev once there's a bug ID). Thank you and best regards, Volker On Mon, Jan 21, 2013 at 11:15 AM, Alejandro E Murillo < alejandro.murillo at oracle.com> wrote: > > Thanks Vladimir, > I pushed this on Friday, will be in 7u/7u/hotspot next time we take a > snapshot of hs24 > cheers > Alejandro > > > On 1/18/2013 3:00 PM, Vladimir Kozlov wrote: > >> Looks good. >> >> Vladimir >> >> On 1/18/13 8:37 AM, Chris Phillips @ T O wrote: >> >>> Hi Alejandro, >>> >>> Have updated the webrev (just off by one line in 1 file) and built both >>> normal >>> hotspot and zero on x86_64 based on the hsx24 repo head: >>> http://integral-portal.lgonqn.**org/temp/ChrisPhi/hsx24b31-** >>> 8000780-zero_20130118_webrev/ >>> [Also now contains updated copyrights] >>> >>> Cheers! >>> Chris >>> >>> On 18/01/13 05:56 AM, Alejandro E Murillo wrote: >>> >>>> >>>> Hi Chris (Phillips) >>>> I just got a snapshot of hs24 and bumped the build number to b31, >>>> so we can resume pushing bug fixes to it. >>>> Unfortunately the patch in the webrev at [1] does not apply cleanly >>>> anymore, >>>> Can you guys reapply the changes to clean clone of [2] and send the >>>> new webrev? >>>> Then if the previous reviewers approve it, I will push that soon >>>> after so it makes >>>> it into next week snapshot. Apologies for the extra work >>>> >>>> [1]http://integral-portal.**lgonqn.org/temp/ChrisPhi/** >>>> jdk7u-dev-zero-hs24b29_**20121222/ >>>> >>>> [2] http://hg.openjdk.java.net/**hsx/hsx24/hotspot >>>> >>>> >>>> >>>> Thanks >>>> Alejandro >>>> >>>> >>>> On 1/2/2013 1:02 PM, Christian Thalinger wrote: >>>> >>>>> On Dec 22, 2012, at 10:15 AM, Chris Phillips @ T >>>>> O wrote: >>>>> >>>>> Hi Alejandro, >>>>>> Oops emails crossed in the net ... >>>>>> See my latest email , I had to regenerate the webrev and patch - >>>>>> This webrev s/b ok: >>>>>> >>>>>> Webrev: >>>>>> http://integral-portal.lgonqn.**org/temp/ChrisPhi/jdk7u-dev-** >>>>>> zero-hs24b29_20121222/ >>>>>> >>>>>> That looks good. -- Chris >>>>> >>>>> Chris >>>>>> >>>>>> On 22/12/12 01:03 PM, Alejandro E Murillo wrote: >>>>>> >>>>>>> Hi Chris, >>>>>>> In that case is not necessary. >>>>>>> I initially thought the webrev was against jdk7u/jdk7u-dev/hotspot >>>>>>> but looks like it is against hsx/hsx24/hotspot. >>>>>>> BTW, I went to check the webrev link and is unreachable, can you >>>>>>> check >>>>>>> that? >>>>>>> Thanks >>>>>>> Alejandro >>>>>>> >>>>>>> On 12/21/2012 9:53 PM, Chris Phillips @ T O wrote: >>>>>>> >>>>>>>> Hi Alejandro, >>>>>>>> >>>>>>>> The only change since I tested this afternoon is the change >>>>>>>> for the hotspot_version. I will re-run tests if you wish but it >>>>>>>> seems >>>>>>>> unnecessary. >>>>>>>> >>>>>>>> Cheers! >>>>>>>> Chris >>>>>>>> >>>>>>>> On 21/12/12 07:40 PM, Alejandro E Murillo wrote: >>>>>>>> >>>>>>>>> On 12/21/2012 4:34 PM, Chris Phillips @ T O wrote: >>>>>>>>> >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> {Not sure if this needs a new bug or not, it definitely needs a >>>>>>>>>> sponsor >>>>>>>>>> - Twisti ? } >>>>>>>>>> >>>>>>>>>> Attached is a backport (essentially resurrection of the Permgen >>>>>>>>>> code) >>>>>>>>>> of 8000780 now updated with Roman Kennke's comments. Checked and >>>>>>>>>> built >>>>>>>>>> against hsx24b28. (Current jdk7u-dev hs) >>>>>>>>>> >>>>>>>>>> Please review. >>>>>>>>>> >>>>>>>>>> Cheers! >>>>>>>>>> Chris >>>>>>>>>> PS >>>>>>>>>> Webrev is here: >>>>>>>>>> http://integral-portal.lgonqn.**org/temp/ChrisPhi/jdk7u-dev-** >>>>>>>>>> zero/hs24b28/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi >>>>>>>>> jdk7u-dev/hotspot corresponds to hs24-b27. >>>>>>>>> I just got the hs24 snapshot for b28 and bumped the number to b29, >>>>>>>>> Can you rework the patch/webrev against this repo: >>>>>>>>> >>>>>>>>> http://hg.openjdk.java.net/**hsx/hsx24/hotspot >>>>>>>>> >>>>>>>>> once it's reviewed I can push it >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> >>>>>>> >>>> >>>> >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20130325/30b2954a/attachment.html -------------- next part -------------- diff --git a/src/share/vm/interpreter/bytecodeInterpreter.cpp b/src/share/vm/interpreter/bytecodeInterpreter.cpp --- a/src/share/vm/interpreter/bytecodeInterpreter.cpp +++ b/src/share/vm/interpreter/bytecodeInterpreter.cpp @@ -2173,12 +2173,13 @@ // This kind of CP cache entry does not need to match the flags byte, because // there is a 1-1 relation between bytecode type and CP entry type. ConstantPoolCacheEntry* cache = cp->entry_at(index); - oop result = cache->f1_as_instance(); - if (result == NULL) { + if (cache->f1_as_instance() == NULL) { CALL_VM(InterpreterRuntime::resolve_ldc(THREAD, (Bytecodes::Code) opcode), handle_exception); - result = cache->f1_as_instance(); + // GC might move cache while returning from VM call. + cache = cp->entry_at(index); // reload } + oop result = cache->f1_as_instance(); VERIFY_OOP(result); SET_STACK_OBJECT(result, 0); @@ -2197,23 +2198,19 @@ u4 index = Bytes::get_native_u4(pc+1); ConstantPoolCacheEntry* cache = cp->secondary_entry_at(index); - oop result = cache->f1_as_instance(); // We are resolved if the f1 field contains a non-null object (CallSite, etc.) // This kind of CP cache entry does not need to match the flags byte, because // there is a 1-1 relation between bytecode type and CP entry type. assert(constantPoolCacheOopDesc::is_secondary_index(index), "incorrect format"); - if (! cache->is_resolved((Bytecodes::Code) opcode)) { + if (cache->is_f1_null()) { CALL_VM(InterpreterRuntime::resolve_invokedynamic(THREAD), handle_exception); - result = cache->f1_as_instance(); + // GC might move cache while returning from VM call. + cache = cp->secondary_entry_at(index); // reload } - VERIFY_OOP(result); - oop method_handle = java_lang_invoke_CallSite::target(result); - CHECK_NULL(method_handle); - - methodOop method = cache->f1_as_method(); + methodOop method = cache->f2_as_vfinal_method(); VERIFY_OOP(method); if (cache->has_appendix()) { @@ -2241,10 +2238,11 @@ if (! cache->is_resolved((Bytecodes::Code) opcode)) { CALL_VM(InterpreterRuntime::resolve_invokehandle(THREAD), handle_exception); - cache = cp->entry_at(index); + // GC might move cache while returning from VM call. + cache = cp->entry_at(index); // reload } - methodOop method = cache->f1_as_method(); + methodOop method = cache->f2_as_vfinal_method(); VERIFY_OOP(method); From ChrisPhi at LGonQn.Org Tue Mar 26 05:29:04 2013 From: ChrisPhi at LGonQn.Org (Chris Phillips @ T O) Date: Tue, 26 Mar 2013 08:29:04 -0400 Subject: RFR: 8000780 back ported Fix zero fail to build in JDK7u-dev [updated] In-Reply-To: References: <50D4F1FA.7090008@LGonQn.Org> <50D5017B.20305@oracle.com> <50D53CDD.9090109@LGonQn.Org> <50D5F5EA.2020902@oracle.com> <50D5F8BF.1030000@LGonQn.Org> <50F92A5A.4090000@oracle.com> <50F97A4D.50606@LGonQn.Org> <50F9C5FD.4050706@oracle.com> <50FD1529.7010303@oracle.com> Message-ID: <51519490.6070003@LGonQn.Org> Hi Volker Thanks! Good catch.. after applying this , I've gotten further in jsr292 for arm 32. Chris On 25/03/13 03:46 PM, Volker Simonis wrote: > Hi, > > I've just realized that something must have gone wrong during the > downport of 8000780 to hsx24 (probably because of the change of the > content of the f1 and f2 fields in the ConstantPoolCacheEntry between > hsx24 and hsx25). Unfortunately now both, '_invokedynamic' as well as > '_invokehandle' don't work in the CC-interpreter anymore. The attached > patch (against hsx24) fixes the problem and lets the Zero-VM pass the > java/lang/invoke JTreg tests again. > > These changes are needed for making JSR292 work in the Zero-port in > jdk7u with hsx24. > > Can somebody please open a bug for this issue and review the changes. > (I can also submit a full RFR with webrev once there's a bug ID). > > Thank you and best regards, > Volker > > > On Mon, Jan 21, 2013 at 11:15 AM, Alejandro E Murillo > > > wrote: > > > Thanks Vladimir, > I pushed this on Friday, will be in 7u/7u/hotspot next time we > take a snapshot of hs24 > cheers > Alejandro > > > On 1/18/2013 3:00 PM, Vladimir Kozlov wrote: > > Looks good. > > Vladimir > > On 1/18/13 8:37 AM, Chris Phillips @ T O wrote: > > Hi Alejandro, > > Have updated the webrev (just off by one line in 1 file) > and built both > normal > hotspot and zero on x86_64 based on the hsx24 repo head: > http://integral-portal.lgonqn.org/temp/ChrisPhi/hsx24b31-8000780-zero_20130118_webrev/ > [Also now contains updated copyrights] > > Cheers! > Chris > > On 18/01/13 05:56 AM, Alejandro E Murillo wrote: > > > Hi Chris (Phillips) > I just got a snapshot of hs24 and bumped the build > number to b31, > so we can resume pushing bug fixes to it. > Unfortunately the patch in the webrev at [1] does not > apply cleanly > anymore, > Can you guys reapply the changes to clean clone of [2] > and send the > new webrev? > Then if the previous reviewers approve it, I will > push that soon > after so it makes > it into next week snapshot. Apologies for the extra work > > [1]http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b29_20121222/ > > > [2] http://hg.openjdk.java.net/hsx/hsx24/hotspot > > > > Thanks > Alejandro > > > On 1/2/2013 1:02 PM, Christian Thalinger wrote: > > On Dec 22, 2012, at 10:15 AM, Chris Phillips @ T > O > wrote: > > Hi Alejandro, > Oops emails crossed in the net ... > See my latest email , I had to regenerate the > webrev and patch - > This webrev s/b ok: > > Webrev: > http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero-hs24b29_20121222/ > > > That looks good. -- Chris > > Chris > > On 22/12/12 01:03 PM, Alejandro E Murillo wrote: > > Hi Chris, > In that case is not necessary. > I initially thought the webrev was against > jdk7u/jdk7u-dev/hotspot > but looks like it is against > hsx/hsx24/hotspot. > BTW, I went to check the webrev link and > is unreachable, can you check > that? > Thanks > Alejandro > > On 12/21/2012 9:53 PM, Chris Phillips @ T > O wrote: > > Hi Alejandro, > > The only change since I tested this > afternoon is the change > for the hotspot_version. I will re-run > tests if you wish but it seems > unnecessary. > > Cheers! > Chris > > On 21/12/12 07:40 PM, Alejandro E > Murillo wrote: > > On 12/21/2012 4:34 PM, Chris > Phillips @ T O wrote: > > Hi > > {Not sure if this needs a new > bug or not, it definitely needs a > sponsor > - Twisti ? } > > Attached is a backport > (essentially resurrection of > the Permgen > code) > of 8000780 now updated with > Roman Kennke's comments. > Checked and > built > against hsx24b28. (Current > jdk7u-dev hs) > > Please review. > > Cheers! > Chris > PS > Webrev is here: > http://integral-portal.lgonqn.org/temp/ChrisPhi/jdk7u-dev-zero/hs24b28/ > > > > Hi > jdk7u-dev/hotspot corresponds to > hs24-b27. > I just got the hs24 snapshot for > b28 and bumped the number to b29, > Can you rework the patch/webrev > against this repo: > > http://hg.openjdk.java.net/hsx/hsx24/hotspot > > once it's reviewed I can push it > > Thanks > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20130326/85cc91d6/attachment-0001.html From gnu.andrew at redhat.com Tue Mar 26 08:00:22 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 26 Mar 2013 11:00:22 -0400 (EDT) Subject: compile error on mac ppc box In-Reply-To: <345D74A2-6857-4E53-8807-E69DA773049A@mac.com> Message-ID: <1011519950.23981084.1364310022789.JavaMail.root@redhat.com> [Forwarding to zero-dev] ----- Original Message ----- > I decided to try to build the latest java 7 code on a dual G4 PPC > power macintosh and ran into the following compile error: > > /Users/tpiselli/development/projects/openjdk-java7-ppc/bsd-port/ > hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp: In static member > function 'static void CppInterpreter::process_method_handle(oopDesc*, > Thread*)': > /Users/tpiselli/development/projects/openjdk-java7-ppc/bsd-port/ > hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp:817: error: > 'get_ek_bound_mh_info' is not a member of 'MethodHandles' > /Users/tpiselli/development/projects/openjdk-java7-ppc/bsd-port/ > hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp:965: error: > 'get_ek_adapter_opt_swap_rot_info' is not a member of 'MethodHandles' > make[6]: *** [cppInterpreter_zero.o] Error 1 > make[6]: *** Waiting for unfinished jobs.... > make[5]: *** [the_vm] Error 2 > make[4]: *** [productzero] Error 2 > make[3]: *** [generic_buildzero] Error 2 > make[2]: *** [productzero] Error 2 > make[1]: *** [hotspot-build] Error 2 > make: *** [build_product_image] Error 2 > > real 61m39.402s > user 59m12.184s > sys 3m9.926s > > > I was wondering if this was a PPC only issue or a generic error. > Thanks, > Tony > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From ChrisPhi at LGonQn.Org Tue Mar 26 08:40:02 2013 From: ChrisPhi at LGonQn.Org (Chris Phillips @ T O) Date: Tue, 26 Mar 2013 11:40:02 -0400 Subject: compile error on mac ppc box In-Reply-To: <1011519950.23981084.1364310022789.JavaMail.root@redhat.com> References: <1011519950.23981084.1364310022789.JavaMail.root@redhat.com> Message-ID: <5151C152.5080604@LGonQn.Org> Hi On 26/03/13 11:00 AM, Andrew Hughes wrote: > 'get_ek_adapter_opt_swap_rot_info' is not a member of 'MethodHandles' This looks like old code that shouldn't be there ... what version of (and what repo) is this built from (That code was for the pre-Richochet version)? (If its an old repo you may need TARGET_ARCH_NYI_693986 set ). Chris -- -- -- Woda: "Java: write once, debug anywhere" Hong Zhang http://thehenrys.ca | Chris Phillips - Resident cat slave and dubious character | | mailto:NorthernL00n at LGonQn.Org (416)483-3768 | | http://LGonQn.Org/www/Chris.Phillips cell: (416)505-3610 | "EPIC stands for Expects Perfectly Intuitive Compilers" P. Bannon http://www.hazmatmodine.com NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. "blah blah blah - Ginger!" -- From tpisellijr at mac.com Tue Mar 26 17:01:27 2013 From: tpisellijr at mac.com (Tony Piselli) Date: Wed, 27 Mar 2013 00:01:27 +0000 (GMT) Subject: compile error on mac ppc box In-Reply-To: <5151C152.5080604@LGonQn.Org> Message-ID: <303b476f-a6e9-4b8f-930d-dd820c5f88e5@me.com> Chris, Sorry for my ignorance with this as it's the first time I've tried to do an OpenJDK build. I basically followed the directions from the following Wiki page: https://wikis.oracle.com/display/OpenJDK/Darwin9Build which calls for the following to pull down the code: hg clone http://hg.openjdk.java.net/bsd-port/bsd-port I hope this is what you were looking for. Please let me knowif you need any more information. Thanks, Tony On Mar 26, 2013, at 11:40 AM, "Chris Phillips @ T O" wrote: Hi On 26/03/13 11:00 AM, Andrew Hughes wrote: > 'get_ek_adapter_opt_swap_rot_info' is not a member of 'MethodHandles' This looks like old code that shouldn't be there ... what version of (and what repo) is this built from (That code was for the pre-Richochet version)? (If its an old repo you may need TARGET_ARCH_NYI_693986 set ). Chris -- -- -- Woda: "Java: write once, debug anywhere" Hong Zhang http://thehenrys.ca | Chris Phillips - Resident cat slave and dubious character | | mailto:NorthernL00n at LGonQn.Org (416)483-3768 | | http://LGonQn.Org/www/Chris.Phillips cell: (416)505-3610 | "EPIC stands for Expects Perfectly Intuitive Compilers" P. Bannon http://www.hazmatmodine.com NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. "blah blah blah - Ginger!" -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20130327/f6c7a5de/attachment.html