/hg/release/icedtea6-1.8: Fix for fast bytecode in cpp interpreter

[Andrew John Hughes]

On 31 March 2010 17:55, Xerxes Ranby <xerxes at zafena.se> wrote:
> Andrew John Hughes wrote:
>>
>> On 31 March 2010 01:09, Andrew John Hughes <ahughes at redhat.com> wrote:
>>
>>>
>>> On 31 March 2010 01:05,  <doko at icedtea.classpath.org> wrote:
>>>
>>>>
>>>> changeset 6c90850063a6 in /hg/release/icedtea6-1.8
>>>> details:
>>>> http://icedtea.classpath.org/hg/release/icedtea6-1.8?cmd=changeset;node=6c90850063a6
>>>> author: doko at ubuntu.com
>>>> date: Wed Mar 31 02:41:55 2010 +0200
>>>>
>>>>       Fix for fast bytecode in cpp interpreter
>>>>
>>>>
>>>> diffstat:
>>>>
>>>> 3 files changed, 20 insertions(+)
>>>> ChangeLog                                        |    4 ++++
>>>> Makefile.am                                      |    1 +
>>>> patches/zero/cppInterpreter-fast-bytecodes.patch |   15 +++++++++++++++
>>>>
>>>> diffs (41 lines):
>>>>
>>>> diff -r e3d17434ea31 -r 6c90850063a6 ChangeLog
>>>> --- a/ChangeLog Wed Mar 31 01:53:39 2010 +0200
>>>> +++ b/ChangeLog Wed Mar 31 02:41:55 2010 +0200
>>>> @@ -1,3 +1,7 @@ 2010-03-31  Matthias Klose  <doko at ubuntu
>>>> +2010-03-30  Edward Nevill   <ed at camswl.com>
>>>> +
>>>> +       * bytecodeInterpreter.cpp Fix to support fast bytecodes
>>>> +
>>>>  2010-03-31  Matthias Klose  <doko at ubuntu.com>
>>>>
>>>>       * acinclude.m4 (ENABLE_ZERO_BUILD): Depend on
>>>> IT_SET_ARCH_SETTINGS.
>>>> diff -r e3d17434ea31 -r 6c90850063a6 Makefile.am
>>>> --- a/Makefile.am       Wed Mar 31 01:53:39 2010 +0200
>>>> +++ b/Makefile.am       Wed Mar 31 02:41:55 2010 +0200
>>>> @@ -220,6 +220,7 @@ ICEDTEA_PATCHES = \
>>>>       patches/zero/6909153.patch \
>>>>       patches/zero/6913869.patch \
>>>>       patches/zero/6914622.patch \
>>>> +       patches/zero/cppInterpreter-fast-bytecodes.patch \
>>>>       patches/icedtea-notice-safepoints.patch \
>>>>       patches/icedtea-parisc-opt.patch \
>>>>       patches/icedtea-lucene-crash.patch \
>>>> diff -r e3d17434ea31 -r 6c90850063a6
>>>> patches/zero/cppInterpreter-fast-bytecodes.patch
>>>> --- /dev/null   Thu Jan 01 00:00:00 1970 +0000
>>>> +++ b/patches/zero/cppInterpreter-fast-bytecodes.patch  Wed Mar 31
>>>> 02:41:55 2010 +0200
>>>> @@ -0,0 +1,15 @@
>>>> +Index: openjdk/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp
>>>> +===================================================================
>>>> +---
>>>> openjdk.orig/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp
>>>>  2010-03-19 10:35:14.000000000 +0100
>>>> ++++ openjdk/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp
>>>> 2010-03-19 10:39:01.000000000 +0100
>>>> +@@ -2328,6 +2328,10 @@
>>>> +       }
>>>> +
>>>> +       DEFAULT:
>>>> ++         if (Bytecodes::is_defined((Bytecodes::Code)opcode)) {
>>>> ++           opcode =
>>>> (jubyte)Bytecodes::java_code((Bytecodes::Code)opcode);
>>>> ++           goto opcode_switch;
>>>> ++         }
>>>> +           fatal2("\t*** Unimplemented opcode: %d = %s\n",
>>>> +                  opcode, Bytecodes::name((Bytecodes::Code)opcode));
>>>> +           goto finish;
>>>>
>>>>
>>>
>>> I didn't see any review of this for HEAD, never mind for the branch.
>>>
>>> THe HotSpot team suggested it may cause a performance deficit:
>>>
>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2010-March/002967.html
>>>
>>
>> Ok, there was a post for the HEAD commit:
>>
>>
>> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-March/008818.html
>>
>> which must have got lost in all the security updates.  However,  I
>> still don't think this should be added to the 1.8 branch until all
>> issues have been resolved with upstream.
>>
>
> I am happy to see this fix in the release branch and head since if fixes a
> issue found in both branches.
>
> The reason why the HotSpot team dont understand how fast bytecodes can end
> up in the cpp interpreter are because the fast bytecodes are inserted by the
> new ARM ASM interpreter and all the new ARM ASM interpreter code changesets
> have not yet been upstreamed, so the hotspot team currently dont know about
> these changesets existance.
> This issue itself currently hits when Shark directly calls the cpp
> interpreterts main loop after marking a method non entrant.
> Most of the time the fast bytecodes will be handled optimally by the new ASM
> interpreter on ARM thus this do not cause any performance deficit.
>

Yes, it fixes an issue with Shark.  But it affects code used by
HotSpot generally.  We shouldn't be putting it in a release without
more time for testing.

> Ed: Are the ASM interpreter in a good shape in order to begin upstreaming to
> OpenJDK?
>
> Cheers
> Xerxes
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8