And now the news from VODC Germany
in [Visual Objects]
|
Prev: Vo 2.7 Garbage Collector
Next: CRC32
From: Ginny Caughey on 16 Nov 2006 09:47 Rob, Is this a situation you've run into? I would have thought that the dynamic memory manager of .NET would swap in and out for us. -- Ginny "rob" <rob_panosh(a)asdsoftware.com> wrote in message news:1163688147.536459.103300(a)h48g2000cwc.googlegroups.com... > Don, > >> You cannot unload an assembly, no matter if it is a "normal" assembly on >> disk or a temporary assembly in memory. This is not a memory leak, at >> least not in the generally accepted definition of a "memory leak". > I understand that ... but if you keep compiling code a new assembly is > created and placed into the current appllication domain .... at some > point in time you are going to hit the wall. > > Rob > > Don Caton wrote: >> "rob" <rob_panosh(a)asdsoftware.com> wrote in message >> news:1163681686.621166.315850(a)h48g2000cwc.googlegroups.com: >> >> > Ginny, >> > >> > > Vulcan use a subset of the Vulcan compiler. Strictly speaking, I >> > > don't think >> > > what you're describing would be a memory leak though, although it >> > > might be >> > It's very simple. Everytime you compile a code snippet (in memory) >> > using CodeDom it will create/load an Assembly and that assembly cannot >> > be unloaded until the Application Domain is shutdown. There are other >> > techniques with secondary application domains but I seriously doubt >> > Vulcan is taking that approach because of performance issues. >> >> Just so there's no misunderstanding... >> >> Vulcan's macro compiler does not create temporary assemblies in memory >> for macros, it creates dynamic methods which do not have the overhead of >> temporary assemblies. >> >> Regarding temporary assemblies, while it is true that they cannot >> currently be unloaded from an application domain, this is how things >> work by design. It has nothing to do with a CodeDom; there are several >> ways you can create a temporary assembly. >> >> You cannot unload an assembly, no matter if it is a "normal" assembly on >> disk or a temporary assembly in memory. This is not a memory leak, at >> least not in the generally accepted definition of a "memory leak". >> >> Also, you may not be aware of it but the C# (and probably all other >> language) packages in Visual Studio often create temporary assemblies in >> memory for various reasons. >> >> -- >> Don >
From: rob on 16 Nov 2006 11:02 Ginny, We have not hit the wall yet. We only compile the code when it has changed and in our application and once a user defines their code snippet it rarely changes. >>I would have thought that the dynamic memory manager of .NET would swap in and out >>for us. Has nothing to do with the dynamic memory manager. In .NET once you load a assembly (by compiling code into memory or read from disk) it cannot be unloaded until you shutdown the application domain. For example this would load 100 assemblies into the curent application domain: For x=1 TO 100 Me._compileResults = _provider.CompileAssemblyFromSource(Me._compileParameters, Me.ProductionSourceCode) Next Rob Ginny Caughey wrote: > Rob, > > Is this a situation you've run into? I would have thought that the dynamic > memory manager of .NET would swap in and out for us. > > -- > Ginny > > > "rob" <rob_panosh(a)asdsoftware.com> wrote in message > news:1163688147.536459.103300(a)h48g2000cwc.googlegroups.com... > > Don, > > > >> You cannot unload an assembly, no matter if it is a "normal" assembly on > >> disk or a temporary assembly in memory. This is not a memory leak, at > >> least not in the generally accepted definition of a "memory leak". > > I understand that ... but if you keep compiling code a new assembly is > > created and placed into the current appllication domain .... at some > > point in time you are going to hit the wall. > > > > Rob > > > > Don Caton wrote: > >> "rob" <rob_panosh(a)asdsoftware.com> wrote in message > >> news:1163681686.621166.315850(a)h48g2000cwc.googlegroups.com: > >> > >> > Ginny, > >> > > >> > > Vulcan use a subset of the Vulcan compiler. Strictly speaking, I > >> > > don't think > >> > > what you're describing would be a memory leak though, although it > >> > > might be > >> > It's very simple. Everytime you compile a code snippet (in memory) > >> > using CodeDom it will create/load an Assembly and that assembly cannot > >> > be unloaded until the Application Domain is shutdown. There are other > >> > techniques with secondary application domains but I seriously doubt > >> > Vulcan is taking that approach because of performance issues. > >> > >> Just so there's no misunderstanding... > >> > >> Vulcan's macro compiler does not create temporary assemblies in memory > >> for macros, it creates dynamic methods which do not have the overhead of > >> temporary assemblies. > >> > >> Regarding temporary assemblies, while it is true that they cannot > >> currently be unloaded from an application domain, this is how things > >> work by design. It has nothing to do with a CodeDom; there are several > >> ways you can create a temporary assembly. > >> > >> You cannot unload an assembly, no matter if it is a "normal" assembly on > >> disk or a temporary assembly in memory. This is not a memory leak, at > >> least not in the generally accepted definition of a "memory leak". > >> > >> Also, you may not be aware of it but the C# (and probably all other > >> language) packages in Visual Studio often create temporary assemblies in > >> memory for various reasons. > >> > >> -- > >> Don > >
From: Ginny Caughey on 16 Nov 2006 11:15 Rob, I understand that .NET assemblies are not unloaded once they are loaded. I just don't understand why this would be an issue assuming you have enough disk for sufficient swap space. -- Ginny "rob" <rob_panosh(a)asdsoftware.com> wrote in message news:1163692970.104797.148020(a)e3g2000cwe.googlegroups.com... > Ginny, > > We have not hit the wall yet. We only compile the code when it has > changed and in our application and once a user defines their code > snippet it rarely changes. > >>>I would have thought that the dynamic memory manager of .NET would swap >>>in and out >>for us. > Has nothing to do with the dynamic memory manager. In .NET once you > load a assembly (by compiling code into memory or read from disk) it > cannot be unloaded until you shutdown the application domain. > > For example this would load 100 assemblies into the curent application > domain: > > For x=1 TO 100 > Me._compileResults = > _provider.CompileAssemblyFromSource(Me._compileParameters, > Me.ProductionSourceCode) > Next > > Rob > > Ginny Caughey wrote: >> Rob, >> >> Is this a situation you've run into? I would have thought that the >> dynamic >> memory manager of .NET would swap in and out for us. >> >> -- >> Ginny >> >> >> "rob" <rob_panosh(a)asdsoftware.com> wrote in message >> news:1163688147.536459.103300(a)h48g2000cwc.googlegroups.com... >> > Don, >> > >> >> You cannot unload an assembly, no matter if it is a "normal" assembly >> >> on >> >> disk or a temporary assembly in memory. This is not a memory leak, at >> >> least not in the generally accepted definition of a "memory leak". >> > I understand that ... but if you keep compiling code a new assembly is >> > created and placed into the current appllication domain .... at some >> > point in time you are going to hit the wall. >> > >> > Rob >> > >> > Don Caton wrote: >> >> "rob" <rob_panosh(a)asdsoftware.com> wrote in message >> >> news:1163681686.621166.315850(a)h48g2000cwc.googlegroups.com: >> >> >> >> > Ginny, >> >> > >> >> > > Vulcan use a subset of the Vulcan compiler. Strictly speaking, I >> >> > > don't think >> >> > > what you're describing would be a memory leak though, although it >> >> > > might be >> >> > It's very simple. Everytime you compile a code snippet (in memory) >> >> > using CodeDom it will create/load an Assembly and that assembly >> >> > cannot >> >> > be unloaded until the Application Domain is shutdown. There are >> >> > other >> >> > techniques with secondary application domains but I seriously doubt >> >> > Vulcan is taking that approach because of performance issues. >> >> >> >> Just so there's no misunderstanding... >> >> >> >> Vulcan's macro compiler does not create temporary assemblies in memory >> >> for macros, it creates dynamic methods which do not have the overhead >> >> of >> >> temporary assemblies. >> >> >> >> Regarding temporary assemblies, while it is true that they cannot >> >> currently be unloaded from an application domain, this is how things >> >> work by design. It has nothing to do with a CodeDom; there are >> >> several >> >> ways you can create a temporary assembly. >> >> >> >> You cannot unload an assembly, no matter if it is a "normal" assembly >> >> on >> >> disk or a temporary assembly in memory. This is not a memory leak, at >> >> least not in the generally accepted definition of a "memory leak". >> >> >> >> Also, you may not be aware of it but the C# (and probably all other >> >> language) packages in Visual Studio often create temporary assemblies >> >> in >> >> memory for various reasons. >> >> >> >> -- >> >> Don >> > >
From: Ginny Caughey on 16 Nov 2006 11:27 Rob, If it does become a problem for you, this article looks like it provides a good technique for the situation you describe: http://www.west-wind.com/presentations/DynamicCode/DynamicCode.htm Of course it's not as easy as just using a Vulcan macro would be, but a solution nonetheless. -- Ginny "rob" <rob_panosh(a)asdsoftware.com> wrote in message news:1163692970.104797.148020(a)e3g2000cwe.googlegroups.com... > Ginny, > > We have not hit the wall yet. We only compile the code when it has > changed and in our application and once a user defines their code > snippet it rarely changes. > >>>I would have thought that the dynamic memory manager of .NET would swap >>>in and out >>for us. > Has nothing to do with the dynamic memory manager. In .NET once you > load a assembly (by compiling code into memory or read from disk) it > cannot be unloaded until you shutdown the application domain. > > For example this would load 100 assemblies into the curent application > domain: > > For x=1 TO 100 > Me._compileResults = > _provider.CompileAssemblyFromSource(Me._compileParameters, > Me.ProductionSourceCode) > Next > > Rob > > Ginny Caughey wrote: >> Rob, >> >> Is this a situation you've run into? I would have thought that the >> dynamic >> memory manager of .NET would swap in and out for us. >> >> -- >> Ginny >> >> >> "rob" <rob_panosh(a)asdsoftware.com> wrote in message >> news:1163688147.536459.103300(a)h48g2000cwc.googlegroups.com... >> > Don, >> > >> >> You cannot unload an assembly, no matter if it is a "normal" assembly >> >> on >> >> disk or a temporary assembly in memory. This is not a memory leak, at >> >> least not in the generally accepted definition of a "memory leak". >> > I understand that ... but if you keep compiling code a new assembly is >> > created and placed into the current appllication domain .... at some >> > point in time you are going to hit the wall. >> > >> > Rob >> > >> > Don Caton wrote: >> >> "rob" <rob_panosh(a)asdsoftware.com> wrote in message >> >> news:1163681686.621166.315850(a)h48g2000cwc.googlegroups.com: >> >> >> >> > Ginny, >> >> > >> >> > > Vulcan use a subset of the Vulcan compiler. Strictly speaking, I >> >> > > don't think >> >> > > what you're describing would be a memory leak though, although it >> >> > > might be >> >> > It's very simple. Everytime you compile a code snippet (in memory) >> >> > using CodeDom it will create/load an Assembly and that assembly >> >> > cannot >> >> > be unloaded until the Application Domain is shutdown. There are >> >> > other >> >> > techniques with secondary application domains but I seriously doubt >> >> > Vulcan is taking that approach because of performance issues. >> >> >> >> Just so there's no misunderstanding... >> >> >> >> Vulcan's macro compiler does not create temporary assemblies in memory >> >> for macros, it creates dynamic methods which do not have the overhead >> >> of >> >> temporary assemblies. >> >> >> >> Regarding temporary assemblies, while it is true that they cannot >> >> currently be unloaded from an application domain, this is how things >> >> work by design. It has nothing to do with a CodeDom; there are >> >> several >> >> ways you can create a temporary assembly. >> >> >> >> You cannot unload an assembly, no matter if it is a "normal" assembly >> >> on >> >> disk or a temporary assembly in memory. This is not a memory leak, at >> >> least not in the generally accepted definition of a "memory leak". >> >> >> >> Also, you may not be aware of it but the C# (and probably all other >> >> language) packages in Visual Studio often create temporary assemblies >> >> in >> >> memory for various reasons. >> >> >> >> -- >> >> Don >> > >
From: rob on 16 Nov 2006 13:54
Ginny, > http://www.west-wind.com/presentations/DynamicCode/DynamicCode.htm Of course > it's not as easy as just using a Vulcan macro would be, but a solution > nonetheless. I don't think you get it. Using your example link above try running the small code for the link you provided. I would be willing to bet you CANNOT add references to the macro code. Then at runtime add a refrence to another another .NET assembly and try to run some of it's members. Rob Ginny Caughey wrote: > Rob, > > If it does become a problem for you, this article looks like it provides a > good technique for the situation you describe: > http://www.west-wind.com/presentations/DynamicCode/DynamicCode.htm Of course > it's not as easy as just using a Vulcan macro would be, but a solution > nonetheless. > > -- > Ginny > > > "rob" <rob_panosh(a)asdsoftware.com> wrote in message > news:1163692970.104797.148020(a)e3g2000cwe.googlegroups.com... > > Ginny, > > > > We have not hit the wall yet. We only compile the code when it has > > changed and in our application and once a user defines their code > > snippet it rarely changes. > > > >>>I would have thought that the dynamic memory manager of .NET would swap > >>>in and out >>for us. > > Has nothing to do with the dynamic memory manager. In .NET once you > > load a assembly (by compiling code into memory or read from disk) it > > cannot be unloaded until you shutdown the application domain. > > > > For example this would load 100 assemblies into the curent application > > domain: > > > > For x=1 TO 100 > > Me._compileResults = > > _provider.CompileAssemblyFromSource(Me._compileParameters, > > Me.ProductionSourceCode) > > Next > > > > Rob > > > > Ginny Caughey wrote: > >> Rob, > >> > >> Is this a situation you've run into? I would have thought that the > >> dynamic > >> memory manager of .NET would swap in and out for us. > >> > >> -- > >> Ginny > >> > >> > >> "rob" <rob_panosh(a)asdsoftware.com> wrote in message > >> news:1163688147.536459.103300(a)h48g2000cwc.googlegroups.com... > >> > Don, > >> > > >> >> You cannot unload an assembly, no matter if it is a "normal" assembly > >> >> on > >> >> disk or a temporary assembly in memory. This is not a memory leak, at > >> >> least not in the generally accepted definition of a "memory leak". > >> > I understand that ... but if you keep compiling code a new assembly is > >> > created and placed into the current appllication domain .... at some > >> > point in time you are going to hit the wall. > >> > > >> > Rob > >> > > >> > Don Caton wrote: > >> >> "rob" <rob_panosh(a)asdsoftware.com> wrote in message > >> >> news:1163681686.621166.315850(a)h48g2000cwc.googlegroups.com: > >> >> > >> >> > Ginny, > >> >> > > >> >> > > Vulcan use a subset of the Vulcan compiler. Strictly speaking, I > >> >> > > don't think > >> >> > > what you're describing would be a memory leak though, although it > >> >> > > might be > >> >> > It's very simple. Everytime you compile a code snippet (in memory) > >> >> > using CodeDom it will create/load an Assembly and that assembly > >> >> > cannot > >> >> > be unloaded until the Application Domain is shutdown. There are > >> >> > other > >> >> > techniques with secondary application domains but I seriously doubt > >> >> > Vulcan is taking that approach because of performance issues. > >> >> > >> >> Just so there's no misunderstanding... > >> >> > >> >> Vulcan's macro compiler does not create temporary assemblies in memory > >> >> for macros, it creates dynamic methods which do not have the overhead > >> >> of > >> >> temporary assemblies. > >> >> > >> >> Regarding temporary assemblies, while it is true that they cannot > >> >> currently be unloaded from an application domain, this is how things > >> >> work by design. It has nothing to do with a CodeDom; there are > >> >> several > >> >> ways you can create a temporary assembly. > >> >> > >> >> You cannot unload an assembly, no matter if it is a "normal" assembly > >> >> on > >> >> disk or a temporary assembly in memory. This is not a memory leak, at > >> >> least not in the generally accepted definition of a "memory leak". > >> >> > >> >> Also, you may not be aware of it but the C# (and probably all other > >> >> language) packages in Visual Studio often create temporary assemblies > >> >> in > >> >> memory for various reasons. > >> >> > >> >> -- > >> >> Don > >> > > > |