JDK-8080904 : ByteBuffer.get(byte[]...) fails to get the buffer content "intermittently"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P1
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2015-05-21
  • Updated: 2023-07-21
  • Resolved: 2023-07-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Resolved
Related Reports
Duplicate :  
Relates :  
Description
During  the investigation of JDK-8080803, it is noticed that the possible trigger might be the ByteBuffer.get(byte[]) fails to get the corresponding bytes from the bytebuffer, the returned byte[] does not contain the any content ("zero" in our test case).

I'm not sure if they are related, the attached test case always fails (ByteBuffer.get(byte[]) fails to get the content) after 10k+ iteration on my local 32-bit linux build (very old  machine/os). Recently I have to update the hotspot source code (2 64-bit constants) to let the hotspot build to finish, as the compiler complains the constant is out of the range of a "long" ...

http://cr.openjdk.java.net/~sherman/iso2022/hotspot

----------------------------------------

import java.nio.*;
import java.nio.charset.*;

public class Foo {

    public static void main(String[] args) throws Throwable {

        int N = Integer.parseInt(args[0]);
        CharsetEncoder enc = Charset.forName("EUC_KR").newEncoder();
        byte[] bytes = new byte[8];
        for (int i = 0; i < N; i++) {
            if (encode(enc, '\u4e00', bytes) == 2) {
                if (bytes[0] == 0 && bytes[1] == 0) {
                    throw new RuntimeException("FAILED: b[0]=" + bytes[0] + ",b[1]=" + bytes[1]);
                } else {
                    System.out.printf("[%d] 0x%x%x%n", i, bytes[0] & 0xff, bytes[1]&0xff);
                }
            }
        }
    }

    private static int encode(CharsetEncoder enc, char unicode, byte ebyte[]) {
        int index = 0;
        char        convChar[] = {unicode};
        byte        convByte[] = new byte[4];
        int         converted;

        try{
            CharBuffer cc = CharBuffer.wrap(convChar);
            ByteBuffer bb = ByteBuffer.allocate(4);
            enc.encode(cc, bb, true);
            bb.flip();
            converted = bb.remaining();
            bb.get(convByte,0,converted);
        } catch(Exception e) {
            return -1;
        }
        if (converted == 2) {
            ebyte[index++] = (byte)(convByte[0] & 0x7f);
            ebyte[index++] = (byte)(convByte[1] & 0x7f);
        }
        return converted;
    }
}
Comments
Reproduced with jdk9 b66 through jdk9 b82, gone in b83 and later. Test passes with -XX:-Inline or -XX:-DoEscapeAnalysis, so it looks like JDK-8134031 is the likely cause.
22-12-2015

ILW=incorrect return values;c2 code;none=HMH=>P1
29-05-2015

Aside: CONST64/UCONST64 macros should be used rather than direct LL/ULL suffix
22-05-2015