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
