[cp-patches] Re: String class: hack for ORP 1.0.9

Hi David, On Tue, 2005-07-12 at 08:06 -0400, David P Grove wrote: So, I'm having a hard time seeing how this optimization actually makes the code faster under any reasonable assumptions of what an optimizing JIT is going to do. It seems mostly harmless to have it (although it makes the

Re: String class: hack for ORP 1.0.9

Hi David, On Tue, 2005-07-12 at 08:06 -0400, David P Grove wrote: So, I'm having a hard time seeing how this optimization actually makes the code faster under any reasonable assumptions of what an optimizing JIT is going to do. It seems mostly harmless to have it (although it makes the

[cp-patches] Re: String class: hack for ORP 1.0.9

So, I'm having a hard time seeing how this optimization actually makes the code faster under any reasonable assumptions of what an optimizing JIT is going to do. It seems mostly harmless to have it (although it makes the method larger, and thus a slightly less attractive candidate for

Re: String class: hack for ORP 1.0.9

On Tue, 2005-07-12 at 13:02 +1200, Simon Kitching wrote: I just wondered if it was time to remove this hack... Wow, that is a very old workaround. And indeed a nice optimization to have. A quick startup of eclipse (with just a little project) shows 4642 hits of String.toCharArray() of which 4200

Re: String class: hack for ORP 1.0.9

So, I'm having a hard time seeing how this optimization actually makes the code faster under any reasonable assumptions of what an optimizing JIT is going to do. It seems mostly harmless to have it (although it makes the method larger, and thus a slightly less attractive candidate for

Re: String class: hack for ORP 1.0.9

Guess I'm showing my bias ;-) It is very easy to get the right thing to happen in Jikes RVM... In general, you are right about native methods being a barrier to JIT optimization (btw there was an interesting paper in VEE'05 last month by Stepanian et al on a system that can inline native

Re: String class: hack for ORP 1.0.9

David P Grove wrote: So, I'm having a hard time seeing how this optimization actually makes the code faster under any reasonable assumptions of what an optimizing JIT is going to do. It seems mostly harmless to have it (although it makes the method larger, and thus a slightly less attractive

Re: String class: hack for ORP 1.0.9

Simon Kitching wrote: public char[] toCharArray() { // XXX ORP 1.0.9 crashes on (char[]) clone() during bootstrap, so we // omit this optimization for now. // if (count == value.length) // return (char[]) value.clone(); char[] copy = new char[count];