tag:blogger.com,1999:blog-9054609445298212106.post6149648117777244051..comments2018-10-19T00:54:01.687+10:30Comments on A Hacker's Craic: GC, finalisersNotZedhttp://www.blogger.com/profile/09469760565180198154noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-9054609445298212106.post-17501733362773126642011-10-26T22:30:03.433+10:302011-10-26T22:30:03.433+10:30Yeah i know there are some problems with it. I ju...Yeah i know there are some problems with it. I just dont want to end up with a refcounted api and completely explicit management.<br /><br />I've done some testing and it seems to work ok enough for me even if i leave it to clean up automatically. <br /><br />But i'm sure you know: one lives and learns ... so i could be completely wrong.NotZedhttps://www.blogger.com/profile/09469760565180198154noreply@blogger.comtag:blogger.com,1999:blog-9054609445298212106.post-2590291357751123292011-10-26T22:10:28.841+10:302011-10-26T22:10:28.841+10:30the problem with this is that you are correlating ...the problem with this is that you are correlating the heapsize + gc alg with native resources. It is not guaranteed that a GC will ever free an unused object. All current GCs are lazy for example.<br /><br />What makes it even worse is that a rather small object can represent a rather large native resource. In jocl for example the native resource don't have to be on the same physical device. mbienhttps://www.blogger.com/profile/13499777062253911679noreply@blogger.com