You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Leo Li <li...@gmail.com> on 2006/09/14 05:08:29 UTC
[General VM] GC strategy:how to garbage collect short-lived objects quickly.
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x1E9 day of Apache Harmony Robin Garner wrote:
> Egor Pasko wrote:
> > On the 0x1E4 day of Apache Harmony Oliver Deakin wrote:
> >>> Forcing gc by hand does work, but it is difficult for code to know
> >>> when to
> >>> call gc.So I think it is better if VM can give some support since it
> >>> knows
> >>> the global situation.:)
> >> ..and of course a manual gc() call does not necessarily result in a gc
> > this one is easy :) make a gc2() magic in DRLVM and collect only
> > young
> > objects on it.. to make code portable, implement gc2() as gc() for
> > other JVMs. Need to be patient until the generational GC.
> > Can a hack like this be widely accepted in Java community? I think,
> > yes.
> >
>
> I think GC research will soon make this unnecessary.
..How I am dreaming of this moment :)
> For example the Sun VM has a concurrent collector for its mature
> space, so on a sufficiently lightly loaded system (or with a core to
> spare) you could eliminate most of the mature space collection pause
> time.
Won't there always be some space to improve performance of a specific
application via user-level hints to GC? Anyway, I am glad that GC
research is making progress!
--
Egor Pasko, Intel Managed Runtime Division
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived
objects quickly.
Posted by Robin Garner <ro...@anu.edu.au>.
Egor Pasko wrote:
> On the 0x1E4 day of Apache Harmony Oliver Deakin wrote:
>>> Forcing gc by hand does work, but it is difficult for code to know
>>> when to
>>> call gc.So I think it is better if VM can give some support since it
>>> knows
>>> the global situation.:)
>> ..and of course a manual gc() call does not necessarily result in a gc
>
> this one is easy :) make a gc2() magic in DRLVM and collect only young
> objects on it.. to make code portable, implement gc2() as gc() for
> other JVMs. Need to be patient until the generational GC.
>
> Can a hack like this be widely accepted in Java community? I think, yes.
>
I think GC research will soon make this unnecessary. For example the
Sun VM has a concurrent collector for its mature space, so on a
sufficiently lightly loaded system (or with a core to spare) you could
eliminate most of the mature space collection pause time.
In MMTk, there is a command line switch, -X:gc:fullHeapSystemGc, used to
specify whether System.gc() causes a full heap collection. But no, I
don't think this is something users should need to play with.
cheers
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x1E4 day of Apache Harmony Oliver Deakin wrote:
> > Forcing gc by hand does work, but it is difficult for code to know
> > when to
> > call gc.So I think it is better if VM can give some support since it
> > knows
> > the global situation.:)
>
> ..and of course a manual gc() call does not necessarily result in a gc
this one is easy :) make a gc2() magic in DRLVM and collect only young
objects on it.. to make code portable, implement gc2() as gc() for
other JVMs. Need to be patient until the generational GC.
Can a hack like this be widely accepted in Java community? I think, yes.
--
Egor Pasko, Intel Managed Runtime Division
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects
quickly.
Posted by Oliver Deakin <ol...@googlemail.com>.
Leo Li wrote:
> Hi,Egor:
>
> On 14 Sep 2006 12:30:49 +0700, Egor Pasko <eg...@gmail.com> wrote:
>>
>> On the 0x1E4 day of Apache Harmony Leo Li 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 forcing gc by hand? does it help?
>
>
> Forcing gc by hand does work, but it is difficult for code to know
> when to
> call gc.So I think it is better if VM can give some support since it
> knows
> the global situation.:)
..and of course a manual gc() call does not necessarily result in a gc -
there's
no guarantee - so even if it was the right time, you might not get it.
Regards,
Oliver
>
>
>> What about the VMs here, drlvm or J9?
>>
>> In a DRLVM JIT (Jitrino.OPT) there is an escape analysis prototype. It
>> detects objects that can be allocated on stack (and, hence, on
>> registers). Currently, it is switched off by default, and, when
>> enabled, it just marks the objects that are not escaped. This info is
>> never used in Jitrino.OPT yet. Sometimes, escape analyzers help, but
>> not very much :)
>
>
> It will be great if JIT can help to allocation objects on stack.
>
> DRLVM GC gurus will say more ;)
>>
>> --
>> Egor Pasko, Intel Managed Runtime Division
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived
objects quickly.
Posted by Robin Garner <ro...@anu.edu.au>.
>> What about the VMs here, drlvm or J9?
>>
>> In a DRLVM JIT (Jitrino.OPT) there is an escape analysis prototype. It
>> detects objects that can be allocated on stack (and, hence, on
>> registers). Currently, it is switched off by default, and, when
>> enabled, it just marks the objects that are not escaped. This info is
>> never used in Jitrino.OPT yet. Sometimes, escape analyzers help, but
>> not very much :)
>
>
> It will be great if JIT can help to allocation objects on stack.
>
> DRLVM GC gurus will say more ;)
The JikesRVM experience was that stack allocation didn't improve
anything, but once you can show that an object never escapes a method,
and is 'hot', you can actually inline the fields of the object, and
never allocate it in the first place. This is a valuable optimization.
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Leo Li <li...@gmail.com>.
Hi,Egor:
On 14 Sep 2006 12:30:49 +0700, Egor Pasko <eg...@gmail.com> wrote:
>
> On the 0x1E4 day of Apache Harmony Leo Li 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 forcing gc by hand? does it help?
Forcing gc by hand does work, but it is difficult for code to know when to
call gc.So I think it is better if VM can give some support since it knows
the global situation.:)
> What about the VMs here, drlvm or J9?
>
> In a DRLVM JIT (Jitrino.OPT) there is an escape analysis prototype. It
> detects objects that can be allocated on stack (and, hence, on
> registers). Currently, it is switched off by default, and, when
> enabled, it just marks the objects that are not escaped. This info is
> never used in Jitrino.OPT yet. Sometimes, escape analyzers help, but
> not very much :)
It will be great if JIT can help to allocation objects on stack.
DRLVM GC gurus will say more ;)
>
> --
> Egor Pasko, Intel Managed Runtime Division
>
>
> ---------------------------------------------------------------------
> 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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x1E4 day of Apache Harmony Leo Li 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 forcing gc by hand? does it help?
> What about the VMs here, drlvm or J9?
In a DRLVM JIT (Jitrino.OPT) there is an escape analysis prototype. It
detects objects that can be allocated on stack (and, hence, on
registers). Currently, it is switched off by default, and, when
enabled, it just marks the objects that are not escaped. This info is
never used in Jitrino.OPT yet. Sometimes, escape analyzers help, but
not very much :)
DRLVM GC gurus will say more ;)
--
Egor Pasko, Intel Managed Runtime Division
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived
objects quickly.
Posted by Robin Garner <ro...@anu.edu.au>.
Weldon Washburn wrote:
> Its not a simple wrapper that is missing. MMTk is written in Java. This
> Java code needs to be intergrated into the bootstrap process of DRLVM.
> For
> example, initial bootstrap java code needs to run on a bootstrap java heap
> until all of MMTk itself has been compiled and initialized. I keep hoping
> that the MMTk guys will volunteer to help me with this (hint, hint).
> Having
> said that, I am trying to put together a TODO list of stuff that needs
> doing
> on the MMTk port so that others can jump in and help. I hope to have this
> list done within one week.
>
Happy to help if you have specific questions :)
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Weldon Washburn <we...@gmail.com>.
On 9/16/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
>
> Also, can MMTk function as the GC for DRLVM yet? If not, can you
> provide a wrapper so it can?
Its not a simple wrapper that is missing. MMTk is written in Java. This
Java code needs to be intergrated into the bootstrap process of DRLVM. For
example, initial bootstrap java code needs to run on a bootstrap java heap
until all of MMTk itself has been compiled and initialized. I keep hoping
that the MMTk guys will volunteer to help me with this (hint, hint). Having
said that, I am trying to put together a TODO list of stuff that needs doing
on the MMTk port so that others can jump in and help. I hope to have this
list done within one week.
geir
>
>
> ---------------------------------------------------------------------
> 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
>
>
--
Weldon Washburn
Intel Middleware Products Division
Re: [General VM] GC strategy:how to garbage collect short-lived objects
quickly.
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Weldon Washburn wrote:
> On 9/14/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>
>>
>>
>> Xiao-Feng Li wrote:
>> > On 9/15/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> >>
>> >>
>> >> 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...
>> >>
>> >
>> > Yes, it is always desirable to keep the existing version runnable.
>> >
>> > Since I will submit code as JIRA issue or update from time to time as
>> > the development proceeds, the initial submissions are only for
>> > developers, will not be ready to run as GCv5, (e.g., it may have
>> > seperate standalone nursery collector and mature collector). When GCv5
>> > is developed reasonably complete in functionality, we will make it a
>> > command line option. Or do you suggest to do it immediately?
>>
>> It wouldn't be a bad thing to at least try to start integrating as soon
>> as possible, as it might affect the structure of what you are building...
>
>
> Integrating as soon as possible is probably already going on. The DRLVM
> VM/GC interface has been basically stable for quite some time. If Xiao
> Feng
> finds a problem with VM/GC interface, we need to know about it immediately.
> Until then, GCV5 probably has little impact on the non-GC part of the VM.
> In other words, GCV5 already connects to DRLVM in much the same fashion as
> GCV4.x and MMTk.
>
Sure.
> I think the question to ask Xiao Feng is when he thinks it makes sense for
> others to play with DRLVM/GCV5. It should be sooner rather than later.
> From the above it looks like once the mature space collector is
> finished, we
> can call for a vote to commit GCV5 to the repository. Once this happens, a
> standard build will produce GCV4, GCV4.1 and GCV5 DLLs. A command line
> switch will select between them. A command line switch for MMTk also needs
> to be added. Hopefully this will happen in the next month or so.
If no one minds, committing early and often might be better than
waiting. The usual "let other people see it, comment, help..." message :)
Also, can MMTk function as the GC for DRLVM yet? If not, can you
provide a wrapper so it can?
geir
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Weldon Washburn <we...@gmail.com>.
On 9/14/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
>
> Xiao-Feng Li wrote:
> > On 9/15/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >>
> >>
> >> 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...
> >>
> >
> > Yes, it is always desirable to keep the existing version runnable.
> >
> > Since I will submit code as JIRA issue or update from time to time as
> > the development proceeds, the initial submissions are only for
> > developers, will not be ready to run as GCv5, (e.g., it may have
> > seperate standalone nursery collector and mature collector). When GCv5
> > is developed reasonably complete in functionality, we will make it a
> > command line option. Or do you suggest to do it immediately?
>
> It wouldn't be a bad thing to at least try to start integrating as soon
> as possible, as it might affect the structure of what you are building...
Integrating as soon as possible is probably already going on. The DRLVM
VM/GC interface has been basically stable for quite some time. If Xiao Feng
finds a problem with VM/GC interface, we need to know about it immediately.
Until then, GCV5 probably has little impact on the non-GC part of the VM.
In other words, GCV5 already connects to DRLVM in much the same fashion as
GCV4.x and MMTk.
I think the question to ask Xiao Feng is when he thinks it makes sense for
others to play with DRLVM/GCV5. It should be sooner rather than later.
>From the above it looks like once the mature space collector is finished, we
can call for a vote to commit GCV5 to the repository. Once this happens, a
standard build will produce GCV4, GCV4.1 and GCV5 DLLs. A command line
switch will select between them. A command line switch for MMTk also needs
to be added. Hopefully this will happen in the next month or so.
geir
>
> >
> > Thanks,
> > xiaofeng
> >
> >
> >>
> >> geir
> >>
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
Weldon Washburn
Intel Middleware Products Division
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 9/15/06, Ivan Volosyuk <iv...@gmail.com> wrote:
>
> There was a command line switch -Dvm.dlls=<full path to GC>. It
> allowed to select GC dll at startup. AFAIK, for now, the method is
> broken. Anyway, we can add the property gc.dll: -Dgc.dll=<path to GC>
> --
> Ivan
>
Good idea. And we need add multiple GCs build as well. Thanks.
-xiaofeng
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Ivan Volosyuk <iv...@gmail.com>.
On 9/15/06, Xiao-Feng Li <xi...@gmail.com> wrote:
> On 9/15/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > > Yes, it is always desirable to keep the existing version runnable.
> > >
> > > Since I will submit code as JIRA issue or update from time to time as
> > > the development proceeds, the initial submissions are only for
> > > developers, will not be ready to run as GCv5, (e.g., it may have
> > > seperate standalone nursery collector and mature collector). When GCv5
> > > is developed reasonably complete in functionality, we will make it a
> > > command line option. Or do you suggest to do it immediately?
> >
> > It wouldn't be a bad thing to at least try to start integrating as soon
> > as possible, as it might affect the structure of what you are building...
> >
> > geir
> >
>
> Agree.
There was a command line switch -Dvm.dlls=<full path to GC>. It
allowed to select GC dll at startup. AFAIK, for now, the method is
broken. Anyway, we can add the property gc.dll: -Dgc.dll=<path to GC>
--
Ivan
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 9/15/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > Yes, it is always desirable to keep the existing version runnable.
> >
> > Since I will submit code as JIRA issue or update from time to time as
> > the development proceeds, the initial submissions are only for
> > developers, will not be ready to run as GCv5, (e.g., it may have
> > seperate standalone nursery collector and mature collector). When GCv5
> > is developed reasonably complete in functionality, we will make it a
> > command line option. Or do you suggest to do it immediately?
>
> It wouldn't be a bad thing to at least try to start integrating as soon
> as possible, as it might affect the structure of what you are building...
>
> geir
>
Agree.
Thanks,
xiaofeng
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects
quickly.
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Xiao-Feng Li wrote:
> On 9/15/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>
>>
>> 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...
>>
>
> Yes, it is always desirable to keep the existing version runnable.
>
> Since I will submit code as JIRA issue or update from time to time as
> the development proceeds, the initial submissions are only for
> developers, will not be ready to run as GCv5, (e.g., it may have
> seperate standalone nursery collector and mature collector). When GCv5
> is developed reasonably complete in functionality, we will make it a
> command line option. Or do you suggest to do it immediately?
It wouldn't be a bad thing to at least try to start integrating as soon
as possible, as it might affect the structure of what you are building...
geir
>
> Thanks,
> xiaofeng
>
>
>>
>> geir
>>
>
> ---------------------------------------------------------------------
> 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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 9/15/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
> 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...
>
Yes, it is always desirable to keep the existing version runnable.
Since I will submit code as JIRA issue or update from time to time as
the development proceeds, the initial submissions are only for
developers, will not be ready to run as GCv5, (e.g., it may have
seperate standalone nursery collector and mature collector). When GCv5
is developed reasonably complete in functionality, we will make it a
command line option. Or do you suggest to do it immediately?
Thanks,
xiaofeng
>
> geir
>
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects
quickly.
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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 <li...@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 <xi...@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 <li...@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 <xi...@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 <li...@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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 <li...@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 <xi...@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 <li...@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 <xi...@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 <li...@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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Leo Li <li...@gmail.com>.
Hi, Weldon:
Thank you. I can read the code:)
Good luck!
On 9/16/06, Weldon Washburn <we...@gmail.com> wrote:
>
> On 9/14/06, Leo Li <li...@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.
>
>
> In case it fell between the cracks, Xiao Feng posted initial rough GCV5
> files at:
>
> http://issues.apache.org/jira/browse/HARMONY-1428
>
> Also, you may be interested in MMTk. Its an infrastructure for
> experimenting with GC algorithms. An initial incomplete port is in
> drlvm/trunk/vm/MMTk.
>
>
>
> Good luck!
> >
> > --
> > Weldon Washburn
> > Intel Middleware Products Division
>
>
--
Leo Li
China Software Development Lab, IBM
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Weldon Washburn <we...@gmail.com>.
On 9/14/06, Leo Li <li...@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.
In case it fell between the cracks, Xiao Feng posted initial rough GCV5
files at:
http://issues.apache.org/jira/browse/HARMONY-1428
Also, you may be interested in MMTk. Its an infrastructure for
experimenting with GC algorithms. An initial incomplete port is in
drlvm/trunk/vm/MMTk.
Good luck!
>
> --
> Weldon Washburn
> Intel Middleware Products Division
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Leo Li <li...@gmail.com>.
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 <xi...@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 <li...@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 <xi...@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 <li...@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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 <li...@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 <xi...@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 <li...@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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 9/15/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> Well, common practise is to allocate most of the physical memory for
> java heap and let the GC to deal with it. Different GC algorithms will
> produce different pause times with different frequencies.
>
> For your case, I think, it will be optimal to have old generation of
> objects living untouched most of the GCs. The rest of the heap is for
> young generation objects. GC can be made to occur more frequently if
> we collect only part of the young generation space: the oldest chunk
> of young generation at a time. There is a trade-off between portion of
> heap collected and GC frequency, of cause.
>
> Other techniques like the JIT's thread-local allocation can also help.
> --
> Ivan
Yes, agreed. the trade-off in GC frequency should be well understood
in order to achieve best performance.
Thanks,
xiaofeng
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Ivan Volosyuk <iv...@gmail.com>.
Well, common practise is to allocate most of the physical memory for
java heap and let the GC to deal with it. Different GC algorithms will
produce different pause times with different frequencies.
For your case, I think, it will be optimal to have old generation of
objects living untouched most of the GCs. The rest of the heap is for
young generation objects. GC can be made to occur more frequently if
we collect only part of the young generation space: the oldest chunk
of young generation at a time. There is a trade-off between portion of
heap collected and GC frequency, of cause.
Other techniques like the JIT's thread-local allocation can also help.
--
Ivan
On 9/14/06, Leo Li <li...@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.
>
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Leo Li <li...@gmail.com>.
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 <xi...@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 <li...@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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 <li...@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
Re: [General VM] GC strategy:how to garbage collect short-lived
objects quickly.
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr. wrote:
> Robin Garner wrote:
>> Designing a garbage collector with low pause times and high throughput
>> (ie
>> low overhead) is to an extent the 'holy grail' of memory management
>> research.
>
> Do you know much about this on in JRockit?
>
> http://www.networkcomputing.com/showArticle.jhtml?articleId=193000182
and, of course, in the interests of unbiased reporting
http://www.ibm.com/software/webservers/realtime/
;-)
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived
objects quickly.
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Robin Garner wrote:
> Designing a garbage collector with low pause times and high throughput (ie
> low overhead) is to an extent the 'holy grail' of memory management
> research.
Do you know much about this on in JRockit?
http://www.networkcomputing.com/showArticle.jhtml?articleId=193000182
(They used Geronimo to test too. w00t!)
>
> The worst case pause times are in full heap collectors, where the pause
> time is proportional to the total number of live objects in the heap.
>
> Generational collection helps drive down the average pause time (nursery
> collections are cheap) but the maximum pause time (when the mature space
> needs collecting) is much the same as a full heap collector. A
> generational collector with a bounded nursery can shorten the time of
> minor collections, but has lower throughput and the same maximum pause
> time.
>
> To an extent, most of the literature on GC addresses this issue, and some
> things you might like to read up on are:
>
> - Metronome.
> This pushes pause times down into the sub-millisecond realm, but at a
> considerable (although predictable) overhead.
>
> - The Sun 1.5 JVM, which has an optional concurrent collector for the
> mature space
>
> - Ulterior Reference Counting, which combines the high throughput of a
> generational collector with the low pause times of reference counting.
>
> - Beltway, which collects the heap in small chunks, after giving objects
> time to die
>
> - Free-me, which automatically identifies short-lived objects
>
> Just to name a few.
>
> cheers
>
>> Leo Li 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?
>>>
>> Interesting topic, I'm still dreaming of "free()" in Java (This dream
>> begins at the very beginning when I see Java, as C/C++ is my first
>> program language )However, it seems RI will never give us "free()". :)
>>
>> Only a thought, Java may offer a key word "temp", indicating that this
>> variety can be freed at once.
>>
>>> Leo Li
>>> China Software Development Lab, IBM
>>>
>>
>> --
>>
>> Best Regards!
>>
>> Jimmy, Jing Lv
>> 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
>
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived
objects quickly.
Posted by Robin Garner <ro...@anu.edu.au>.
Designing a garbage collector with low pause times and high throughput (ie
low overhead) is to an extent the 'holy grail' of memory management
research.
The worst case pause times are in full heap collectors, where the pause
time is proportional to the total number of live objects in the heap.
Generational collection helps drive down the average pause time (nursery
collections are cheap) but the maximum pause time (when the mature space
needs collecting) is much the same as a full heap collector. A
generational collector with a bounded nursery can shorten the time of
minor collections, but has lower throughput and the same maximum pause
time.
To an extent, most of the literature on GC addresses this issue, and some
things you might like to read up on are:
- Metronome.
This pushes pause times down into the sub-millisecond realm, but at a
considerable (although predictable) overhead.
- The Sun 1.5 JVM, which has an optional concurrent collector for the
mature space
- Ulterior Reference Counting, which combines the high throughput of a
generational collector with the low pause times of reference counting.
- Beltway, which collects the heap in small chunks, after giving objects
time to die
- Free-me, which automatically identifies short-lived objects
Just to name a few.
cheers
> Leo Li 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?
>>
>
> Interesting topic, I'm still dreaming of "free()" in Java (This dream
> begins at the very beginning when I see Java, as C/C++ is my first
> program language )However, it seems RI will never give us "free()". :)
>
> Only a thought, Java may offer a key word "temp", indicating that this
> variety can be freed at once.
>
>> Leo Li
>> China Software Development Lab, IBM
>>
>
>
> --
>
> Best Regards!
>
> Jimmy, Jing Lv
> 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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Ivan Volosyuk <iv...@gmail.com>.
On 10/1/06, FaeLLe <mr...@gmail.com> wrote:
> Perhaps he means clone the object to a WeakReference then null the original
> object ?
>
> That way the only existing copy of that object will be a WeakReference....
> with my limited
> understanding of GC concepts would that no be benificial ?
>
> Regards,
>
> - Vikram Mohan
WeakReference can become null any time. We hold strong reference for a
reason. Usually algorithms assume that there is no possibility to
loose the object we hold at any arbitrary point. With the conversion,
the assumption will fail.
If we had a way to re-create the state of given object after we have
GC'd him, we could use the WeakReferences. But, anyway, I have serious
doubts about any performance gain with the approach for _short_living_
objects. Short living object, AFAIU, is objects which are created,
initialized, used, and unused any more.
Explicit zeroing of no-longer-used references can be benefitial for
GC. This is nothing to do with the WeakReferences.
--
Ivan
Intel Middleware Products Division
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by FaeLLe <mr...@gmail.com>.
Perhaps he means clone the object to a WeakReference then null the original
object ?
That way the only existing copy of that object will be a WeakReference....
with my limited
understanding of GC concepts would that no be benificial ?
Regards,
- Vikram Mohan
On 9/19/06, Ivan Volosyuk <iv...@gmail.com> wrote:
>
> On 9/19/06, Oliver Deakin <ol...@googlemail.com> wrote:
> > Ivan Volosyuk wrote:
> > > On 9/19/06, Oliver Deakin <ol...@googlemail.com> wrote:
> > >> Robin Garner wrote:
> > >> >
> > >> >>>
> > >> >>> I don't understand. How can weak references help short-lived
> objects
> > >> >>> reclaim?
> > >> >>
> > >> >> Really what I'm saying is that this is the closest thing we have
> to a
> > >> >> hint to GC that objects can be collected soon - but it is not
> > >> anything
> > >> >> like a proper free() call. There is no immediate reclaim of
> memory,
> > >> >> just the possibility that it will be reclaimed soon - and the
> object
> > >> >> may be garbage collected before you are finished with it!
> > >> >>
> > >> >> Regards,
> > >> >> Oliver
> > >> >>
> > >> >
> > >> > Actually, it's kind of the other way around isn't it ? Nulling the
> > >> > last pointer to an object tells the GC that it can collect it
> > >> > (explicitly in the case of reference counting), whereas having a
> Weak
> > >> > Reference to an object says 'please tell me when on-one else wants
> > >> > this object', which results in the object staying around even
> longer.
> > >>
> > >> Isn't this only the case if you register the WeakReference with a
> > >> ReferenceQueue?
> > >> If you do not do that, then the GC can collect the referent when it
> > >> wants, and you will
> > >> just get a null back from a get() call on any WeakReference object.
> > >> So I imagine that keeping the object weakly reachable and not
> > >> registering it with
> > >> a ReferenceQueue says to the GC "you are free to collect this
> referent
> > >> object at the
> > >> next collection if you wish".
> > >
> > > It is always better not to have any references to an object in heap
> > > then to have a WeakReference to it.
> >
> > Yup, agreed!
> >
> > > The object without references is
> > > simply garbage, while WeakReference is a kind of reference to it and
> > > require handling - updating on object relocation, zeroing when object
> > > no longer reachable.
> >
> > Agreed - but I wasn't comparing it to an object with no references. I
> was
> > merely saying that rather than having a strong reference to a very short
> > lived object, that will definitely not be garbage collected until the
> strong
> > reference goes out of scope or is explicitly nullified, having only
> > WeakReferences
> > to the object could allow it to be collected ealier. I know it's not
> > guaranteed,
> > but there is a possibility. It's also probably not the best thing to do
> > - it was
> > just a comment on the ability to have short lived objects gc'ed earlier
> :)
>
> Well, Oliver, if you have a strong reference to short-lived object,
> you have it for a reason. This means that you do some actions with it.
> It will be a failure when the reference to the object suddenly become
> a null reference (what is normal for WeakReference). If you no longer
> need that object - that means the live of it has just come to an end.
> Short live :)
>
> After that, no more need for WeakReference to the object. Before that,
> hard reference is required by the algorithm used. There is no place
> here for WeakReference.
>
> May be I don't understand your point here. I don't see a way how
> WeakReference can be used together with short lived objects.
>
> --
> Best regards,
> Ivan
>
> ---------------------------------------------------------------------
> 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
>
>
--
www.FaeLLe.com
www.VikramMohan.com
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Ivan Volosyuk <iv...@gmail.com>.
On 9/19/06, Oliver Deakin <ol...@googlemail.com> wrote:
> Ivan Volosyuk wrote:
> > On 9/19/06, Oliver Deakin <ol...@googlemail.com> wrote:
> >> Robin Garner wrote:
> >> >
> >> >>>
> >> >>> I don't understand. How can weak references help short-lived objects
> >> >>> reclaim?
> >> >>
> >> >> Really what I'm saying is that this is the closest thing we have to a
> >> >> hint to GC that objects can be collected soon - but it is not
> >> anything
> >> >> like a proper free() call. There is no immediate reclaim of memory,
> >> >> just the possibility that it will be reclaimed soon - and the object
> >> >> may be garbage collected before you are finished with it!
> >> >>
> >> >> Regards,
> >> >> Oliver
> >> >>
> >> >
> >> > Actually, it's kind of the other way around isn't it ? Nulling the
> >> > last pointer to an object tells the GC that it can collect it
> >> > (explicitly in the case of reference counting), whereas having a Weak
> >> > Reference to an object says 'please tell me when on-one else wants
> >> > this object', which results in the object staying around even longer.
> >>
> >> Isn't this only the case if you register the WeakReference with a
> >> ReferenceQueue?
> >> If you do not do that, then the GC can collect the referent when it
> >> wants, and you will
> >> just get a null back from a get() call on any WeakReference object.
> >> So I imagine that keeping the object weakly reachable and not
> >> registering it with
> >> a ReferenceQueue says to the GC "you are free to collect this referent
> >> object at the
> >> next collection if you wish".
> >
> > It is always better not to have any references to an object in heap
> > then to have a WeakReference to it.
>
> Yup, agreed!
>
> > The object without references is
> > simply garbage, while WeakReference is a kind of reference to it and
> > require handling - updating on object relocation, zeroing when object
> > no longer reachable.
>
> Agreed - but I wasn't comparing it to an object with no references. I was
> merely saying that rather than having a strong reference to a very short
> lived object, that will definitely not be garbage collected until the strong
> reference goes out of scope or is explicitly nullified, having only
> WeakReferences
> to the object could allow it to be collected ealier. I know it's not
> guaranteed,
> but there is a possibility. It's also probably not the best thing to do
> - it was
> just a comment on the ability to have short lived objects gc'ed earlier :)
Well, Oliver, if you have a strong reference to short-lived object,
you have it for a reason. This means that you do some actions with it.
It will be a failure when the reference to the object suddenly become
a null reference (what is normal for WeakReference). If you no longer
need that object - that means the live of it has just come to an end.
Short live :)
After that, no more need for WeakReference to the object. Before that,
hard reference is required by the algorithm used. There is no place
here for WeakReference.
May be I don't understand your point here. I don't see a way how
WeakReference can be used together with short lived objects.
--
Best regards,
Ivan
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects
quickly.
Posted by Oliver Deakin <ol...@googlemail.com>.
Ivan Volosyuk wrote:
> On 9/19/06, Oliver Deakin <ol...@googlemail.com> wrote:
>> Robin Garner wrote:
>> >
>> >>>
>> >>> I don't understand. How can weak references help short-lived objects
>> >>> reclaim?
>> >>
>> >> Really what I'm saying is that this is the closest thing we have to a
>> >> hint to GC that objects can be collected soon - but it is not
>> anything
>> >> like a proper free() call. There is no immediate reclaim of memory,
>> >> just the possibility that it will be reclaimed soon - and the object
>> >> may be garbage collected before you are finished with it!
>> >>
>> >> Regards,
>> >> Oliver
>> >>
>> >
>> > Actually, it's kind of the other way around isn't it ? Nulling the
>> > last pointer to an object tells the GC that it can collect it
>> > (explicitly in the case of reference counting), whereas having a Weak
>> > Reference to an object says 'please tell me when on-one else wants
>> > this object', which results in the object staying around even longer.
>>
>> Isn't this only the case if you register the WeakReference with a
>> ReferenceQueue?
>> If you do not do that, then the GC can collect the referent when it
>> wants, and you will
>> just get a null back from a get() call on any WeakReference object.
>> So I imagine that keeping the object weakly reachable and not
>> registering it with
>> a ReferenceQueue says to the GC "you are free to collect this referent
>> object at the
>> next collection if you wish".
>
> It is always better not to have any references to an object in heap
> then to have a WeakReference to it.
Yup, agreed!
> The object without references is
> simply garbage, while WeakReference is a kind of reference to it and
> require handling - updating on object relocation, zeroing when object
> no longer reachable.
Agreed - but I wasn't comparing it to an object with no references. I was
merely saying that rather than having a strong reference to a very short
lived object, that will definitely not be garbage collected until the strong
reference goes out of scope or is explicitly nullified, having only
WeakReferences
to the object could allow it to be collected ealier. I know it's not
guaranteed,
but there is a possibility. It's also probably not the best thing to do
- it was
just a comment on the ability to have short lived objects gc'ed earlier :)
Regards,
Oliver
>
> You cannot speedup object memory reclaming having WeakReference to it.
> --
> Regards,
> Ivan
>
> ---------------------------------------------------------------------
> 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
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Ivan Volosyuk <iv...@gmail.com>.
On 9/19/06, Oliver Deakin <ol...@googlemail.com> wrote:
> Robin Garner wrote:
> >
> >>>
> >>> I don't understand. How can weak references help short-lived objects
> >>> reclaim?
> >>
> >> Really what I'm saying is that this is the closest thing we have to a
> >> hint to GC that objects can be collected soon - but it is not anything
> >> like a proper free() call. There is no immediate reclaim of memory,
> >> just the possibility that it will be reclaimed soon - and the object
> >> may be garbage collected before you are finished with it!
> >>
> >> Regards,
> >> Oliver
> >>
> >
> > Actually, it's kind of the other way around isn't it ? Nulling the
> > last pointer to an object tells the GC that it can collect it
> > (explicitly in the case of reference counting), whereas having a Weak
> > Reference to an object says 'please tell me when on-one else wants
> > this object', which results in the object staying around even longer.
>
> Isn't this only the case if you register the WeakReference with a
> ReferenceQueue?
> If you do not do that, then the GC can collect the referent when it
> wants, and you will
> just get a null back from a get() call on any WeakReference object.
> So I imagine that keeping the object weakly reachable and not
> registering it with
> a ReferenceQueue says to the GC "you are free to collect this referent
> object at the
> next collection if you wish".
It is always better not to have any references to an object in heap
then to have a WeakReference to it. The object without references is
simply garbage, while WeakReference is a kind of reference to it and
require handling - updating on object relocation, zeroing when object
no longer reachable.
You cannot speedup object memory reclaming having WeakReference to it.
--
Regards,
Ivan
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects
quickly.
Posted by Oliver Deakin <ol...@googlemail.com>.
Robin Garner wrote:
>
>>>
>>> I don't understand. How can weak references help short-lived objects
>>> reclaim?
>>
>> Really what I'm saying is that this is the closest thing we have to a
>> hint to GC that objects can be collected soon - but it is not anything
>> like a proper free() call. There is no immediate reclaim of memory,
>> just the possibility that it will be reclaimed soon - and the object
>> may be garbage collected before you are finished with it!
>>
>> Regards,
>> Oliver
>>
>
> Actually, it's kind of the other way around isn't it ? Nulling the
> last pointer to an object tells the GC that it can collect it
> (explicitly in the case of reference counting), whereas having a Weak
> Reference to an object says 'please tell me when on-one else wants
> this object', which results in the object staying around even longer.
Isn't this only the case if you register the WeakReference with a
ReferenceQueue?
If you do not do that, then the GC can collect the referent when it
wants, and you will
just get a null back from a get() call on any WeakReference object.
So I imagine that keeping the object weakly reachable and not
registering it with
a ReferenceQueue says to the GC "you are free to collect this referent
object at the
next collection if you wish".
Regards,
Oliver
>
> cheers,
> Robin
>
> ---------------------------------------------------------------------
> 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
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived
objects quickly.
Posted by Robin Garner <ro...@anu.edu.au>.
>>
>> I don't understand. How can weak references help short-lived objects
>> reclaim?
>
> Really what I'm saying is that this is the closest thing we have to a
> hint to GC that objects can be collected soon - but it is not anything
> like a proper free() call. There is no immediate reclaim of memory,
> just the possibility that it will be reclaimed soon - and the object
> may be garbage collected before you are finished with it!
>
> Regards,
> Oliver
>
Actually, it's kind of the other way around isn't it ? Nulling the last
pointer to an object tells the GC that it can collect it (explicitly in
the case of reference counting), whereas having a Weak Reference to an
object says 'please tell me when on-one else wants this object', which
results in the object staying around even longer.
cheers,
Robin
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects
quickly.
Posted by Oliver Deakin <ol...@googlemail.com>.
Xiao-Feng Li wrote:
> On 9/18/06, Oliver Deakin <ol...@googlemail.com> wrote:
>> Xiao-Feng Li wrote:
>> > On 9/14/06, Jimmy, Jing Lv <fi...@gmail.com> wrote:
>> >> Interesting topic, I'm still dreaming of "free()" in Java (This dream
>> >> begins at the very beginning when I see Java, as C/C++ is my first
>> >> program language )However, it seems RI will never give us
>> "free()". :)
>> >>
>> >> Only a thought, Java may offer a key word "temp", indicating that
>> this
>> >> variety can be freed at once.
>> >
>> >
>> > Well, it is not so easy to support "free()" in JVM as it looks like,
>> > and may not really bring benefit. Even worse, it may introduce unsafe
>> > code, which was one of the major design goals of Java/JVM. That said,
>> > I agree that some hints by programmer to assist GC might be an
>> > interesting topic.
>>
>> There are always weak references to help out with short lived objects -
>> you know they will be collected fairly soon (should be within a few
>> gc cycles) - and soft references for longer lived ones. That's
>> about as close to free() as youll get for now!
>>
>> Regards,
>> Oliver
>>
>
> I don't understand. How can weak references help short-lived objects
> reclaim?
Really what I'm saying is that this is the closest thing we have to a
hint to GC that objects can be collected soon - but it is not anything
like a proper free() call. There is no immediate reclaim of memory,
just the possibility that it will be reclaimed soon - and the object
may be garbage collected before you are finished with it!
Regards,
Oliver
>
> Thanks,
> xiaofeng
>
> ---------------------------------------------------------------------
> 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
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 9/18/06, Oliver Deakin <ol...@googlemail.com> wrote:
> Xiao-Feng Li wrote:
> > On 9/14/06, Jimmy, Jing Lv <fi...@gmail.com> wrote:
> >> Interesting topic, I'm still dreaming of "free()" in Java (This dream
> >> begins at the very beginning when I see Java, as C/C++ is my first
> >> program language )However, it seems RI will never give us "free()". :)
> >>
> >> Only a thought, Java may offer a key word "temp", indicating that this
> >> variety can be freed at once.
> >
> >
> > Well, it is not so easy to support "free()" in JVM as it looks like,
> > and may not really bring benefit. Even worse, it may introduce unsafe
> > code, which was one of the major design goals of Java/JVM. That said,
> > I agree that some hints by programmer to assist GC might be an
> > interesting topic.
>
> There are always weak references to help out with short lived objects -
> you know they will be collected fairly soon (should be within a few
> gc cycles) - and soft references for longer lived ones. That's
> about as close to free() as youll get for now!
>
> Regards,
> Oliver
>
I don't understand. How can weak references help short-lived objects reclaim?
Thanks,
xiaofeng
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects
quickly.
Posted by Oliver Deakin <ol...@googlemail.com>.
Xiao-Feng Li wrote:
> On 9/14/06, Jimmy, Jing Lv <fi...@gmail.com> wrote:
>> Interesting topic, I'm still dreaming of "free()" in Java (This dream
>> begins at the very beginning when I see Java, as C/C++ is my first
>> program language )However, it seems RI will never give us "free()". :)
>>
>> Only a thought, Java may offer a key word "temp", indicating that this
>> variety can be freed at once.
>
>
> Well, it is not so easy to support "free()" in JVM as it looks like,
> and may not really bring benefit. Even worse, it may introduce unsafe
> code, which was one of the major design goals of Java/JVM. That said,
> I agree that some hints by programmer to assist GC might be an
> interesting topic.
There are always weak references to help out with short lived objects -
you know they will be collected fairly soon (should be within a few
gc cycles) - and soft references for longer lived ones. That's
about as close to free() as youll get for now!
Regards,
Oliver
> Thanks,
> xiaofeng
>
>> --
>>
>> Best Regards!
>>
>> Jimmy, Jing Lv
>> 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
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 9/14/06, Xiao-Feng Li <xi...@gmail.com> wrote:
> Well, it is not so easy to support "free()" in JVM as it looks like,
> and may not really bring benefit. Even worse, it may introduce unsafe
> code, which was one of the major design goals of Java/JVM. That said,
Typo here: "which was ..." --> "well typesafy was ...", although I
think everybody knows what I mean. :-)
> I agree that some hints by programmer to assist GC might be an
> interesting topic.
>
> Thanks,
> xiaofeng
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 9/14/06, Jimmy, Jing Lv <fi...@gmail.com> wrote:
> Interesting topic, I'm still dreaming of "free()" in Java (This dream
> begins at the very beginning when I see Java, as C/C++ is my first
> program language )However, it seems RI will never give us "free()". :)
>
> Only a thought, Java may offer a key word "temp", indicating that this
> variety can be freed at once.
Well, it is not so easy to support "free()" in JVM as it looks like,
and may not really bring benefit. Even worse, it may introduce unsafe
code, which was one of the major design goals of Java/JVM. That said,
I agree that some hints by programmer to assist GC might be an
interesting topic.
Thanks,
xiaofeng
> --
>
> Best Regards!
>
> Jimmy, Jing Lv
> 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
Re: [General VM] GC strategy:how to garbage collect short-lived objects
quickly.
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Jimmy, Jing Lv wrote:
> Leo Li 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?
>>
>
> Interesting topic, I'm still dreaming of "free()" in Java (This dream
> begins at the very beginning when I see Java, as C/C++ is my first
> program language )However, it seems RI will never give us "free()". :)
No :)
>
> Only a thought, Java may offer a key word "temp", indicating that this
> variety can be freed at once.
How can you tell? You need to be sure that value of the temp reference
isn't held by anyone else. You need to make sure it doesn't escape the
scope...
geir
>
>> 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
Re: [General VM] GC strategy:how to garbage collect short-lived objects
quickly.
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Leo Li 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?
>
Interesting topic, I'm still dreaming of "free()" in Java (This dream
begins at the very beginning when I see Java, as C/C++ is my first
program language )However, it seems RI will never give us "free()". :)
Only a thought, Java may offer a key word "temp", indicating that this
variety can be freed at once.
> Leo Li
> China Software Development Lab, IBM
>
--
Best Regards!
Jimmy, Jing Lv
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Dec 28, 2006, at 6:10 AM, Tim Ellison wrote:
> Thorbjørn Ravn Andersen wrote:
>> Leo Li skrev den 14-09-2006 05:08:
>>> 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?
>>
>> We experimented with this on a Sun box running Sun JDK where one
>> of the
>> more exotic GC's in the server VM used parallel garbage collection
>> without stopping the world for the program executed.
>> This was needed in a large scale J2EE application to avoid user
>> perceptible pauses. ''
>
> This is a common requirement, and there is a whole science around
> optimizing the throughput / speed of the memory manager.
>
> With the greatest of respect to the MM researchers who are making
> great
> progress, the commercial response so far seems to be a bunch of
> heuristics and knobs to tune, e.g. "Understanding the Garbage
> Collector"
> http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/topic/
> com.ibm.java.doc.diagnostics.50/html/contents.html#ToC_27
>
What, you don't believe that "Out of the Box" is an imperative
configuration for enterprise customers? ;)
geir
Re: [General VM] GC strategy:how to garbage collect short-lived objects
quickly.
Posted by Tim Ellison <t....@gmail.com>.
Thorbjørn Ravn Andersen wrote:
> Leo Li skrev den 14-09-2006 05:08:
>> 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?
>
> We experimented with this on a Sun box running Sun JDK where one of the
> more exotic GC's in the server VM used parallel garbage collection
> without stopping the world for the program executed.
> This was needed in a large scale J2EE application to avoid user
> perceptible pauses. ''
This is a common requirement, and there is a whole science around
optimizing the throughput / speed of the memory manager.
With the greatest of respect to the MM researchers who are making great
progress, the commercial response so far seems to be a bunch of
heuristics and knobs to tune, e.g. "Understanding the Garbage Collector"
http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/topic/com.ibm.java.doc.diagnostics.50/html/contents.html#ToC_27
Regards,
Tim
Re: [General VM] GC strategy:how to garbage collect short-lived objects
quickly.
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
Leo Li skrev den 14-09-2006 05:08:
> 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?
We experimented with this on a Sun box running Sun JDK where one of the
more exotic GC's in the server VM used parallel garbage collection
without stopping the world for the program executed.
This was needed in a large scale J2EE application to avoid user
perceptible pauses. ''
--
Thorbjørn
Re: [General VM] GC strategy:how to garbage collect short-lived
objects quickly.
Posted by Robin Garner <ro...@anu.edu.au>.
Egor Pasko wrote:
> On the 0x1E4 day of Apache Harmony Alexey Varlamov wrote:
>> Just a wild idea: a smart JIT could hint a GC during allocation if an
>> object is expected to be short-lived so the GC could allocate it in a
>> special space,
>
> if a JIT can prove that the object is local, it can allocate it on
> stack almost without help of VM. An imprecise estimation of
> short-liveness is a kind of magic. What heuristics can we use? Small
> objects live shortly? :)
>
Stack allocation generally performs more poorly than heap allocation.
In fact the cheapest place to allocate a short-lived object is in the
nursery where all objects are allocated - the cost of allocation is
simply incrementing a counter and doing a bounds check.
Identifying objects (usually call sites) that are likely to live for a
long time, and allocating them directly into the mature space is called
pre-tenuring, and there has been a lot of work done on that.
ALl this can be done by the JIT at run-time, although feedback from the
VM via sampling can be useful.
cheers
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects
quickly.
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Egor Pasko wrote:
> On the 0x1E4 day of Apache Harmony Alexey Varlamov wrote:
>> Just a wild idea: a smart JIT could hint a GC during allocation if an
>> object is expected to be short-lived so the GC could allocate it in a
>> special space,
>
> if a JIT can prove that the object is local, it can allocate it on
> stack almost without help of VM. An imprecise estimation of
> short-liveness is a kind of magic. What heuristics can we use? Small
> objects live shortly? :)
I've often thought about this. I thought hardware support was needed to
make this efficient.
geir
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x1E4 day of Apache Harmony Alexey Varlamov wrote:
> Just a wild idea: a smart JIT could hint a GC during allocation if an
> object is expected to be short-lived so the GC could allocate it in a
> special space,
if a JIT can prove that the object is local, it can allocate it on
stack almost without help of VM. An imprecise estimation of
short-liveness is a kind of magic. What heuristics can we use? Small
objects live shortly? :)
--
Egor Pasko, Intel Managed Runtime Division
---------------------------------------------------------------------
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
Re: [General VM] GC strategy:how to garbage collect short-lived objects quickly.
Posted by Alexey Varlamov <al...@gmail.com>.
Just a wild idea: a smart JIT could hint a GC during allocation if an
object is expected to be short-lived so the GC could allocate it in a
special space, recycled quickly and frequently. I guess it could be
not too expensive estimation for optimizing JIT, based on performed
escape analysis or such. Or the contrary, JIT also may hint that a
particular object is potencially long-lived one (say values assigned
to static fields).
I'm not a GC guy, maybe there are similar techniques already investigated :)
2006/9/14, Leo Li <li...@gmail.com>:
> 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