harmony-dev mailing list archives

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message