[...] > Could you describe in some > more detail, what are "meta classes" in groovy runtime in terms of how > they are generated (lazily at runtime or ahead of runtime?), what > dependencies they can have and who is dependent on them. I assume they > are generated at runtime, since if they were accessible as class files > on the classpath of some loader, you would not have to design your own > caching/loading/defining layer (Class.forName() would do). That's still > an option if you create your own ClassLoader subclass that would use a > naming convention (say groovymeta.some.pkg.ClassName would be the name > of meta class "belonging" to some.pkg.ClassName main class) and use that > ClassLoader as the class loader for groovy apps. But that's hard to > enforce in various environments... So dynamic generation then.
a meta class in groovy is a class containing the information the runtime has about a class. That includes methods and properties (which might be added at runtime) and different other things. It is basically administrative stuff and an important element in caching. In Groovy3 a class can have more than one meta class, depending on the context the class is used in... but that is probably already more than enough detail. Important is that I don't generate classes for this at any time, the structure is represented by a bunch of classes from my runtime. It can be best compared with Class from Java Reflection. The problem I have is, that if for example Object has a ClassValue based hard reference to MetaClass (my meta class class), then there will be always a class from the groovy runtime that stays referenced, thus not allowing it to be replaced or simply unloaded. I was already wondering if I can just use a WeakReference to my MetaClass instance. But the isnstance could be collected before the runtime is not needed anymore. At least in some cases this is nor acceptable. Just to make the problem more clear... Imagine there is some kind of App-Server and it laods something that uses Groovy, and maybe it loads this not at the system level, but per application and imagine the application is loaded and unloaded several times... a meta class is a large structure with a lot of objects. I could very easily write a Groovy script for such an environment that will eat up all the memory in this new meta class system while currently it should run with some big gc runs, but still run endlessly. For for example web applications this scenario is even likely to happen. bye Jochen _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
