The garbage collector is kind of necessary to resolve circular references when freeing objects.

Ok I see. Well FWIW, for our needs It would be fine if circular references would result in memory leaks, and are considered the script programmers fault and responsibility. I assume AC could easily reported these errors at shutdown of the script engine, to provide feedback of their occurrence. (Of course they wouldn't be true leaks, as the memory would be released when the engine is deleted.)

Obviously I mean as an optional compiler flag (which basically would be the "Release on destruction" flag and no GC).

ziomau,

I've completely re-factored the way the memory management for the internal script code is handled in revision 2094. It should no longer cause any problem to rebuild the scripts like you do, as the internal script code no longer uses the garbage collector to resolve the internal circular references. Discarding the old script module is much faster, and there is no memory build-up. If your script code doesn't create any garbage collected objects at all, you will not have to run the garbage collector at any time.

audioboy77,

You're thinking like a C++ developer where the programmer has the full responsibility for making sure the program behaves well. AngelScript is not C++ in script form. I cannot assume the script writer knows what he is doing and will not accidentally cause memory leaks or circular references between objects. AngelScript is meant to provide a sand-boxed environment. The script writer should not be able to do something wrong even if he tries to (of course, this also depends on the functionality that the application exposes to the script engine).

If you prefer to put the responsibility on your script writers to make sure the scripts are well behaving, then you can easily turn off the automatic garbage collection, and just do a trivial sweep over objects in the GC. I doubt you'll have a performance problem due to that, especially since the GC is incremental, and can be executed from a background thread if desired. I will however take your suggestion to heart and consider adding a flag that completely turns off the use of GC for those who prefer that.

Yes, you're right. malloc and free are blocking. I didn't mean the "blocking" in the sense of quick operations like malloc and free, I meant "blocking" in the sense like Java's garbage collector that (used to) stop all processing until the garbage collector is finished, potentially for several seconds. (I mean no disrespect to Java developers, I'm basing my assumption on 10+ year old knowledge. I'm pretty sure Java has evolved since then )

I try to explain how AngelScript's garbage collector works in the manual. Hopefully it should answer most of your questions. Though if you do have further questions, I recommend you start a new forum post for that discussion rather than hijacking ziomau's thread .

ziomau,

I've completely re-factored the way the memory management for the internal script code is handled in revision 2094. It should no longer cause any problem to rebuild the scripts like you do, as the internal script code no longer uses the garbage collector to resolve the internal circular references. Discarding the old script module is much faster, and there is no memory build-up. If your script code doesn't create any garbage collected objects at all, you will not have to run the garbage collector at any time.

audioboy77,

You're thinking like a C++ developer where the programmer has the full responsibility for making sure the program behaves well. AngelScript is not C++ in script form. I cannot assume the script writer knows what he is doing and will not accidentally cause memory leaks or circular references between objects. AngelScript is meant to provide a sand-boxed environment. The script writer should not be able to do something wrong even if he tries to (of course, this also depends on the functionality that the application exposes to the script engine).

If you prefer to put the responsibility on your script writers to make sure the scripts are well behaving, then you can easily turn off the automatic garbage collection, and just do a trivial sweep over objects in the GC. I doubt you'll have a performance problem due to that, especially since the GC is incremental, and can be executed from a background thread if desired. I will however take your suggestion to heart and consider adding a flag that completely turns off the use of GC for those who prefer that.

Yes, you're right. malloc and free are blocking. I didn't mean the "blocking" in the sense of quick operations like malloc and free, I meant "blocking" in the sense like Java's garbage collector that (used to) stop all processing until the garbage collector is finished, potentially for several seconds. (I mean no disrespect to Java developers, I'm basing my assumption on 10+ year old knowledge. I'm pretty sure Java has evolved since then )

I try to explain how AngelScript's garbage collector works in the manual. Hopefully it should answer most of your questions. Though if you do have further questions, I recommend you start a new forum post for that discussion rather than hijacking ziomau's thread .

Hi Andreas

Thanks for the reply.

Yes I'm thinking like a C++ developer :)

Ok I will turn of GC and then call the cleanup manually, as you say this will probably have a minimal overhead, and I assume in practice will be fine for our needs. But thanks for considering the suggested flag!

I will check the manual again, and look forward to getting productive with AngelScript

Thanks

James