Alex Tkachman schrieb:

I guess that means that the web application loader can not thrown away unless the deamon here stops, because the thread class itself is loaded by that loader.

I remember we had some "on access" action to remove the stalled entries in 1.5.x. How bad would it impact performance if we do it the same way again? I mean calling poll on each modification instead of remove here.

yes, I see it the same way

I agree

terminatingit without recreation is bad.... how do you know we still need it? and is that faster than doing polling on our own? Also with a fixed time you still have the same problem on a high load server. The higher the load, the shorter the time would have to be to avoid the problem, but that will not happen, because you have no way to know the load... also what time values would be good?

No... I think we have these profiles:

a) 1 thread, runniing for a while with low memory requirement and then die, one runtime only, runs a short time -> small application such as benchmark b) multiple threads, one runtime only, probably long running -> normal application c) high load, one thread per request, multiple requests at the same time, multiple runtimes, long running probably -> web application d) many runtimes, low load -> web development

for profile (a) we would probably not need to remove any meta classes.. also no thread local stuff would be needed in this case

for (b) we need to, because the application is long running. Many other languages spawn a completely new runtime per thread... I won't suggest that for Groovy, because it is so near Java, and we would like the threads to be able to communicate to each other. On the other hand we kind of do that already with many threadlocals here and there... making one partial runtime per thread would be a small step then.. Anyway, this profileis what 1.6 targets atm

for (c)... would it work on a per request basis, like a php script for example, then we would have nearly the same situation as in (a). But we are in the Java world, meaning the web application sticks around, even if there is one thread per request. The web application may stay around for a while... this is not the situation of the problem I think

(d) is our problem atm, because of the redeploys we get a higher number of runtimes, where most of them are inactive. Of course only the active ones can get a high load, but the inactive ones have to release their memory while they are inactive

for a we could say we start memory management after a specific time only... in case of (a) it is unlikely that many meta classes are created... so even bettter would be to start memory management only after we got a minimum number of meta classes. That is also compatible with (b). Maybe some benchmarks will run just another little bit faster with this if they stay in the area where no memory management is needed... and I guess most benchmarks from the shootout are of that kind.

for (c) and (d) the question is if on high load where all processing power is used if there is any difference between the thread using remove() or us polling per request. If the processor is not on high load, then the Thread version we have now should be the best one, because it utalizes unused processing power.

Well... what I now suggest is quite complicated to implement... and it is maybe just a stupid idea... but what would be if we had different profiles and we could switch between them, maybe have an option to force one such a profile? Basically it is only a question of abstraction, but abstraction takes a little performance away too..

So basically we would maybe have a profile which does not care how many meta classes are there and does not remove them. Then if a certain amount of meta classes is reached we switch to the next profile, which is either using poll() or remove(), maybe with the thread based remove as default and an application can set the polling. Frankly I would use polling as default and let command line programs (or GroovyMain for example) use a flag to set the other profile. Because in that case we assumein general, that we will be used as library, meaning we should not spawn deamon threads. When used from the command line, we know we are allowed to do that, since there will be only one runtime anyway and we are starting the application by ourselfs too. That would automatically and without any configuration solve the problem for glassfish for example too. We could maybe even say that once a groovy generated, main method is called and a certain property/flag is not set yet, that we assume we are in application mode.

At last if there are no other surprises.

Sorry for the long text ;)

bye blackdrag