Identifier 'ObjectEnumerator' not found
Monkey Forums/Monkey Beginners/Identifier 'ObjectEnumerator' not found
| ||
| Screenshot https://yadi.sk/i/ydsNjy3riL5FB what could be the problem? help me plz |
| ||
| problem resolved itself. But I noticed that my game is continually increasing memory on 4 KB. In addition to the text output in the program nothing (DrawText). What do you think about this? |
| ||
| And how to free up memory? List.RemoveEach and List.Clear not free downloaded memory. I dont understand for this |
| ||
| What makes you think your program does not free memory? |
| ||
| the amount of memory in task Manager |
| ||
I looked at the code in list.monkey and it seems like the references are removed the but data is not, so the garbage collector probably won't do much for you. The relevant code is in the class Node, and is this:Method Remove() #If CONFIG="debug" If _succ._pred<>Self Error "Illegal operation on removed node" #Endif _succ._pred=_pred _pred._succ = _succ End Method If you consider this for a moment, you'll see this is a linked list, and it's taking it's predecessor and successor out. It can't take itself out. Self=null is not valid. What you can do is null the data you're storing out before you remove the list item. For example, in the case of a string list, just make the string blank. Actually, I was thinking about this some more and perhaps this is a bug. I think method could null itself before it deletes its own references: Method Remove() #If CONFIG="debug" If _succ._pred<>Self Error "Illegal operation on removed node" #Endif Self._data =Null _succ._pred=_pred _pred._succ=_succ End Method However, this fails on stringlists, because you can't null strings: http://www.monkey-x.com/Community/posts.php?topic=3150&post=32880 Best bet is just to null your data before you delete it, even though it goes against the general rule stated in the monkey help which is "ignore the garbage collector". Lastly, since this does erase all references to itself I'm not sure why the GC isn't taking it out. Perhaps someone more familiar with the inner workings of the GC can comment on that. |
| ||
| Alright, I'll get this out of the way now: @bitJericho: That method you posted removes the object in question (The 'Node' object) from the list by removing all references to itself. It does this by taking the two references on either side, and "stitching them together" (Having them reference each other), thus making the original 'Node' object no longer referenced. Since it isn't referenced anywhere, it gets deleted when the garbage collector sees fit. @Aim: "But wait, there's no delete/explicit "nulling" here." - That's the point. The garbage collector takes care of it. On most targets, Monkey uses a deterministic approach to reference validation, meaning that a certain amount of time will be used every update to collect garbage. Because of this, memory usage can go up. "But, hang on", you ask, "wouldn't it be better to get rid of the internal data anyway, since it can't be referenced?" - The answer is no. That node could very well be referenced, thanks to several methods previously used, meaning you could corrupt routines using the node elsewhere (Even if the links associated are undefined). The standard 'Node' classes are usually "read-only", using properties to achieve this. This means it's simple enough to delegate them, and not lose sleep over it. So, the real question is: "What's up with the 'String' / 'Object' / whatever it was referencing?" - That element will be removed automatically by the garbage collector using reference counting. You don't need to make a "blank" 'String', you don't need to set the reference to 'Null', it'll be taken care of when the GC gets to it. There are times when using large resources and native functionality when manually discarding is beneficial, but those situations should be as controlled as possible. Monkey (MX2 may fix this) doesn't have destructors, so this is the best option we have. Okay, so what's up with the Task Manager? Nothing, for the most part. Things are garbage collected slowly, but in most cases, Monkey will reduce the memory consumption. The memory usage in the Task Manager on Windows is also a bit problematic. You see, the memory usage of a program isn't always the actual usage. On x86 and x64, you have virtual memory, which is handled at user-level (Where your code runs), that is separated into "pages". Pages are uniform chunks of memory that get represented in actual RAM as the operating system (Heap) sees fit. Basically, on the CPU (These days), your hardware would perform address translation. So, even though your pointers (Or in this case, references) describe "real memory", that address still gets translated into the real address space. Windows uses what's called a working-set, this is system managed (Unless manually changed), and it basically dictates what pages your program is given. For best possible performance, your OS tries to delegate as many pages as it can within reason. When a program uses a lot of allocations (Uses of 'New'), the OS is more likely to statically give you a lot of pages. If your program doesn't have a lot of pages, then when you make a new allocation, it could mean the system will stall. By stall, I mean it'll freeze, reorder pages to be best represented in cache, including reordering other programs' pages, then continue. This is usually described as a page-miss (Or similar), where pages need to be managed by the OS. This also includes loading to and from your page file. Just think of a page file as a table of pages and their contents, which can be streamed to and from your hard drive or SSD. That should give you a rough idea of why Windows goes crazy about memory usage of garbage collected programs. The numbers are accurate, it's just that calling 'free', 'delete' (Or anything else like that) isn't necessarily going to help, due to the predictive nature of heaps. That being said, Windows is usually pretty good about reducing page allocation. But it's been notorious for bad paging when it comes to disk activity, and stalling the entire system trying to reorganize itself. That was a VERY basic explanation about paging, but it's the basic concept. Things get collected, but that doesn't mean Windows knows what's going on. Just realize that if your program's using a lot of memory, and you don't have gigantic buffers, Windows can probably reduce your working set to something reasonable at a later point. For more information on Monkey's garbage collection, you can view some of my posts here (And beyond). |
| ||
| Yes, i have noticed a sharp drop in memory consumption. However, the total amount of memory is still more. I understand this problem Windows. Thank you all for the answers. And excuse me for my English, I use online translator :) |
   |