GCCollect() doesn't work in a dll
BlitzMax Forums/BlitzMax Programming/GCCollect() doesn't work in a dll
| ||
| Garbage collection appears to be completely inactive when a BlitzMax program is compiled into a dll. I am running two identical programs. One is a BlitzMax application that includes the program files. The other is a BlitzPlus program that calls a BlitzMax dll. Whether the GC mode is set to 1 or 2, the memory usage increases quickly and continually. When GC mode is set to 2, the GCCollect() command always returns 0. I presume gc mode 1 probably calls GCCollect() every time the Flip() command is called, which my program does not use. |
| ||
| Hi leadwerks - Haven't tried making a Max dll, and I doubt you'll get any support from BRL as Max dlls are unofficial, but I can confirm a similar issue when writing a callback routine and having a 3rd party dll call it. Repeatedly crashed until I created a version that didn't require garbage collection. This was a while back in an old 'flushmem' version of Max. |
| ||
| BM DLL Support is currently in testing. But it makes sense that the GC is disabled on a DLL to prevent interference with external data, which is what you operate on most of the time within the DLL. don't think you want to get GC:Setmembit error on DLL, do you? ^^ |
| ||
| I don't see why a dll wouldn't be able to clean up its own objects just like an exe does. My dll just wraps engines commands so that an external program can call them. I understand dll support is currently experimental, but I have faith they'll get this cleaned up in the near future. BlitzMax has really impressed me so far, and I think it was designed right from the ground up. |
| ||
Well off the top of my head, I'm thinking..Type Thing End Type A=New Thing B=A If you write that code in BlitzMax, it knows you just made another reference to the "Thing". But if you do that in another language, how can BlitzMax keep count of the references? |
| ||
| I don't expect BlitzMax to keep track of an external program's variables. I still store the objects in internal lists, just like if it was a regular BlitzMax program. I don't see a conflict. I wouldn't expect BlitzMax to be able to create an object, return it to the main program, and still store it without me adding the object to an internal list or variable somewhere. When the program calls this function, the object is stored in a list, so BlitzMax won't delete it (and so the dll can handle internal routines and cycle through all the objects): Function CreateThing:Int() thing:TThing=new TThing thing.handle=HandleFromObject(thing) thing.link=TThing.list.addfirst(thing) return thing.handle EndFunction If I did this, I would EXPECT BlitzMax to delete the object: Function CreateThing:Int() thing:TThing=new TThing thing.handle=HandleFromObject(thing) return thing.handle EndFunction When the program wants to free the object, it does this: Function FreeThing(HThing) thing:TThing=TThing(HandleToObject(HThing)) If thing RemoveLink thing.link MemFree thing.handle Else Notify "Thing does not exist." Endif EndFunction I don't see a problem. It works just like in Blitz3D. |
| ||
| Oh I completely agree. I should have been more clear. I'm not suggesting that what you're asking for is difficult, or awkward, I'm just thinking that it might be for fear of people doing what I demonstrated above that they may have disabled automatic gargage collection for now. Probably just until DLL's are officially supported. |
| ||
| MemFree thing.handle????? I'm pretty sure handles are integer hash keys not memory addresses! |
| ||
| You have to use MemFree on object handles, correct?: handle:Int=HandleFromObject(object) MemFree handle Because I am using the handles so often, my root type just automatically gets its own handle and stores it in a field. |
| ||
| You have to use MemFree on object handles, correct?: No, you Release them (that's it's only purpose in life). |
| ||
| Ah, I even had Release in my code. I just typed it wrong here. |
| ||
| And you are using GCEnter with all your public functions? Maybe you could try a GCCollect from a simple public function that doesn't have GCEnter and call that from your main program. Fredborg I think is the man to talk to. |
| ||
| The docs for GCEnter just says not to use it(?). I call GCCollect() in my UpdateWorld() function, which is getting called...it just returns 0, as memory usage builds and builds. This only happens as a dll, not an exe. I emailed Fredborg. |
| ||
| Fredborg replied. I added GCEnter() to the start of all exposed functions, and it works perfectly now. Thanks! I sent an email to BRL about a dll license, so please just get back to me when you guys have time. BlitzMax is really awesome. |
   |