if you would just post the source code...
|
Correct me if I am wrong about the title, but I had an idea that, if someone was to use a Map/HashMap like this:
and they store a value like:Code:public static Map<String, Object> field_storage = new HashMap<>();
It would possibly use more memory by keeping it there forever.Code:field_storage.put("anInt1", 1);
My idea, is that if you store the value for the key, then declare an actual field that will carry the value of the key, then remove the key to free up memory, then when you actually need it, you may either use it, or restore it then use it then completely remove it, and null the actual field, to free up memory; but my idea is more likely useful when you're not going to use it anymore.
If I am wrong, please reply, if you think my idea can be done right, please reply with some of your thoughts about it.
I can't prove this, but I do have a sloppy video that I made of a comparison. Please if you watch, ignore the part of the title saying "node". I don't know exactly what a node is.
Here's the video:
if you would just post the source code...
what....
first of all you really need to stop using so many spaces and remove the comments like "todo: code application logic here" this no-brainer shit. condense your if statements, seriously. by stop using so many spaces i mean: if (something == something), HashMap<String, Object> str = new HashMap<String, Object>();
=Code:stage == 1 || stage == 2 || stage == 3 || stage == 4 || stage == 5 || stage == 6 || stage == 7 || stage == 8 || stage == 9
go learn what a hashmap is and how to use itCode:stage > 0 && stage < 10
Basically to simplify, what Mayhem believes is something along these lines:
will save memory, because while the MyBigObject is referenced in the method, it is not in the map, and vice-versa.Code:Map<Integer, MyBigObject> map = new HashMap<>(); void doSomethingWith(int key) { MyBigObject test = map.get(key); map.remove(key); // do some work with this 'test' value map.put(key, test); }
However, this isn't the case. The Map and the local variable both refer to the same MyBigObject in memory, they aren't copies (@Mayhem, read about pointers/references/the heap.)
OK, you might save a bit from losing the Map.Entry object internally, but this isn't really a significant saving and this just leads to more processing work to do. Any differences you get are, in most cases, probably going to be on the order of bytes, not kilobytes or megabytes.
oh wow, that's what he was trying to do. the second pastebin threw me off so much. you might (depending on the actual implementation, i don't know it off the top of my head) be wrong about the map.entry instance though... if you "remove" the key/value from the map, you don't "lose" the map.entry instance. you know more than i do so i'm not going to explain garbage collection lol. the first map.entry instance will probably still be in memory by the time you put your object back into the map. probably will create two instances instead of the previous 1. so you're actually using (potentially a lot if you do it for every entry in quick succession) more memory than you would have if you just left it in the map, did some work on it, then removed it. of course garbage collection would clean it all up but my point is that it's not doing anything but creating more problems (more memory usage, need to gc earlier)
also, since i don't have anything else to contribute to the main subject: when you remove something from anything that implements the map interface, the remove method returns the object that you are removing. so you don't need to call get then remove, just Object got = someMap.remove(key);
i don't understand why people can't just research how memory in java works and then see if their "memory-saving" ideas still make sense.
Why do you speculate to how the jvm handles dead objects and then state you don't understand why people don't do their research first?
Once all references to the key in the map.entry object are lost(edit: typo), it's essentially dead. And the jvm will not check and re-awaken a dead object.
imprying (lolcensor) i was even coming close to saying that.
i said that i don't know how hashmap is implemented, so i can't speak as if i do (this is just me saying that i'm not actually stating facts, so people can't be mad at me if i'm wrong because i never claimed that i was right). i can only guess that it does in fact completely remove all references to the object it created internally. this has nothing to do with my understanding of how memory works in the jvm at all.
« Previous Thread | Next Thread » |
Thread Information |
Users Browsing this ThreadThere are currently 1 users browsing this thread. (0 members and 1 guests) |