Daniel Spiewak schrieb: > Here's the problem with that: it requires everyone to be using this > "JVM Server" on their machine. JVM langs are so great partially > because they run everywhere there's a JVM (which is practically > everywhere). I can't think of anyone that has nailgun installed. But > even assuming you just packaged Nailgun with the main language distro, > there's still the problem of starting it as a service. Not everyone > is going to *want* to have a persistent JVM instance running in the > background. And chances are, those who do want it know enough to be > concerned about the implications of things like static variables, UI > dispatch thread, etc.
if we forgett about UI, static variabels and such... I had a different thought... let us say I use the myLang command (doesn't exist) to start an application. let us also say, that the myLang command checks for the NailGun server, if not started it starts a new one and attaches itself to that server. If here is already a server running, then it simply attaches itself to the server. If the myLang command is completed, then the server stays, but not till the end of time, let us say just for another minute or so. If in that time no other myLang command has taken place, then the server disposes itself from memory. If there is another myLang command executed during that timeout period, then the server stays until the new command is completed and starts the waits for the timeout again. The advantage are: * memory is not polluted by a unused resident JVM all the time * multiple scripts running at the same time can still take advantage of the server and probably save some memory * you may get a penalty for the first script startup, but all further scripts started before the timeout won't have that penalty I also think that static variables are a solvable problem. The UI dispatch thread is a bigger problem in my eyes, it would not be very nice to have one application blocking all UIs. [...] > Honestly I don't even know if a project is already doing this, but I > think it's a thought worth considering. There are innumerable static > analysis techniques for examining code to determine dependencies and > internal requirements on the fly. Given that this sort of analysis > would be running at (or immediately before) the actual execution of > the code, we would actually have a valid runtime environment to work > with. Thus, in all but some very odd cases, the dynamic nature of > languages like Ruby, Groovy, Python and so on wouldn't pose too much > of an issue. The idea being, until the whole environment is > completely loaded and initialized, only load things bit-by-bit as > required to execute the code *right now*. For implementations which > support JITing (like JRuby and Groovy), this would be the last thing > loaded and more-or-less disabled until the entire environment is > available. ok, then for Groovy... given that the code is not yet compiled Groovy needs to laod a huge amount of classes for the compiler and for the AST. Then the code is executed and it needs to load several runtime classes and needs to create some MetaClasses.... That all happens on demand. If you have precompiled code, then the compiler won't be loaded unless you need it somewhen in your code. Groovy does not create a MetaClass for a class that is not needed. An so on. Maybe something could be done by splitting some classes, but that won't give a huge amount of speed anymore. bye blackdrag -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ http://www.g2one.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
