hg: hsx/hotspot-comp/hotspot: 7013347: allow crypto functions to be called inline to enhance performance
Tom Rodriguez
tom.rodriguez at oracle.com
Mon Feb 6 18:25:32 PST 2012
On Feb 6, 2012, at 6:20 PM, Krystal Mok wrote:
> 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.
The various native wrappers are inconsistent whether they do their work inline vs. out of line and out of line should generally be better. I certainly may do that part to tighten up the core of the native wrapper code.
tom
>
> 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
> >
> >
>
>
More information about the hotspot-compiler-dev
mailing list