String.indexOf optimization

[Zoltan Sziladi]

Hi,

Thanks everyone for all the info.
So, just to go step by step in understanding this.
Andrew said HotSpot would ignore my implementation. So why is there an
implementation of indexOf at all in the JDK, if that's not the code that's
executed? Is it just a default fallback? When is the indexOf function not
intrinsified? When do people usually disable intrinsification?
Sorry if these are newbie questions, I'm new to this part of Java.

Regards,
Zoltan

On Tue, Jan 6, 2015 at 1:28 AM, Andrew Haley <aph at redhat.com> wrote:

> Hi,
>
> On 05/01/15 18:59, Zoltan Sziladi wrote:
>
> > This discussion was a long time ago, I was just reading through it to
> check
> > again what was the last state of the discussion about the String.indexOf.
> > There is one part which I still do not understand, hopefully someone
> could
> > shed some light on it. A few emails ago Martin mentioned
> >
> > "Hotspot seems to have some intrinsification of String.indexOf, which
> > confuses me.
> > Hotspot seems the right place to provide more optimizations for this,
> since
> > there has been a fair amount of work creating high-performance low-level
> > implementations of this idea in C."
> >
> > Then Ivan asked what that actually meant, whether hotspot actually
> replaced
> > the jdk implementation with a low level optimized C implementation, but I
> > never saw an answer to that.
>
> You can have a look at an implementation of MacroAssembler::string_indexof
> in
>
>
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/b6b89b8f8531/src/cpu/x86/vm/macroAssembler_x86.cpp
>
> > Can someone please explain this? If we somehow found an algorithm that
> beat
> > the naive implementation in the average case, would it be possible to
> just
> > implement it in the JDK?
>
> No, because HotSpot would ignore it.  Any speed improvements have to be
> done in the architecture-dependent files.
>
> Andrew.
>
>