In answer to the question directly: yes, absolutely.
If you need to manage it that closely, yes, you can. Allocators (in themselves) aren't yet stable, but, like in C++ and other languages (before they became normal), you can make it work. (Note: In C++ and other languages people, myself included, still use workarounds because of interface concerns).
In answer to the context driven question, which I interpret as "can it help me solve the problem": maybe.
Without knowing the specifics of the issue, there may be other solutions. The two that come to mind quickly are:
- swapping/paging the data away (get a cheap USB drive if you're concerned about your drive, or you don't want to write to it constantly for space/capacity concerns);
- Using memory pools.
If you're interested in learning Rust anyway, both of those are completely viable (and serde makes reading and writing to disk easy if you don't want to roll your own for the sake of learning, or for the sake of raw speed).
Contextually, it's worth noting the JVM has some overhead (by necessity/design), and that's fine. mbrubeck already commented on the garbage collection issue, but there's a bit more to it (and it's not really worth going into here), and it can add up (depending on what you're doing). But in that overhead comes the flexibility to write code in a way you're used to writing it without certain concerns that arise in C, C++, and Rust. Rust will seem like it has an undue number of sharp edges when you start, so if this is something extremely complex internally, make sure you break it down in a modular way so you can approach it without getting frustrated (I know, basic programming advice, but it bears repeating because Rust can be infuriating at times).
The other thing is that if you decide to go the "my own allocator" route, don't start there. If you're worried you'll need it later, that's fine, but consider a reset() method, and pooling it instead. Since the faux-allocator method you'll see used a lot is Vec::<u8>::with_capacity (it's what I use), save yourself the potential headache and just use Vec::<Object>::with_capacity, add something like is_valid() and use reset() when you're done with it (so it can be re-used). The end result is, for your purposes, the same, and there's no real reason to go insane trying to resolve a potential memory leak caused by layers of unsafe code. (If you're wondering why I'm suggesting it that way it's because it may be as small, and as simple, as the JVM overhead being the issue; it may be far more complex, in which case your initial allocator design may be problematic.)