On 23 Sep 2015, at 08:55, Tagir F. Valeev <amae...@gmail.com> wrote:
> Hello!
> 
> Quite interesting feature. Isn't it a typo here?
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/src/java.base/share/classes/java/util/ArraysSupport.java.html
> 
> 419    if (!Float.isNaN(a[aFromIndex + i]) || !Float.isNaN(b[aFromIndex + i]))
> 487    if (!Double.isNaN(a[aFromIndex + i]) || !Double.isNaN(b[aFromIndex + 
> i]))
> 
> Seems that it should be b[bFromIndex + i], not b[aFromIndex + i] in
> both cases.
> 

Oops, well spotted, thanks. Testing for NaNs can be tricky, now i need to work 
out why the tests did not capture that!


> As for methods like compare(byte[] a, int aFromIndex, int aToIndex,
>                            byte[] b, int bFromIndex, int bToIndex)
> 
> Is it better to introduce two to-indices instead of single length
> argument (like in System.arraycopy)?

Because that’s the style of usage in Arrays, and AFAICT the common style used 
by apps/frameworks that have rolled their own array comparators.


> Six method arguments looks
> a little bit crowded.
> 
> As for method count, it would be really nice and user-friendly were it
> be possible to add methods to the array types themselves, so users can
> write:
> 
> byte[] b1;
> byte[] b2;
> 
> int mismatchPos = b1.mismatch(b2);
> Comparator<byte[]> cmp = byte[]::compareTo;
> 
> This somehow works with clone() method (I guess, there is some very
> special code in javac for this). There could be some special abstract
> classes like java.lang.ByteArray with private constructor (using
> this[idx] to access elements) and all byte[] arrays could extend them,
> so JDK developers could add new methods to arrays without modifying
> the compiler. Well, that's just my fantasies about the better
> world…
> 


Perhaps it’s closer than you think, although further away than you might like 
:-) There are some experiments in Project Valhalla [1]. We would like all 
arrays to extend from a common array super type, from which we can then hang 
off further methods. That’s part of the Arrays 2.0 story.

You correctly guessed there is currently something special going in javac and 
the VM. I think it might be quite simple to extend javac. The tricky work is 
more likely in the VM to hook in the array super type and it's methods (perhaps 
patching into the underlying array class's v/itables).

Paul.

[1] http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/73ae1e2cbb20

Reply via email to