On Mon, Jan 26, 2015 at 10:50 PM, Zoltan Sziladi
wrote:
>
> By the way, can you tell me why you used named loops in your code? Isn't
> it considered bad practice as it is almost like a goto statement? Couldn't
> we refactor it in a way that we do not use named loops?
>
Here in core-libs-land, we
Hi Martin,
Nice catches on the cleanup!
By the way, can you tell me why you used named loops in your code? Isn't it
considered bad practice as it is almost like a goto statement? Couldn't we
refactor it in a way that we do not use named loops?
Also, if there is a for loop that has no start state
On Sat, Jan 24, 2015 at 1:19 PM, Vitaly Davidovich
wrote:
> Try -XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic:_indexOf
>
Thank you very much! Hard to find because -XX:+PrintFlagsFinal is
insufficient - also needs -XX:+UnlockDiagnosticVMOptions
Try -XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic:_indexOf
sent from my phone
On Jan 24, 2015 4:13 PM, "Martin Buchholz" wrote:
> I took another look. It seems to me that the java code implementing
> String.indexOf still assumes the old String layout and so is full of dead
> code, which s
I took another look. It seems to me that the java code implementing
String.indexOf still assumes the old String layout and so is full of dead
code, which should be excised just to be clean. (I continue to think the
change to String layout came too late in the life of Java and is incomplete
in way
Martin, yes, we're talking about that method.
Other than tightening that code some... if we find some algorithm that
outperforms the naive implementation under certain conditions (let's say
when the searched pattern is longer than 10 characters), would it be worth
including it as a special case? (
If there's a clean improvement in the java code, it's worth putting in.
You can try benchmarking with -Xint.
Are we talking about this method?
static int indexOf(char[] source, int sourceOffset, int sourceCount,
char[] target, int targetOffset, int targetCount,
int from
I'm fairly certain that nobody would object if you send a patch with
reproducible benchmark code demonstrating the gain. I think this mostly
comes down to cost/benefit of doing this work, and the benefit is
marginalized out of the gate by virtue of the intrinsic. You'd probably
also have to demon
Thanks for the info.
So that basically means we have 2 implementations of indexOf currently, one
is in HotSpot, the other is in the JDK itself, which rarely gets executed.
Aside from this later fact, isn't it still worth improving the JDK
implementation if it is possible? I know that the intrinsifi
The java impl you saw would be called by (a) interpreter, (b) if you
explicitly disable intrinsification of this function, or (c) some other JVM
that doesn't intrinsify this method (or any method).
People don't usually disable intrinsics; if they do, it's because they hit
some JIT bug and may disa
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 fu
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
Hi,
Sharing in case you haven't seen it... Aleksey Shipilëv has a talk about
String optimizations, which discusses these questions and specifically the
Boyer-Moore algorithm.
http://shipilev.net/talks/joker-Oct2014-string-catechism.pdf
Page 85 talks about the intrinsification of indexOf and comp
Evidence that hotspot tries to intrinsify String.indexOf:
do_intrinsic(_indexOf,
java_lang_String, indexOf_name, string_int_signature,
F_R) \
do_name( indexOf_name,"indexOf")
\
So
Hi,
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 se
On 16.04.2014 2:53, Martin Buchholz wrote:
Hi Ivan,
There's already an indexOf(int, int) that allows a user to explicitly
search for a char (or character).
Sure.
What I meant was not to introduce a special function for searching a
single character, but to restrict the general case loop to
Hi everyone!
On 04.04.2014 21:13, Martin Buchholz wrote:
Summary:
Many people (myself included) have looked at this problem. It's unlikely
that String.indexOf will change. It's hard to beat the naive
implementation in the typical case.
But we can try to speed up this naive implementation a l
Thanks everyone for the input. Even though many people who are way
smarter than me already tried to beat the naive implementation, I'll
try too, just for the fun of it. I'll post my updates here if I find
something worthy of mentioning.
Zoltan
On Fri, Apr 4, 2014 at 7:13 PM, Martin Buchholz wrot
On 04/04/2014 05:18 PM, Alan Bateman wrote:
On 04/04/2014 15:49, Zoltan Sziladi wrote:
Hi,
I am new to this mailing list so please forgive me if this has been
discussed before.
I was looking at the implementation of String.indexOf and I see that
it uses the O(n^2) naive implementation. I have
On 04/04/2014 15:49, Zoltan Sziladi wrote:
Hi,
I am new to this mailing list so please forgive me if this has been
discussed before.
I was looking at the implementation of String.indexOf and I see that
it uses the O(n^2) naive implementation. I have been trying to find
out why it does not use s
Hi,
I am new to this mailing list so please forgive me if this has been
discussed before.
I was looking at the implementation of String.indexOf and I see that
it uses the O(n^2) naive implementation. I have been trying to find
out why it does not use some kind of a modern, sophisticated O(n)
algo
21 matches
Mail list logo
