gpt4 book ai didi

java - 内存屏障和 TLB

转载 作者:IT老高 更新时间:2023-10-28 21:16:16 25 4
gpt4 key购买 nike

内存屏障保证数据缓存是一致的。但是,它是否保证 TLB 是一致的?

我看到一个问题,即在线程之间传递 MappedByteBuffer 时,JVM(java 7 update 1)有时会因内存错误(SIGBUS、SIGSEG)而崩溃。

例如

final AtomicReference<MappedByteBuffer> mbbQueue = new AtomicReference<>();

// in a background thread.
MappedByteBuffer map = raf.map(MapMode.READ_WRITE, offset, allocationSize);
Thread.yield();
while (!inQueue.compareAndSet(null, map));


// the main thread. (more than 10x faster than using map() in the same thread)
MappedByteBuffer mbb = inQueue.getAndSet(null);

如果没有 Thread.yield(),我偶尔会在 force()、put() 和 C 的 memcpy() 中崩溃,所有这些都表明我试图非法访问内存。使用 Thread.yield() 我没有遇到问题,但这听起来不是一个可靠的解决方案。

有人遇到过这个问题吗? TLB 和内存屏障有什么保证吗?


编辑:操作系统是 Centos 5.7,我已经看到了 i7 和 Dual Xeon 机器上的行为。

我为什么要这样做?因为写入消息的平均时间为 35-100 ns,具体取决于长度,并且使用普通的 write() 并没有那么快。如果我在当前线程中进行内存映射和清理,这需要 50-130 微秒,使用后台线程来完成主线程交换缓冲区大约需要 3-5 微秒。为什么我需要交换缓冲区?因为我正在写入许多 GB 的数据,而 ByteBuffer 的大小不能超过 2 GB。

最佳答案

映射是通过 mmap64 (FileChannel.map) 完成的。当访问该地址时,将出现页面错误,内核将在那里为您读/写。在 mmap 期间不需要更新 TLB。

TLB(所有 CPU 的)在 munmap 期间未经验证,由 MappedByteBuffer 的最终确定处理,因此 munmap 成本高。

映射涉及大量同步,因此地址值不会被破坏。

你有没有机会通过 Unsafe 尝试花哨的东西?

关于java - 内存屏障和 TLB,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8325768/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com