harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Date Fri, 15 Sep 2006 00:44:47 GMT
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.

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


Mime
View raw message