lxx.Tomcat 3.55 vs cs.ags.Scarlet 1.1c

Jump to navigation Jump to search
Revision as of 28 February 2012 at 00:13.
The highlighted comment was created in this revision.

lxx.Tomcat 3.55 vs cs.ags.Scarlet 1.1c

The duels between lxx.Tomcat 3.55 and cs.ags.Scarlet 1.1c are throwing OutOfMemoryErrors and crashing my clients.

I´m using the standard -Xmx512m parameter in a 64-bit Hotspot JVM (Oracle/Sun).

    MN13:50, 24 February 2012

    It's strange - i have no problems in same environment: java version "1.7.0" Java(TM) SE Runtime Environment (build 1.7.0-b147) Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)

    Can you do some more investigations (Tomcat vs Druss & Scarlet vs Druss etc. and see in which battles memory usage will higher) to detect which robot is eats memory and, if it's Tomcat. i will try to fix it

      Jdev03:35, 25 February 2012
       

      Scarlet uses lots of memory. The longer the battle the more memory used. So battles against top bots will use the most.

        Skilgannon06:53, 25 February 2012
         

        Made some tests. I set -Xmx2g, tested the pairings below twice each and tracked how much memory the JVM allocates:

        Tomcat vs Scarlet: 1,231,648k, 1,133,508k

        DrussGT vs Tomcat: 1,047,452k, 1,043,268k

        DrussGT vs Scarlet: 1,251,568k, 1,221,012k

        DrussGT vs Diamond: 869,356k, 878,216k

        Those numbers are maximum heaps. The actual used heaps are usually between 30% to 70% of those numbers.

          MN15:31, 25 February 2012
           

          So it seems both Tomcat and Scarlet use a lot of memory... hmm. I can see how a battle of one vs the other could cause problems on a memory limited machine. What are the maximum heaps used when run with -Xmx512MB ?

            Skilgannon20:24, 25 February 2012
             

            The reason Scarlet uses so much memory is it is just two bots that have been welded together. Each side manages its own information and systems.

              Chase-san22:48, 25 February 2012

              Why would that matter? My gun and movement don't really share any data. I might save on the size of a few class files they share, but that's negligible (the whole JAR file is a couple hundred kb).

              Unless there's two movements and two guns being initialized and/or processed, but I'd be surprised if that's how you guys have it setup, and it would be easy to fix.

                Voidious19:14, 27 February 2012
                 

                They both have a lot of 'structure'. ;)

                But beyond that, might just be that they are fat and unoptimizated.

                  Chase-san23:29, 27 February 2012
                   

                  I also do some investigations:

                  • Tomcat 3.54a vs Tomcat 3.54a: ~320 mb
                  • Scarlet 1.1c vs Scarlet 1.1c: ~300 mb
                  • Druss vs Druss: ~129 mb
                  • Diamond vs Diamond: ~116 mb

                  Numbers - it's smallest used memory showed by robocode after gc. So both Tomcat & Scarlet is memory consuming robots. I tried to optimise Tomcat, but did not get any success. Anybody have ideas, how i can detect which part of Tomcat uses most part of memory?

                    Jdev05:27, 27 February 2012

                    Try doing some heap profiling.

                      MN14:10, 27 February 2012
                       

                      Are you using fasttrig? If so, how big are your arrays?

                      Are you using multi-dimensional arrays? It is very easy to use LOTS of memory. I have many multi-dimensional arrays, but use a lazy initialisation so that memory is only used if it gets written to first.

                      If you have your own kd-tree, check that it is splitting how you want it to. If it only splits one point off each time, it will get deep very quickly. This uses lots of memory, as each object needs a container and a bounding box.

                      Check if you have static arrays/lists that could initialised after each round.

                      Don't keep logs of data that won't get used again. Once it won't be used (eg at the end of the round) clear it explicitly by setting to null or calling .clear()

                      Check you don't have circular dependencies. Make sure you break the dependency if you delete something.

                      These are my first thoughts =)

                        Skilgannon08:32, 27 February 2012
                         
                        1. I use fast trig, but initially Tomcat eats less than 100 mb of memory
                        2. I do not use multi-dimensional arrays
                        3. I use Rednaxela's kD-tree and own R-tree. Splitting in r-tree is fairly well
                        4. I keep static links only to movement & gun logs.

                        I tried to change double to float everywhere, but it has not any influence on memory usage. My problem, that i have 16 logs with visit data, 16 logs with hit data & 6 logs with tick data, but i can not find way, how to reduce it without APS degradation. But any way, thanks for response:)

                          Jdev09:25, 27 February 2012
                           

                          I can increase the maximum heap in my clients, although it will change RoboRumble "rules". So I would like the opinion of the people here.

                            MN14:13, 27 February 2012
                             

                            Not much to add, lots of good suggestions already, but do you keep all your waves around forever? I clear the objects between rounds because all the pertinent data is in the kd-trees. I have more than a few trees in both gun and movement, too, for what it's worth. Do you have a big object as the "value" in your trees?

                            "static links only to movement & gun logs" and your R-tree are what jump out at me. I would try chopping off certain parts of your bot and seeing which brings your memory usage down to earth, though some kind of heap profiler (like MN suggested) would be more elegant. =)

                            Off-topic: Circular dependencies shouldn't matter, at least in modern JVMs. If the only references are within a circle unreachable from the root of code execution, it will be garbage collected.

                              Voidious22:01, 27 February 2012
                               

                              I don't know about the Nene side of the code, but on the RougeDC side, Scarlet's gun is somewhat heavy on memory. IIRC it's partially because of it's folded single-tick pattern matching. I might look at some heap profiling to see exactly how the memory usage is broken down some time, but I'm pretty busy these days.

                              In general, I kind of wish Java allowed the security manager to deal with memory usage, because then the robocode engine could have a 'real' rule about memory use. Instead we're just kind of left with "not too much please".

                                Rednaxela01:13, 28 February 2012