harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Date Fri, 15 Sep 2006 01:35:38 GMT


Xiao-Feng Li wrote:
> GCv5 is a proposed next GC version for Harmony VM. It's just starting.
> Any people who are interested are welcome to comment the design or
> participate the development. Please notice messages with [DRLVM][GC]
> in subject. I will submit a very preliminary mark-compaction GC
> skeleton as the mature space collector soon.

When this happens, lets ensure that we can compile both v4.1 and v5 at 
the same time, and choose them via a cmd-line switch...


geir

> 
> The posted GCv5 design proposal (at high level) is at here:
> http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg12263.html
> 
> Thanks,
> xiaofeng
> 
> On 9/15/06, Leo Li <liyilei1979@gmail.com> wrote:
>> Hi, Xiao-Feng:
>>      It will be great if VM can adjust its strategy adaptively. 
>> However, as
>> a programmer, I would like to have some method to instruct the GC 
>> strategy.
>> If I can, I tend to control things and get definite result, whenever I am
>> programming or tuning . :)
>>      Besides, where are your GCv5, is it open-sourced? I am quite
>> interesting in the topic.
>>
>> Good luck!
>>
>> On 9/14/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
>> >
>> > Hi, Leo, your concerns about the potential impact of GC on system
>> > performance (time and memory) are quite reasonable. Yes, there is no
>> > single GC algorithm that wins all situations. Some dynamic adaptation
>> > are desirable.
>> >
>> > We would like to introduce this kind of dynamics step by step, since
>> > it's subject to thorough evaluations to decide the adaptation
>> > heuristics. As the first step of GCv5 develpment, we will let the size
>> > of a generation (an age-based heap partition) be variable, so that the
>> > frequency of GC is variable accordingly.
>> >
>> > Thanks,
>> > xiaofeng
>> >
>> > On 9/14/06, Leo Li <liyilei1979@gmail.com> wrote:
>> > > Dear Xiao-Feng:
>> > >     Thank you for your advice.
>> > >     I would like generational GC, but what I worry about whether 
>> it is
>> > > preferrable to let GC start even if there is free memory
>> > existing.  Although
>> > > the initiative gc fits in my case, I do not know the side-effect of
>> > frequent
>> > > gc, for example, to pick out gc-able objects, to merge memory and to
>> > reset
>> > > pointers to moved objects, especially on other cases. In my 
>> opinion, the
>> > > strategy of current passive gc still has its market. Is it 
>> possible to
>> > let
>> > > it configurable for application developers to choose the gc strategy?
>> > >    Smatter compiler to allocate object on stack is really a good way
>> > since
>> > > many a time an object is used as a local varaible. I think it is 
>> not so
>> > > difficult for compiler to pick out local variables and what we 
>> need is
>> > just
>> > > to let VM to allow space allocated on stack.:)
>> > >    I am not quite familiar with JIT, but it will become a powerful
>> > > supplement for static analysis.
>> > >
>> > > Good luck!
>> > >
>> > > On 9/14/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
>> > > >
>> > > > Hi, Dear Leo,
>> > > >
>> > > > There are a couple of known approaches to collect short-lived 
>> objects.
>> > > >
>> > > > The most common approach is generational GC, which is designed
>> > > > specifically with the assumption that most objects die young in 
>> normal
>> > > > applications. Simply put, the objects are arranged into spaces
>> > > > according to their age, and the younger objects' spaces are 
>> collected
>> > > > more frequently. GC pause time is improved since only part of 
>> the heap
>> > > > is collected normally.
>> > > >
>> > > > Another way is to let JIT to free objects whenever it sees
>> > > > appropriate. The idea actually is letting JIT to insert object 
>> freeing
>> > > > code sequence in the generated jitted code, so that the mutator can
>> > > > free objects proactively. The "free-me" paper in this year's PLDI
>> > > > exprimented this approach but showed this approach helps little 
>> with a
>> > > > setting of generational GC.
>> > > >
>> > > > Stack allocation may help the short-lived objects collection as 
>> well,
>> > > > which requires escape analysis/detection (by compiler or hardware).
>> > > > But my experience was that synchronization removal is the main 
>> benefit
>> > > > from escape analysis, and stack allocation may not really help 
>> in our
>> > > > evaluations.
>> > > >
>> > > > Which approach is the best for your case may depend on the real
>> > > > application behavior. Since generational GC is well-established for
>> > > > this problem, we'd take this approach at first. GCv5 proposed is a
>> > > > generational GC. We hope it can help to solve the problem you meet.
>> > > > Stay tuned... :-)
>> > > >
>> > > > Thanks,
>> > > > xiaofeng
>> > > >
>> > > > On 9/14/06, Leo Li <liyilei1979@gmail.com> wrote:
>> > > > > Hi,all:
>> > > > >    As we all know, java objects are allocated on heap instead
of
>> > stack,
>> > > > > thus there is a problem about how to garbage collect short-lived
>> > objects
>> > > > > quickly.
>> > > > >    In a recent real project I involved, a server built on java

>> tries
>> > to
>> > > > > send thousands of messages to client per second. A lot of
>> > short-lived
>> > > > > messages is created as objects and discarded. (Although I can
>> > recycle
>> > > > these
>> > > > > memory, there is still a byte array created during per call of

>> nio
>> > read
>> > > > and
>> > > > > write.) Since current GC strategy adopted by current RI starts
to
>> > work
>> > > > only
>> > > > > when the memory allocated approaching the limit of java heap,
the
>> > work
>> > > > of GC
>> > > > > is huge and will raise a wave on the server performance.
>> > Furthermore,
>> > > > after
>> > > > > a long run, although I know GC will merge memory, the operating
>> > system
>> > > > > reports there is memory fragment and in the worst case the OS

>> will
>> > even
>> > > > > report real memory is exhausted.
>> > > > >    Of course it is possible to limit the java heap so as to 
>> force gc
>> > > > > frequently as a workround, is it preferrable to collect 
>> short-lived
>> > > > objects
>> > > > > quickly such as adopt aged-related object queues as one of the
gc
>> > > > strategy?
>> > > > >   What about the VMs here, drlvm or J9?
>> > > > >
>> > > > > Leo Li
>> > > > > China Software Development Lab, IBM
>> > > > >
>> > > > >
>> > > >
>> > > > 
>> ---------------------------------------------------------------------
>> > > > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > > > To unsubscribe, e-mail: 
>> harmony-dev-unsubscribe@incubator.apache.org
>> > > > For additional commands, e-mail: 
>> harmony-dev-help@incubator.apache.org
>> > > >
>> > > >
>> > >
>> > >
>> > > --
>> > > Leo Li
>> > > China Software Development Lab, IBM
>> > >
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >
>> >
>>
>>
>> -- 
>> Leo Li
>> China Software Development Lab, IBM
>>
>>
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message