>> or IBM has used a mark-sweep-compact collector Never mind - Sun's is also sometimes referred to as mark-sweep-compact. I've just seen it referred to as mark-compact before as well. In either case though, without some sort of sweep phase, there is no reclamation of memory :)
It's interesting though - in the days of the early JVM's Sun talked more about compaction - but if you look at their recent info, they don't even mention it, or give you params to messs with it. They just talk about the mark and the sweep phase. IBM is much more open about a compaction phase, and not only do they give controls to tune it, they let you turn it off completely. Not sure what Sun is doing with compaction these days - or if they just work with fragmentation avoidance techniques instead - haven't seen any info on it. Mark Miller wrote: > When we talk about Collectors, we are not just talking about > "collecting" - whatever that means. There isn't really a "collecting" > phase - the whole algorithm is garbage collecting - hence calling the > different implementations "collectors". > > Usually, fragmentation is dealt with using a mark-compact collector (or > IBM has used a mark-sweep-compact collector). > Copying collectors are not only super efficient at collecting young > spaces, but they are also great for fragmentation - when you copy > everything to the new space, you can remove any fragmentation. At the > cost of double the space requirements though. > > So mark-compact is a compromise. First you mark whats reachable, then > everything thats marked is copied/compacted to the bottom of the heap. > Its all part of a "collection" though. > > Jonathan Ariel wrote: > >> Maybe what's missing here is how did I get the 11%.I just ran solr with the >> following JVM params: -XX:+PrintGCApplicationConcurrentTime >> -XX:+PrintGCApplicationStoppedTime with that I can measure the amount of >> time the application run between collection pauses and the length of the >> collection pauses, respectively. >> I think that in this case the 11% is just for memory collection and not >> defragmentation... but I'm not 100% sure. >> >> On Fri, Sep 25, 2009 at 5:05 PM, Fuad Efendi <f...@efendi.ca> wrote: >> >> >> >>> But again, GC is not just "Garbage Collection" as many in this thread >>> think... it is also "memory defragmentation" which is much costly than >>> "collection" just because it needs move somewhere _live_objects_ (and >>> wait/lock till such objects get unlocked to be moved...) - obviously more >>> memory helps... >>> >>> 11% is extremely high. >>> >>> >>> -Fuad >>> http://www.linkedin.com/in/liferay >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Jonathan Ariel [mailto:ionat...@gmail.com] >>>> Sent: September-25-09 3:36 PM >>>> To: solr-user@lucene.apache.org >>>> Subject: Re: FW: Solr and Garbage Collection >>>> >>>> I'm not planning on lowering the heap. I just want to lower the time >>>> "wasted" on GC, which is 11% right now.So what I'll try is changing the >>>> >>>> >>> GC >>> >>> >>>> to -XX:+UseConcMarkSweepGC >>>> >>>> On Fri, Sep 25, 2009 at 4:17 PM, Fuad Efendi <f...@efendi.ca> wrote: >>>> >>>> >>>> >>>>> Mark, >>>>> >>>>> what if piece of code needs 10 contiguous Kb to load a document field? >>>>> >>>>> >>> How >>> >>> >>>>> locked memory pieces are optimized/moved (putting on hold almost whole >>>>> application)? >>>>> Lowering heap is _bad_ idea; we will have extremely frequent GC >>>>> >>>>> >>> (optimize >>> >>> >>>>> of >>>>> live objects!!!) even if RAM is (theoretically) enough. >>>>> >>>>> -Fuad >>>>> >>>>> >>>>> >>>>> >>>>>> Faud, you didn't read the thread right. >>>>>> >>>>>> He is not having a problem with OOM. He got the OOM because he >>>>>> >>>>>> >>> lowered >>> >>> >>>>>> the heap to try and help GC. >>>>>> >>>>>> He normally runs with a heap that can handle his FC. >>>>>> >>>>>> Please re-read the thread. You are confusing the tread. >>>>>> >>>>>> - Mark >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>>>> GC will frequently happen even if RAM is more than enough: in case >>>>>>> >>>>>>> >>> if >>> it >>> >>> >>>>> is >>>>> >>>>> >>>>>>> heavily sparse... so that have even more RAM! >>>>>>> -Fuad >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> >> >> > > > -- - Mark http://www.lucidimagination.com
