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

[Vitaly Davidovich]

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?

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