Hypothetical : What restrictions will I need to add to Java so that I can remove its GC?

This is a hypothetical, yet very technically precise question I'm trying to ask all the compiler/static analysis programmers.

I'm trying to understand the extent of prohibitive features I would need to add to the language such that it is still a Java program, i.e. it could run inside any JVM with the same semantic meaning (i.e. the GC or no GC doesn't change the semantics), and then also run in my special scenario.

I'm asking this because I've a developer in a large team (>200 people) developing a pretty large web application, and it's all dependency injection based. I've been a C++ developer all my life, and this change (to java) has been surprisingly poor, except for the silver lining of dependency injection stuff and peculiar thing that happens in the codebase I work on.

In this particular codebase, they use the java compiler, and then they have another sort-of compiler that annotates the source code with ownership details of the objects being passed from function to function.

foo(someType a); // @_@_move_semantic_@_@

I've modified the notation (for obvious reasons), but it does it after every commit, a few minutes later. Our application takes a few minutes to compiler by javac.

I then inquired about this and was told that the previous engineering lead developer was this guy who had a vision of removing the GC from their codebase, which never materialized.

I understand what he was doing was "Escape Analysis", but beyond that I'm sure some restrictions need to be added to the code? What would they be?

Special method names? All exits from a function require some reference count call?

I'm looking for a pretty precise or theoretical treatise ... or pointers to some papers or research (I know about the Mercury language, but it's only stack based)