查找Java字节数组的缓存行的开头

时间:2018-08-02 15:12:14

标签: java performance bloom-filter

对于高性能的阻塞布隆过滤器,我想将数据对齐到高速缓存行。 (我知道用C进行这样的技巧比较容易,但是我想使用Java。)

我确实有解决方案,但是我不确定这是否正确,或者是否有更好的方法。我的解决方案尝试使用以下算法找到缓存行的起点:

  • 对于每个可能的偏移量o(0..63;我假设缓存行长度为64)
  • 启动一个从data [o]读取并将其写入data [o + 8]的线程
  • 在主线程中,将'1'写入data [o],然后等待直到在data [o + 8]中结束(因此请等待另一个线程)
  • 重复那个

然后,测量这有多快,基本上是一个100万个循环(在每个线程中)有多少增量。我的逻辑是,如果数据位于不同的缓存行中,则会变慢。

这是我的代码:

public static void main(String... args) {
    for(int i=0; i<20; i++) {
        int size = (int) (1000 + Math.random() * 1000);
        byte[] data = new byte[size];
        int cacheLineOffset = getCacheLineOffset(data);
        System.out.println("offset: " + cacheLineOffset);
    }
}

private static int getCacheLineOffset(byte[] data) {
    for (int i = 0; i < 10; i++) {
        int x = tryGetCacheLineOffset(data, i + 3);
        if (x != -1) {
            return x;
        }
    }
    System.out.println("Cache line start not found");
    return 0;
}

private static int tryGetCacheLineOffset(byte[] data, int testCount) {
    // assume synchronization between two threads is faster(?)
    // if each thread works on the same cache line
    int[] counters = new int[64];
    int testOffset = 8;
    for (int test = 0; test < testCount; test++) {
        for (int offset = 0; offset < 64; offset++) {
            final int o = offset;
            final Semaphore sema = new Semaphore(0);
            Thread t = new Thread() {
                public void run() {
                    try {
                        sema.acquire();
                    } catch (InterruptedException e) {
                        throw new RuntimeException(e);
                    }
                    for (int i = 0; i < 1000000; i++) {
                        data[o + testOffset] = data[o];
                    }
                }
            };
            t.start();
            sema.release();
            data[o] = 1;
            int counter = 0;
            byte waitfor = 1;
            for (int i = 0; i < 1000000; i++) {
                byte x = data[o + testOffset];
                if (x == waitfor) {
                    data[o]++;
                    counter++;
                    waitfor++;
                }
            }
            try {
                t.join();
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            counters[offset] += counter;
        }
    }
    Arrays.fill(data, 0, testOffset + 64, (byte) 0);
    int low = Integer.MAX_VALUE, high = Integer.MIN_VALUE;
    for (int i = 0; i < 64; i++) {
        // average of 3
        int avg3 = (counters[(i - 1 + 64) % 64] + counters[i] + counters[(i + 1) % 64]) / 3;
        low = Math.min(low, avg3);
        high = Math.max(high, avg3);
    }
    if (low * 1.1 > high) {
        // no significant difference between low and high
        return -1;
    }
    int lowCount = 0;
    boolean[] isLow = new boolean[64];
    for (int i = 0; i < 64; i++) {
        if (counters[i] < (low + high) / 2) {
            isLow[i] = true;
            lowCount++;
        }
    }
    if (lowCount != 8) {
        // unclear
        return -1;
    }
    for (int i = 0; i < 64; i++) {
        if (isLow[(i - 1 + 64) % 64] && !isLow[i]) {
            return i;
        }
    }
    return -1;
}

它打印(示例):

offset: 16
offset: 24
offset: 0
offset: 40
offset: 40
offset: 8
offset: 24
offset: 40
...

因此Java中的数组似乎对齐为8个字节。

2 个答案:

答案 0 :(得分:2)

您知道GC可以移动对象...因此,完全对齐的阵列以后可能会对齐。

我会尝试ByteBuffer;我想,直接的页面会对齐很多(到页面边界)。

不安全的地址可以提供给您,使用JNI,您可以固定一个数组。

答案 1 :(得分:2)

第一件事-Java中的一切是8字节对齐的,而不仅仅是数组。有一个Java Object Layout可以使用的工具。这里的小事(不相关,但相关)-在java-9 String中内部存储为byte[],以缩小LATIN-1的空间,因为一切都是对齐8个字节后,增加了一个字段coderbyte,而没有使字符串的任何实例变大-间隙足够大以适合该字节。

您认为对齐的对象将更快地访问的整个想法是正确的。当多个线程尝试访问该数据(也称为false-sharing)时,这一点要明显得多(但我敢打赌,您知道这一点)。顺便说一句,Unsafe中有一些方法可以向您显示对象地址,但是由于GC可以移动这些对象地址,因此对于您的要求来说这没用。

您会not be the first one尝试克服这一问题。不幸的是,如果您阅读该博客条目-您将看到即使是非常有经验的开发人员(我佩服)也无法做到这一点。众所周知,VM可以聪明地删除某些地方可能需要的检查和代码,尤其是当JIT C2启动时。

您真正想要的是:

jdk.internal.vm.annotation.Contended

注释。这是确保缓存行对齐的 only 方法。如果您真的想阅读所有其他可以完成的“技巧”,那么您要找的是Alekesy Shipilev's个例子。