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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > Leo Li
> > China Software Development Lab, IBM
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Leo Li
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
