And SVR4 and SCO binaries too for that matter.
The idea that your kernel can only give you one syscall-API is so 1990-ish.
If you're talking enterprise use, sure, some app servers might need more than a few GB, but that's a memory problem, not strictly a bitness problem.
One program would spin up lots of threads, each with a 1MB stack, which was hardly used. It'd die on 32bit even with no real memory pressure.
Also, 32bit is less likely to get as much testing for server apps.
The only my wish for FreeBSD is some easy way to do pkg install $PKG --and-run-it-in-jail=jail22 --thxbye
Is now a good time to explain why SysV shared memory syscalls were never wrapped and are thus shared across all jails in FreeBSD? :-)
And, of course, you know much better what would happen to CPU caches and I/O context switching in a host OS under even a moderate load.)
Update:
Dear anonymous down-voters, I ran a FreeBSD Jail-based hosting in production for years in 2000s, while you, probably, didn't even finished a secondary school.))
Jails are not comparable to Docker. Jails are the container technology, like LXC and OpenVZ, which Linux has had for almost a decade.
Now, could you elaborate how Docker is not a "container technology".
What Docker provides is the level above - the layered images, repositories, automated services discovery, etc - which LXC/Jails/etc don't provide.
A closer equivalent in the *BSD world would probably be projects like CBSD, ezjail and such (in terms of the stack layer, not in features).
What I am trying to say is that chrooted envs for process segregation (like running a separate mysql instance) is not such new and exciting idea, and it has more disadvantages than benefits, at least for production use. (It is substantially slower and unpredictable due to memory access and I/O bottlenecks).
On the other hand, for 98% of Docker = "containerization" (a new shiny meme) = cool, without even a bit of understanding what LXC is.
perhaps jails need's a little boyish mustache?
also; hurrah for jails.