3 ms·
> Unfortunately, you do pay a fairly large price for bytebuffers, even off-heap ones. I'd disagree. Heap based bytebuffers - I don't consider them interesting,
by xxs 3y ago
> Unfortunately, you do pay a fairly large price for bytebuffers, even off-heap ones.
I'd disagree. Heap based bytebuffers - I don't consider them interesting, they are just byte arrays. The direct ones suffer from unmapping (munmap on linux) - it's a slow process that has to flush the TLB. So the only sane way to use them allocate once/reuse. Anything else I'd consider a programmer error.
mmap on large files indeed does suck (a bit) w/ ByteBuffers as it'd require an array of them.
Personally I have been using direct buffer since 1.4, so I guess I am also quite used to them as well.
- marginalia_nu 3y agoRight, I'm not talking about mapping or allocation costs or anything surrounding the access, just the impact of addressing off heap bytebuffers them seems quite a bit slower than what you get with the new foreign memory API... for whatever reason.
- xxs 3y agoYou mean using directBuffers in java - that could be, if the JIT fails to remove the bound checks. It should never be an issue in native code, of course. But yes - it's possible that it happens with Java code. In that case you'd need print assembly and looking at the generated code. Some libraries have 'switched' to straight unsafe use (which has no bound checks, of course), so there is that.
- bitcharmer 3y agoThis makes zero sense. I'll believe it when someone proves that (warmed up) direct byte buffer access is slower than Unsafe.
- marginalia_nu 3y agoI'm not comparing against Unsafe, this is JDK21. No unsafe anymore.