Investigate the possibility of using a deduplicated filesystem for running game instances

[Gamebuster19901]

Explore the feasibility of using a custom FileSystemProvider to expose deduplicated game versions as read-only filesystems.

The goal would be to let multiple game versions share a common blob store (content-addressed storage), allowing the JVM and related tools to interact with each version’s files through standard NIO APIs without requiring duplicate installations of the game on disk.

Key points to investigate:

• How feasible it is to replace or augment FileSystems.getDefault() for seamless integration.
• Performance and memory implications of mapping thousands of files virtually.
• Limitations when interacting with native libraries (System.load, etc.)
• Compare the feasibility between a pure java FileSystemProvider, FUSE based mount, and symlink approaches.
• Pros and cons of a read-only design (throwing ReadOnlyFileSystemException when a deduplicated file is modified) versus a copy-on-write system, where modified files are copied where the default file system expects it to be, and future reads reference the new version instead of the blob store.

[Gamebuster19901]

• How feasible it is to replace or augment FileSystems.getDefault() for seamless integration.

Assuming it is possible to mixin to java.io.DefaultFileSystem, replacing it with our own implementation would be trivial. The only issue is that classes from the parent classloader would still reference the original filesystem, rather than our implementation. However, deduplicated files really would only need to be accessed from knot classloader anyway, so I don't anticipate it to be much of an issue.

[Gamebuster19901]

Limitations when interacting with native libraries (System.load, etc.)

OpenJDK's System.load() calls Runtime.load0. Runtime.load0 creates a new File, which is created using FileSystems.getDefault(). Loading native libraries located in the blob store would be trivial.

[Gamebuster19901]

Compare the feasibility between a pure java FileSystemProvider, FUSE based mount, and symlink approaches.

A pure java FileSystemProvider would be the only realistic way of making this work correctly. Neither FUSE nor symlinks allow you to dynamically reference a file from multiple filesystems hierarchically (I.E. try to read from blob store filesystem, if failed, try to read from default filesystem)