hg: hsx/hotspot-comp/hotspot: 7013347: allow crypto functions to be called inline to enhance performance

Krystal Mok rednaxelafx at gmail.com
Mon Feb 6 18:20:41 PST 2012


Hi Tom,

Oops, yes I did mean the UEP code. Typos...

Got it. Thanks for the explanation. That makes sense.

The original thinking behind modifying the UEP sequence in native wrapper
is that the more space it takes, the more likely it'll become a code bubble
that affects i-cache. The patch in the earlier post also modified the place
where it checks thread state, which should also reduce code bubble for the
common case.

Regards,
Kris Mok

On Tue, Feb 7, 2012 at 9:07 AM, Tom Rodriguez <tom.rodriguez at oracle.com>wrote:

>
> On Feb 2, 2012, at 9:05 PM, Krystal Mok wrote:
>
> > Hi Tom,
> >
> > Just noticed that this changeset modifed the JNI native wrapper.
> >
> > Might a bit late to mention, Joseph proposed a modification to the JNI
> native wrapper's VEP code sequence [1]. Could it be taken into
> consideration sometime in the future?
>
> You mean the UEP code?  I may be reworking these a bit more in the future
> so I might incorporate some of that.  In general the UEP code is never used
> for natives since they tend to be non-virtual.  So making them more
> efficient would only save a bit of space but not performance.  The whole
> UEP idiom should be in a piece of shared code somewhere where it can be
> standardized.  Ideally it should be aligned upwards so that there no nops
> introduced by the alignment.
>
> tom
>
> >
> > Regards,
> > Kris Mok
> >
> > [1]:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2011-November/004754.html
> >
> > On Thu, Feb 2, 2012 at 11:03 AM, <tom.rodriguez at oracle.com> wrote:
> > Changeset: 0382d2b469b2
> > Author:    never
> > Date:      2012-02-01 16:57 -0800
> > URL:
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0382d2b469b2
> >
> > 7013347: allow crypto functions to be called inline to enhance
> performance
> > Reviewed-by: kvn
> >
> > ! src/cpu/sparc/vm/assembler_sparc.hpp
> > ! src/cpu/sparc/vm/assembler_sparc.inline.hpp
> > ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
> > ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
> > ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
> > ! src/share/vm/code/nmethod.cpp
> > ! src/share/vm/code/nmethod.hpp
> > ! src/share/vm/memory/gcLocker.cpp
> > ! src/share/vm/memory/gcLocker.hpp
> > ! src/share/vm/oops/arrayOop.cpp
> > ! src/share/vm/oops/methodOop.cpp
> > ! src/share/vm/oops/methodOop.hpp
> > ! src/share/vm/prims/nativeLookup.cpp
> > ! src/share/vm/prims/nativeLookup.hpp
> > ! src/share/vm/runtime/globals.hpp
> > ! src/share/vm/runtime/safepoint.cpp
> > ! src/share/vm/runtime/safepoint.hpp
> > ! src/share/vm/runtime/sharedRuntime.cpp
> > ! src/share/vm/runtime/sharedRuntime.hpp
> > ! src/share/vm/runtime/thread.cpp
> > ! src/share/vm/runtime/thread.hpp
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120207/bf1af871/attachment.html 


More information about the hotspot-compiler-dev mailing list