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

[Roman Kennke]

Am Montag, den 18.02.2013, 12:30 -0800 schrieb 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.

I agree with both of you.  :-)

I also tried to move this code into separate methods. However, this
seems to be very difficult, because the CALL_VM macro depends on a lot
of variables local to the interpreter loop: cp, locals, cache, thread,
topOfStack, pc, istate and handle_exception, handle_Pop_frame
(goto-labels). Yes, it is possible to somehow pass everything into such
a method, but this seems awkward. I am not sure what is the lesser evil
here.

Roman

> 
> -- 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
> > > >>
> > > >>
> > > >
> > 
> > 
>