8008243: Zero: implement fast-bytecodes [Was: Re: [RFC] Fast-bytecodes for Zero]

[Christian Thalinger]

On Feb 15, 2013, at 6:39 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

> Hi Roman,
> 
> One suggestion I have is to add functions to JvmtiExport like has_field_access_watchers() and change this accordingly:
> 
> count_addr = (int *)JvmtiExport::get_field_access_count_addr(); \
> 436     if ( *count_addr > 0 ) {       
> 
> The has_XXX function can simply have that code inside.
> 
> Reason I think it's useful is because the field is an int but the get_* function declares address as return type requiring you to cast and thus know internal representation.  Seems cleaner to encapsulate inside JvmtiExport?

I agree on that but that would be beyond the scope of this change.  Roman only moved the code into a macro so he can reuse it in multiple places.  Actually I would prefer to move the code into a method because that would make the huge method a little smaller.

-- Chris

> 
> Thanks
> 
> Sent from my phone
> 
> On Feb 15, 2013 5:23 AM, "Roman Kennke" <rkennke at redhat.com> wrote:
> Hi David,
> 
> Am Freitag, den 15.02.2013, 17:25 +1000 schrieb David Holmes:
> > There's a lot of changes to shared code here - what is the impact on
> > non-zero platforms?
> 
> The changes to shared code are in bytecodeInterpreter.cpp, which is, to
> my knowledge, only used by Zero. *If* there are other interpreters that
> use it (maybe in closed trees?) they would most likely just pick up and
> benefit from the improvements. But of course, I cannot tell...
> 
> Regards,
> Roman
> 
> > Thanks,
> > David
> >
> > On 15/02/2013 4:51 AM, Christian Thalinger wrote:
> > > I've filed:
> > >
> > > 8008243: Zero: implement fast-bytecodes
> > >
> > > -- Chris
> > >
> > > On Feb 13, 2013, at 11:40 AM, Roman Kennke <rkennke at redhat.com> wrote:
> > >
> > >> The following change implements support for the following fast-bytecodes
> > >> in the Zero interpreter:
> > >>
> > >> fast_agetfield
> > >> fast_bgetfield
> > >> fast_cgetfield
> > >> fast_dgetfield
> > >> fast_fgetfield
> > >> fast_igetfield
> > >> fast_lgetfield
> > >> fast_sgetfield
> > >> fast_aputfield
> > >> fast_bputfield
> > >> fast_cputfield
> > >> fast_dputfield
> > >> fast_fputfield
> > >> fast_iputfield
> > >> fast_lputfield
> > >> fast_sputfield
> > >> fast_aload_0
> > >> fast_iaccess_0
> > >> fast_aaccess_0
> > >> fast_faccess_0
> > >> fast_iload
> > >> fast_iload2
> > >> fast_icaload
> > >> fast_invokevfinal
> > >>
> > >> All together this leads to a speedup of the interpreter of about 25%.
> > >>
> > >> Some notes:
> > >> - I extracted the JVMTI related blocks into a macro to avoid repetition.
> > >> - The field get/put opcodes are only rewritten for non-volatile
> > >> non-static field access, this makes the fast one really fast (no
> > >> additional branches needed), and static/volatile field accesses seem
> > >> rare enough anyway.
> > >>
> > >> http://cr.openjdk.java.net/~rkennke/zero-fast-opcodes/webrev.00/
> > >>
> > >>
> > >> Opinions? Can this be included in hotspot? And Can I have a bug-ID?
> > >>
> > >> Best regards,
> > >> Roman
> > >>
> > >>
> > >
> 
>