From Alan.Bateman at Sun.COM Thu Apr 1 12:52:32 2010 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 01 Apr 2010 20:52:32 +0100 Subject: Swap should be better done native? In-Reply-To: References: <4BB20D1E.4090301@gmx.de> <87ljd9sm6o.fsf@mid.deneb.enyo.de> <4BB39315.1020005@gmx.de> <1ccfd1c11003311140u51df1dcbld7155ca4b1f1cfea@mail.gmail.com> <4BB39C08.5040003@gmx.de> <1ccfd1c11003311206l23bb0783k11296eb6370c536@mail.gmail.com> <4BB3C9D3.8040908@gmx.de> Message-ID: <4BB4F980.1090409@sun.com> Martin Buchholz wrote: > Alan, please file a bug and review this change. > > Synopsis: Optimize java/nio/Bits.java > Description: > Use intrinsified reverseBytes operation; elide no-op constructs > > > Sorry for the late reply, I've been busy in other areas recently. I've created: 6940258: (bf) Use intrinsified reverseBytes operation; elide no-op constructs and will review when you (and Ulf) are done. -Alan. PS: I've moved this back thread back to nio-dev. From Ulf.Zibis at gmx.de Fri Apr 2 07:13:37 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 02 Apr 2010 16:13:37 +0200 Subject: Swap should be better done native? In-Reply-To: <4BB5348B.8080507@gmx.de> References: <4BB20D1E.4090301@gmx.de> <1ccfd1c11003301759h31e9dd19ie7f440c429def49e@mail.gmail.com> <4BB3B902.6070902@gmx.de> <4BB3D6A4.7090608@gmx.de> <4BB5348B.8080507@gmx.de> Message-ID: <4BB5FB91.2070802@gmx.de> Am 02.04.2010 02:04, schrieb Ulf Zibis: > Am 01.04.2010 01:29, schrieb Martin Buchholz: >> On Wed, Mar 31, 2010 at 16:11, Ulf Zibis wrote: >>> Not to forget java.nio.Heap-X-Buffer.java.template. >> Ulf, would you like to provide a patch that deletes all uses of >> java.nio.Bits.swap and replaces them with the relevant >> reverseBytes methods? > > See attachments. > > Number_reverseBytes: > - Most, but not all, i.e. Float, Double, SIZE constants were at > "wrong" position. I have corrected this. > - I too think, serialVersionIDs should be positioned more upper, e.g. > as last of all static finals. > > X-Buffer_swap: > - I'm not enough experienced in make files, and I can't run them on my > Windows system, so genBuffer.sh change is incomplete. > X-Buffer_swap2: - Removed superfluous casts and bloated white space. -Ulf -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: X-Buffer_swap2 Url: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100402/6e8de544/attachment-0001.ksh From Ulf.Zibis at gmx.de Fri Apr 2 10:50:43 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 02 Apr 2010 19:50:43 +0200 Subject: Swap should be better done native? In-Reply-To: <4BB5FB91.2070802@gmx.de> References: <4BB20D1E.4090301@gmx.de> <1ccfd1c11003301759h31e9dd19ie7f440c429def49e@mail.gmail.com> <4BB3B902.6070902@gmx.de> <4BB3D6A4.7090608@gmx.de> <4BB5348B.8080507@gmx.de> <4BB5FB91.2070802@gmx.de> Message-ID: <4BB62E73.7080500@gmx.de> Am 02.04.2010 16:13, schrieb Ulf Zibis: > Am 02.04.2010 02:04, schrieb Ulf Zibis: >> Am 01.04.2010 01:29, schrieb Martin Buchholz: >>> On Wed, Mar 31, 2010 at 16:11, Ulf Zibis wrote: >>>> Not to forget java.nio.Heap-X-Buffer.java.template. >>> Ulf, would you like to provide a patch that deletes all uses of >>> java.nio.Bits.swap and replaces them with the relevant >>> reverseBytes methods? >> >> See attachments. >> >> Number_reverseBytes: >> - Most, but not all, i.e. Float, Double, SIZE constants were at >> "wrong" position. I have corrected this. >> - I too think, serialVersionIDs should be positioned more upper, e.g. >> as last of all static finals. >> >> X-Buffer_swap: >> - I'm not enough experienced in make files, and I can't run them on >> my Windows system, so genBuffer.sh change is incomplete. >> > > X-Buffer_swap2: > - Removed superfluous casts and bloated white space. Corrected little bug -Ulf -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: X-Buffer_swap2 Url: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100402/df61e934/attachment.ksh From martinrb at google.com Fri Apr 2 11:42:09 2010 From: martinrb at google.com (Martin Buchholz) Date: Fri, 2 Apr 2010 11:42:09 -0700 Subject: Swap should be better done native? In-Reply-To: <4BB52994.6070005@gmx.de> References: <4BB20D1E.4090301@gmx.de> <4BB39315.1020005@gmx.de> <1ccfd1c11003311140u51df1dcbld7155ca4b1f1cfea@mail.gmail.com> <4BB39C08.5040003@gmx.de> <1ccfd1c11003311206l23bb0783k11296eb6370c536@mail.gmail.com> <4BB3B390.8040806@gmx.de> <4BB4924C.8010606@gmx.de> <4BB52994.6070005@gmx.de> Message-ID: On Thu, Apr 1, 2010 at 16:17, Ulf Zibis wrote: > Am 01.04.2010 23:55, schrieb Martin Buchholz: >> >> On Thu, Apr 1, 2010 at 05:32, Ulf Zibis ?wrote: >> >> >>>> >>>> How can 4 put(byte) be converted into one put(int)? >>>> >>>> >>> >>> See the following code snippets ... >>> >>> =================================================== >>> Codesnippet from EUC_TW$Encoder: >>> ? ? ? ? ? ?dst.put(SS2); >>> ? ? ? ? ? ?dst.put((byte)(0xa0 | p)); >>> ? ? ? ? ? ?dst.put((byte)(db>> ?8)); >>> ? ? ? ? ? ?dst.put((byte)db); >>> >> >> >>> >>> =================================================== >>> Alternative 1 codesnippet: >>> ? ? ? ? ? ?dst.putInt((SS2<< ?24) | (0xa0<< ?16) | (p<< ?16) | db); >>> >> >> Ahhh, I see. ?Direct buffers are optimized to use Unsafe.putInt >> on platforms where unaligned writes are possible (i.e. x86). >> >> Some problems with that: >> - this only works on x86 >> > > Correct me if I'm wrong: On all platforms 4 put(byte) can be converted into > one put(int), but the performance win would be different. No. In general, we can't assume that the target address is int-aligned, and non-x86 architectures require alignment for word writes to memory. > Maybe using put(byte[]) would be better on other platforms ? But then you'd have to allocate an expensive byte array, and write to it first? >> - this doesn't work with other subclasses of ByteBuffer >> > > Not sure, if I understand right. Which subclasses you mean? CharBuffer, > e.g., is NOT subclass of ByteBuffer. > But I see an advantage to have putInt/Long in Char/Short/IntegerBuffer. > >> - I would think optimizing the case of ByteBuffer with arrays >> ? (ie. hasArray() is true) would be more important. >> > > I don't think, optimizing the case for the direct buffers would harm the > case for the heap buffers. charsets have two cases - general Buffer implementation, and a specialized one if hasArray() is true for both Buffers. So switching to putInt instead of putByte might slow things down either on non-x86 or if transferring between direct buffer and heap buffer. Martin From Ulf.Zibis at gmx.de Fri Apr 2 15:42:11 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 03 Apr 2010 00:42:11 +0200 Subject: Swap should be better done native? In-Reply-To: <4BB62E73.7080500@gmx.de> References: <4BB20D1E.4090301@gmx.de> <1ccfd1c11003301759h31e9dd19ie7f440c429def49e@mail.gmail.com> <4BB3B902.6070902@gmx.de> <4BB3D6A4.7090608@gmx.de> <4BB5348B.8080507@gmx.de> <4BB5FB91.2070802@gmx.de> <4BB62E73.7080500@gmx.de> Message-ID: <4BB672C3.1040106@gmx.de> Am 02.04.2010 19:50, schrieb Ulf Zibis: > Am 02.04.2010 16:13, schrieb Ulf Zibis: >> Am 02.04.2010 02:04, schrieb Ulf Zibis: >>> Am 01.04.2010 01:29, schrieb Martin Buchholz: >>>> On Wed, Mar 31, 2010 at 16:11, Ulf Zibis wrote: >>>>> Not to forget java.nio.Heap-X-Buffer.java.template. >>>> Ulf, would you like to provide a patch that deletes all uses of >>>> java.nio.Bits.swap and replaces them with the relevant >>>> reverseBytes methods? >>> >>> See attachments. >>> >>> Number_reverseBytes: >>> - Most, but not all, i.e. Float, Double, SIZE constants were at >>> "wrong" position. I have corrected this. >>> - I too think, serialVersionIDs should be positioned more upper, >>> e.g. as last of all static finals. >>> >>> X-Buffer_swap: >>> - I'm not enough experienced in make files, and I can't run them on >>> my Windows system, so genBuffer.sh change is incomplete. >>> >> >> X-Buffer_swap2: >> - Removed superfluous casts and bloated white space. > X-Buffer_swap3: - Use more descriptive names Alternatively I think we would better have separate classes for DirectByteBufferX e.g.: - DirectByteBuffer - DirectByteBufferR - DirectUnalignedByteBuffer (unalignedAccessible) - DirectUnalignedByteBufferR (unalignedAccessible) -Ulf -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: X-Buffer_swap3 Url: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100403/d9ccb6f5/attachment.ksh From Ulf.Zibis at gmx.de Fri Apr 2 16:01:26 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 03 Apr 2010 01:01:26 +0200 Subject: Swap should be better done native? In-Reply-To: <4BB672C3.1040106@gmx.de> References: <4BB20D1E.4090301@gmx.de> <1ccfd1c11003301759h31e9dd19ie7f440c429def49e@mail.gmail.com> <4BB3B902.6070902@gmx.de> <4BB3D6A4.7090608@gmx.de> <4BB5348B.8080507@gmx.de> <4BB5FB91.2070802@gmx.de> <4BB62E73.7080500@gmx.de> <4BB672C3.1040106@gmx.de> Message-ID: <4BB67746.4040705@gmx.de> Am 03.04.2010 00:42, schrieb Ulf Zibis: > Am 02.04.2010 19:50, schrieb Ulf Zibis: >> Am 02.04.2010 16:13, schrieb Ulf Zibis: >>> Am 02.04.2010 02:04, schrieb Ulf Zibis: >>>> Am 01.04.2010 01:29, schrieb Martin Buchholz: >>>>> On Wed, Mar 31, 2010 at 16:11, Ulf Zibis wrote: >>>>>> Not to forget java.nio.Heap-X-Buffer.java.template. >>>>> Ulf, would you like to provide a patch that deletes all uses of >>>>> java.nio.Bits.swap and replaces them with the relevant >>>>> reverseBytes methods? >>>> >>>> See attachments. >>>> >>>> Number_reverseBytes: >>>> - Most, but not all, i.e. Float, Double, SIZE constants were at >>>> "wrong" position. I have corrected this. >>>> - I too think, serialVersionIDs should be positioned more upper, >>>> e.g. as last of all static finals. >>>> >>>> X-Buffer_swap: >>>> - I'm not enough experienced in make files, and I can't run them on >>>> my Windows system, so genBuffer.sh change is incomplete. >>>> >>> >>> X-Buffer_swap2: >>> - Removed superfluous casts and bloated white space. >> > > X-Buffer_swap3: > - Use more descriptive names > > Alternatively I think we would better have separate classes for > DirectByteBufferX e.g.: > - DirectByteBuffer > - DirectByteBufferR > - DirectUnalignedByteBuffer (unalignedAccessible) > - DirectUnalignedByteBufferR (unalignedAccessible) Corrected. -Ulf -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: X-Buffer_swap3 Url: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100403/a2a2292c/attachment.ksh From Ulf.Zibis at gmx.de Fri Apr 2 16:56:22 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 03 Apr 2010 01:56:22 +0200 Subject: Swap should be better done native? In-Reply-To: References: <4BB20D1E.4090301@gmx.de> <4BB39315.1020005@gmx.de> <1ccfd1c11003311140u51df1dcbld7155ca4b1f1cfea@mail.gmail.com> <4BB39C08.5040003@gmx.de> <1ccfd1c11003311206l23bb0783k11296eb6370c536@mail.gmail.com> <4BB3B390.8040806@gmx.de> <4BB4924C.8010606@gmx.de> <4BB52994.6070005@gmx.de> Message-ID: <4BB68426.1060703@gmx.de> Am 02.04.2010 20:42, schrieb Martin Buchholz: > On Thu, Apr 1, 2010 at 16:17, Ulf Zibis wrote: > >> Am 01.04.2010 23:55, schrieb Martin Buchholz: >> >>> On Thu, Apr 1, 2010 at 05:32, Ulf Zibis wrote: >>> >>> >>> >>>>> How can 4 put(byte) be converted into one put(int)? >>>>> >>>>> >>>>> >>>> See the following code snippets ... >>>> >>>> =================================================== >>>> Codesnippet from EUC_TW$Encoder: >>>> dst.put(SS2); >>>> dst.put((byte)(0xa0 | p)); >>>> dst.put((byte)(db>> 8)); >>>> dst.put((byte)db); >>>> >>>> >>> >>> >>>> =================================================== >>>> Alternative 1 codesnippet: >>>> dst.putInt((SS2<< 24) | (0xa0<< 16) | (p<< 16) | db); >>>> >>>> >>> Ahhh, I see. Direct buffers are optimized to use Unsafe.putInt >>> on platforms where unaligned writes are possible (i.e. x86). >>> >>> Some problems with that: >>> > >>> - this only works on x86 >>> >>> >> Correct me if I'm wrong: On all platforms 4 put(byte) can be converted into >> one put(int), but the performance win would be different. >> > No. In general, we can't assume that the target address is int-aligned, > and non-x86 architectures require alignment for word writes to memory. > This should be a rare case even on non-x86 architectures. It generally should only happen, if the offset of a sliced buffer is not aligned to it's value size. Fresh allocated buffers should be always properly aligned (hopefully). I wanted to say, that 4 put(byte) can be replaced by one put(int), but would perform likely worse in the rare case of unaligned position pointer. E.g. this can happen frequently on UTF-8 coder, but could always be checked. > >> Maybe using put(byte[]) would be better on other platforms ? >> > But then you'd have to allocate an expensive byte array, > and write to it first? > This should not be expensive, if byte[] would be reused on same coder instance and -XX:+DoEscapeAnalysis is set or would become default in the future. See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6908239 > >>> - this doesn't work with other subclasses of ByteBuffer >>> >>> >> Not sure, if I understand right. Which subclasses you mean? CharBuffer, >> e.g., is NOT subclass of ByteBuffer. >> But I see an advantage to have putInt/Long in Char/Short/IntegerBuffer. >> >> >>> - I would think optimizing the case of ByteBuffer with arrays >>> (ie. hasArray() is true) would be more important. >>> >>> >> I don't think, optimizing the case for the direct buffers would harm the >> case for the heap buffers. >> > charsets have two cases - general Buffer implementation, > and a specialized one if hasArray() is true for both Buffers. > So switching to putInt instead of putByte > might slow things down either on non-x86 Therefore, as you have just suggested, heap buffers should be refactored to use unsafe char/short/int/long transfer on x86 architectures or if position pointer is properly aligned. BTW, my suggestion to use putChar(char)/put(byte[]) was only meant for direct buffer case in UTF_8$Encoder, respectively getChar(char)/get(byte[]) for UTF_8$Decoder. Looking in the disassembles I additionally believe, HotSpot could better optimize both cases, e.g. a previewing bounds check in case of consecutive bytes accessed or a more economical reuse of the arrays oop/content pointers. > or if > transferring between direct buffer and heap buffer. > Therefore I've implemented 4 cases in my SingleByteXcoder: https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteDecoder_new.java?rev=&view=markup https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/src/sun/nio/cs/SingleByteEncoder_new.java?rev=&view=markup -Ulf From martinrb at google.com Fri Apr 2 17:37:53 2010 From: martinrb at google.com (Martin Buchholz) Date: Fri, 2 Apr 2010 17:37:53 -0700 Subject: Swap should be better done native? In-Reply-To: <4BB68426.1060703@gmx.de> References: <4BB20D1E.4090301@gmx.de> <4BB39C08.5040003@gmx.de> <1ccfd1c11003311206l23bb0783k11296eb6370c536@mail.gmail.com> <4BB3B390.8040806@gmx.de> <4BB4924C.8010606@gmx.de> <4BB52994.6070005@gmx.de> <4BB68426.1060703@gmx.de> Message-ID: On Fri, Apr 2, 2010 at 16:56, Ulf Zibis wrote: >> No. ?In general, we can't assume that the target address is int-aligned, >> and non-x86 architectures require alignment for word writes to memory. >> > > This should be a rare case even on non-x86 architectures. > It generally should only happen, if the offset of a sliced buffer is not > aligned to it's value size. > Fresh allocated buffers should be always properly aligned (hopefully). > > I wanted to say, that 4 put(byte) can be replaced by one put(int), but would > perform likely worse in the rare case of unaligned position pointer. > E.g. this can happen frequently on UTF-8 coder, but could always be checked. I don't think unaligned access is rare. Perhaps because I've spent too much time in the zip implementation. Ulf, you could start a project to find all the places where we could replace unaligned reads on x86 with int reads. E.g. in zip_util.h I see #define CH(b, n) (((unsigned char *)(b))[n]) #define SH(b, n) (CH(b, n) | (CH(b, n+1) << 8)) #define LG(b, n) ((SH(b, n) | (SH(b, n+2) << 16)) &0xffffffffUL) #define LL(b, n) (((jlong)LG(b, n)) | (((jlong)LG(b, n+4)) << 32)) #define GETSIG(b) LG(b, 0) by conditionally using short, int, or long reads, you could speed up zip file reading significantly on x86. Which seems like an important optimization. Martin From Ulf.Zibis at gmx.de Sat Apr 10 09:59:49 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 10 Apr 2010 18:59:49 +0200 Subject: Swap should be better done native? In-Reply-To: <4BB67746.4040705@gmx.de> References: <4BB20D1E.4090301@gmx.de> <1ccfd1c11003301759h31e9dd19ie7f440c429def49e@mail.gmail.com> <4BB3B902.6070902@gmx.de> <4BB3D6A4.7090608@gmx.de> <4BB5348B.8080507@gmx.de> <4BB5FB91.2070802@gmx.de> <4BB62E73.7080500@gmx.de> <4BB672C3.1040106@gmx.de> <4BB67746.4040705@gmx.de> Message-ID: <4BC0AE85.5070506@gmx.de> Now I think, I've managed the make file. Here my 1st two changed changes... Would be nice, you would have a look at it. with some luck, the genBuffer.sh will run without errors. See attachments. Number_reverseBytes: - Most, but not all, i.e. Float, Double, SIZE constants were at "wrong" position. I have corrected this. - I too think, serialVersionIDs should be positioned more upper, e.g. as last of all static finals. X-Buffer_swap: - Use intrinsified reverseBytes operation; Omit zero shifts. -Ulf -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Number_reverseBytes Url: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100410/ed09735d/attachment-0002.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: X-Buffer_swap Url: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100410/ed09735d/attachment-0003.ksh From martinrb at google.com Sat Apr 10 23:34:54 2010 From: martinrb at google.com (Martin Buchholz) Date: Sat, 10 Apr 2010 23:34:54 -0700 Subject: Swap should be better done native? In-Reply-To: <4BC0AE85.5070506@gmx.de> References: <4BB20D1E.4090301@gmx.de> <4BB3B902.6070902@gmx.de> <4BB3D6A4.7090608@gmx.de> <4BB5348B.8080507@gmx.de> <4BB5FB91.2070802@gmx.de> <4BB62E73.7080500@gmx.de> <4BB672C3.1040106@gmx.de> <4BB67746.4040705@gmx.de> <4BC0AE85.5070506@gmx.de> Message-ID: I will help put some form of these changes into the JDK. My colleague HIroshi Yamauchi will be adding the missing intrinsification for Character.reverseBytes and Short.reverseBytes to hotspot. Because of this, we should not use my idea of having Character.reverseBytes call Integer.reverseBytes. The changes to genBuffer.sh should be tested in a complete clean build. I will help with this offline. Martin On Sat, Apr 10, 2010 at 09:59, Ulf Zibis wrote: > Now I think, I've managed the make file. > > Here my 1st two changed changes... > > Would be nice, you would have a look at it. with some luck, the genBuffer.sh > will run without errors. > > See attachments. > > Number_reverseBytes: > - Most, but not all, i.e. Float, Double, SIZE constants were at "wrong" > position. I have corrected this. > - I too think, serialVersionIDs should be positioned more upper, e.g. as > last of all static finals. > > X-Buffer_swap: > - Use intrinsified reverseBytes operation; Omit zero shifts. > > -Ulf > > From Ulf.Zibis at gmx.de Sat Apr 17 15:37:43 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 18 Apr 2010 00:37:43 +0200 Subject: Numerical error on native float access Message-ID: <4BCA3837.90906@gmx.de> There seems to be a bug in Float.intBitsToFloat(int) and/or Float.floatToRawIntBits(float) and/or sun.misc.Unsafe.getInt/Float. If I replace return Float.intBitsToFloat(Integer.reverseBytes(unsafe.getInt(offset))); with return reverseBytes(unsafe.getFloat(offset)); ... private static float reverseBytes(float x) { // intBitsToFloat, floatToRawIntBits should become NOP if intrinified return Float.intBitsToFloat(Integer.reverseBytes(Float.floatToRawIntBits(x))); } ... I get jtreg (jtr nioBuffer) failure with slightly different result: java.nio.DirectFloatBufferS[pos=0 lim=1792 cap=1792] 2f712001 java.lang.RuntimeException: java.nio.DirectFloatBufferS[pos=11 lim=11 cap=1792]: Expected ' '=0x0.91697687, got ' '=0x0.91795343 at Basic.fail(Basic.java:94) at Basic.ck(Basic.java:119) at BasicFloat.test(BasicFloat.java:494) at BasicByte.testViews(BasicByte.java:251) at BasicByte.test(BasicByte.java:618) at BasicByte.test(BasicByte.java:917) at Basic.main(Basic.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:613) at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:96) at java.lang.Thread.run(Thread.java:717) JavaTest Message: Test threw exception: java.lang.RuntimeException: java.nio.DirectFloatBufferS[pos=11 lim=11 cap=1792]: Expected ' '=0x0.91697687, got ' '=0x0.91795343 Equivalent error for equivalent methods in java.lang.Double. Any idea, which of the mentioned methods is wrong? -Ulf From martinrb at google.com Tue Apr 20 00:02:16 2010 From: martinrb at google.com (Martin Buchholz) Date: Tue, 20 Apr 2010 00:02:16 -0700 Subject: Numerical error on native float access In-Reply-To: <4BCA3837.90906@gmx.de> References: <4BCA3837.90906@gmx.de> Message-ID: On Sat, Apr 17, 2010 at 15:37, Ulf Zibis wrote: > There seems to be a bug in Float.intBitsToFloat(int) and/or > Float.floatToRawIntBits(float) and/or sun.misc.Unsafe.getInt/Float. > > If I replace > ? ? ? ?return > Float.intBitsToFloat(Integer.reverseBytes(unsafe.getInt(offset))); > with > ? ? ? ?return reverseBytes(unsafe.getFloat(offset)); It looks like you are accessing a float value using getInt, which is breaking the rules. In any case, swapping bytes of floating point values is something no one is likely to care about. At least, I'm finding it hard to care. Martin From Ulf.Zibis at gmx.de Tue Apr 20 05:12:34 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 20 Apr 2010 14:12:34 +0200 Subject: Numerical error on native float access In-Reply-To: References: <4BCA3837.90906@gmx.de> Message-ID: <4BCD9A32.3070504@gmx.de> Am 20.04.2010 09:02, schrieb Martin Buchholz: > On Sat, Apr 17, 2010 at 15:37, Ulf Zibis wrote: > >> There seems to be a bug in Float.intBitsToFloat(int) and/or >> Float.floatToRawIntBits(float) and/or sun.misc.Unsafe.getInt/Float. >> >> If I replace >> return >> Float.intBitsToFloat(Integer.reverseBytes(unsafe.getInt(offset))); >> with >> return reverseBytes(unsafe.getFloat(offset)); >> > It looks like you are accessing a float value using getInt, > Contrary, DirectFloat/DoubleBufferS#get/put() currently use get/putInt/Long. My attempt is, to avoid this by shifting the swap mechanics to Unsafe class. > which is breaking the rules. > > In any case, swapping bytes of floating point values is > something no one is likely to care about. > At least, I'm finding it hard to care. Sounds not good. I think we need a native byte swapping for float/double types to ensure correctness on little-endian machines for DirectFloat/DoubleBufferS#get/put(). What you think? -Ulf From pjenvey at underboss.org Sat Apr 24 18:45:13 2010 From: pjenvey at underboss.org (Philip Jenvey) Date: Sat, 24 Apr 2010 18:45:13 -0700 Subject: Unix paths as bytes In-Reply-To: <49FEC84C.5020400@sun.com> References: <8A76422D-80E7-4266-A2D4-11CA6097B9C6@underboss.org> <1ccfd1c10905031702l8e9a805l7205d01a0cb27e61@mail.gmail.com> <49FEC84C.5020400@sun.com> Message-ID: On May 1, 2009, at 6:03 PM, Philip Jenvey wrote: > UnixPath solves the issue of java.io.File treating unix paths as Strings (e.g. http://bugs.sun.com/view_bug.do?bug_id=4899439 ) -- but AFAICT not for all situations on the JVM. > > For example in Jython, paths are represented by Strings, not wrapper objects > Can we allow access to UnixPath's byte representation of path names and the reverse: the ability to create a Path object from said bytes? On May 4, 2009, at 3:49 AM, Alan Bateman wrote: > It would be easy to expose the bytes with something like toString(CharsetDecoder) and a corresponding FileSystem.getPath(String,CharsetEncoder) for import but I wouldn't expect it would be used by regular applications. Hi Alan, To revisit this issue I brought up a year ago, Jython could still use efficient access to the underlying bytes of a Path object. The additional API you proposed would do it -- I can work up a patch for this if you're up for considering its inclusion. For Windows I suppose the extra encoder/decoder arguments would just be ignored -- Philip Jenvey From Ulf.Zibis at gmx.de Sun Apr 25 06:22:37 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 25 Apr 2010 15:22:37 +0200 Subject: review request (S) - Spp tool fails on embedded vars containing '_' and text containing '=+{|' etc. Message-ID: <4BD4421D.6020601@gmx.de> Sherman, as you originally coded the Spp tool, please file a bug and review my changes (see attachment). The patch does fine on "make all", but I only did "jtr char" for test. Thanks, -Ulf -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: spp Url: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100425/3e3f0f36/attachment.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: spp1 Url: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20100425/3e3f0f36/attachment-0001.ksh