- You'd have to ensure that your large data structure gets allocated entirely within the special region. That's simple enough if all you have is a big array, but it gets more complicated if you've got something like a map of strings. Each map cell and each string would need to get allocated in the special region, and all of the types involved would need new APIs to make that happen.
- You'd have to ensure that data structures in your special region never hold references to anything outside. Since the whole point of the region is that the GC doesn't scan it, nothing in the region will be able to keep anything outside the region alive. Any external references could easily become dangling pointers to freed memory, which is the sort of security vulnerability that GC itself was designed to prevent.
All of this is doable in theory, but it's sufficiently difficult, and it comes with sufficiently many downsides, that it makes more sense for a project with these performance needs to just use C or Rust or something.
You can treat external references as GC roots.
Which brings you back to doing an expensive scan of the large off-heap data structure you were trying to avoid.
[1] https://docs.oracle.com/javase/9/gctuning/garbage-first-garb...
That real business problem is Java generates boat load of garbage so GC needs a lot more performance tuning to make application run normal.
As you fight your language, you're GC avoidance system will become larger and larger. At some point you might re-evaluate your latency requirements, your architecture, and which are the right tools for the job.
Just pool could've mitigated your problem at least partially, is what I'm saying.
Probably, yeah. But the Golang team would never add such a feature because of their philosophy of keeping the language simple.