At present the Java frontend walks the classpath looking for any type reference and converting any method defined on such a type. When the standard library JAR is available this results in far too much getting loaded, due to obscure references that most programs don't use-- for example, loading all of java.lang.System due to some trivial reference in a deserialization routine. To improve on this I am currently working on a simple lazy loading scheme, where all methods are initially stubbed, and then each is converted only when we find a call that may reach it (including through virtual dispatch). For example the following program currently runs out of memory when the standard library is available to parse:
import java.util.ArrayList;
public class al {
public static void main(int args) {
ArrayList<Integer> a = new ArrayList<Integer>();
a.add(args);
int i = a.get(0);
}
}
With these changes the dependencies for simple construct, add and get should hopefully be much smaller.
Note that the types are still loaded eagerly, for simplicity-- only method bodies are populated on demand.
At present the Java frontend walks the classpath looking for any type reference and converting any method defined on such a type. When the standard library JAR is available this results in far too much getting loaded, due to obscure references that most programs don't use-- for example, loading all of
java.lang.Systemdue to some trivial reference in a deserialization routine. To improve on this I am currently working on a simple lazy loading scheme, where all methods are initially stubbed, and then each is converted only when we find a call that may reach it (including through virtual dispatch). For example the following program currently runs out of memory when the standard library is available to parse:With these changes the dependencies for simple construct, add and get should hopefully be much smaller.
Note that the types are still loaded eagerly, for simplicity-- only method bodies are populated on demand.