Thread: Resubmission Theory by Mayhem

Page 1 of 2 12 LastLast
Results 1 to 10 of 11
  1. #1 Resubmission Theory by Mayhem 
    Interfacing with your sister

    Streax's Avatar
    Join Date
    Jun 2009
    Posts
    2,308
    Thanks given
    784
    Thanks received
    175
    Rep Power
    229
    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:

    Code:
    public static Map<String, Object> field_storage = new HashMap<>();
    and they store a value like:

    Code:
    field_storage.put("anInt1", 1);
    It would possibly use more memory by keeping it there forever.

    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:

    Attached image
    Reply With Quote  
     

  2. #2  
    ???

    funkE's Avatar
    Join Date
    Feb 2008
    Posts
    2,612
    Thanks given
    255
    Thanks received
    989
    Rep Power
    1366
    if you would just post the source code...
    .
    Reply With Quote  
     

  3. Thankful user:


  4. #3  
    Renown Programmer

    Join Date
    Dec 2010
    Posts
    2,876
    Thanks given
    508
    Thanks received
    1,898
    Rep Power
    5000
    what....
    Reply With Quote  
     

  5. #4  
    Interfacing with your sister

    Streax's Avatar
    Join Date
    Jun 2009
    Posts
    2,308
    Thanks given
    784
    Thanks received
    175
    Rep Power
    229
    Quote Originally Posted by Supah Fly View Post
    if you would just post the source code...
    [Java] Test1 - Pastebin.com

    [Java] Test2 - Pastebin.com
    Attached image
    Reply With Quote  
     

  6. #5  
    ???

    funkE's Avatar
    Join Date
    Feb 2008
    Posts
    2,612
    Thanks given
    255
    Thanks received
    989
    Rep Power
    1366
    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
    =

    Code:
    stage > 0 && stage < 10
    go learn what a hashmap is and how to use it
    .
    Reply With Quote  
     

  7. #6  
    Valar Morghulis

    Laxika's Avatar
    Join Date
    Sep 2006
    Age
    32
    Posts
    2,813
    Thanks given
    1,804
    Thanks received
    274
    Rep Power
    2128
    You want something like this: WeakHashMap (Java Platform SE 6) or what?
    Reply With Quote  
     

  8. #7  
    Programmer, Contributor, RM and Veteran




    Join Date
    Mar 2007
    Posts
    5,147
    Thanks given
    2,656
    Thanks received
    3,731
    Rep Power
    5000
    Basically to simplify, what Mayhem believes is something along these lines:

    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);
    }
    will save memory, because while the MyBigObject is referenced in the method, it is not in the map, and vice-versa.

    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.
    .
    Reply With Quote  
     

  9. Thankful users:


  10. #8  
    ???

    funkE's Avatar
    Join Date
    Feb 2008
    Posts
    2,612
    Thanks given
    255
    Thanks received
    989
    Rep Power
    1366
    Quote Originally Posted by Graham View Post
    Basically to simplify, what Mayhem believes is something along these lines:

    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);
    }
    will save memory, because while the MyBigObject is referenced in the method, it is not in the map, and vice-versa.

    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.
    .
    Reply With Quote  
     

  11. Thankful users:


  12. #9  
    Registered Member
    tommo's Avatar
    Join Date
    Aug 2008
    Posts
    420
    Thanks given
    30
    Thanks received
    36
    Rep Power
    200
    Quote Originally Posted by Supah Fly View Post
    oh wow, that's what he was trying to do. the second pastebin through 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.
    23:06 <t4> of course, you can just reverse their wavygravy cipher to produce the public volatile boolean needed
    22:58 <t4> careful it sends bologna packets to the login servers
    22:58 <t4> very unsafe kernel flash
    Reply With Quote  
     

  13. #10  
    ???

    funkE's Avatar
    Join Date
    Feb 2008
    Posts
    2,612
    Thanks given
    255
    Thanks received
    989
    Rep Power
    1366
    Quote Originally Posted by tommo View Post
    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, 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.
    .
    Reply With Quote  
     

Page 1 of 2 12 LastLast

Thread Information
Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)


User Tag List

Similar Threads

  1. *new* project mayhem
    By Deekin in forum Advertise
    Replies: 24
    Last Post: 05-06-2010, 05:27 AM
  2. 517+ mayhem pkz
    By Tasty Noob in forum Advertise
    Replies: 7
    Last Post: 02-09-2010, 06:52 PM
  3. [317] mayhem pkz [317]
    By Tasty Noob in forum Advertise
    Replies: 3
    Last Post: 02-09-2010, 05:56 PM
  4. Guitar Mayhem
    By Full Metalst in forum Showcase
    Replies: 2
    Last Post: 06-17-2009, 01:24 PM
Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •