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

[Xerxes Ranby]

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.

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

Cheers
Xerxes