qiemem
commented
5 years ago It turns out this is due, in fact, to generated classes (though child models that use extensions may have the same problem. Tracing class loading shows that each child model uses an independent (but identical) set of generated classes. There are a couple possible solutions here:
- Reuse generated classes between models. The generator is not at all built for the generated classes to be reused right now, but it should technically possible. That said, it would probably be a good bit of work.
- Reuse the complete compilation results between different instances of the same model. This would be the ideal solution. However, there are a number of problems. Right now,
Instructions, including generated ones, are both stateful and dependent on the workspace. This means that either they would have to be cloned between models (which defeats some of the point over the first solution) or the stateful/workspace dependent nature of them would have to be removed. The latter shouldn't be too complicated, but it would be a huge effort, touching virtually the entire NetLogo compiler and engine, and completely break every extension. The other huge problem is that extensions cannot be shared, as some make use mutable, static state. - Disable the generator for child models. This is a four line change to LevelSpace (though it involves mutating a system property, which could get weird if multiple models attempt to do it simultaneously). The downside is that, theoretically, the child models would run slower. However, in practice, I found that they ran faster, which I have absolutely no explanation for.
Given the above, I'm going to go for disabling the generator for child models. It's just so much simpler than the other solutions, and requires no modification to NetLogo itself. It's also not even clear that the other solutions would have any benefit over disabling the generator given that I've observed no performance hit.
I've been running out of compressed class pointer space when doing big behaviorspace runs with a large number of child models (500+). A workaround is to just do
-XX:-UseCompressedClassPointers, but we probably shouldn't be running out in the first place. Need to look into why we're creating so many classes.One thought; the child model uses an extension. Maybe because the child models extensions get their own class loader, it's just loading enough copies of those classes to overwhelm it. That seems weird to me though.
It could also just be generated classes.