On 10/1/06, FaeLLe [EMAIL PROTECTED] 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,
-
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 [EMAIL
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
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.
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
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
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
Xiao-Feng Li wrote:
On 9/18/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Xiao-Feng Li wrote:
On 9/14/06, Jimmy, Jing Lv [EMAIL PROTECTED] 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
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
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
On 9/19/06, Oliver Deakin [EMAIL PROTECTED] 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
Ivan Volosyuk wrote:
On 9/19/06, Oliver Deakin [EMAIL PROTECTED] 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 -
On 9/19/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
On 9/19/06, Oliver Deakin [EMAIL PROTECTED] 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
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?
Xiao-Feng Li wrote:
On 9/14/06, Jimmy, Jing Lv [EMAIL PROTECTED] 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,
On 9/18/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Xiao-Feng Li wrote:
On 9/14/06, Jimmy, Jing Lv [EMAIL PROTECTED] 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
Hi, Weldon:
Thank you. I can read the code:)
Good luck!
On 9/16/06, Weldon Washburn [EMAIL PROTECTED] wrote:
On 9/14/06, Leo Li [EMAIL PROTECTED] wrote:
Hi, Xiao-Feng:
It will be great if VM can adjust its strategy adaptively. However,
as
a programmer, I would like to have some
On 9/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] 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
On 9/14/06, Leo Li [EMAIL PROTECTED] wrote:
Hi, Xiao-Feng:
It will be great if VM can adjust its strategy adaptively. However, as
a programmer, I would like to have some method to instruct the GC
strategy.
If I can, I tend to control things and get definite result, whenever I am
programming
On 9/14/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Xiao-Feng Li wrote:
On 9/15/06, Geir Magnusson Jr. [EMAIL PROTECTED] 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
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
Weldon Washburn wrote:
On 9/14/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Xiao-Feng Li wrote:
On 9/15/06, Geir Magnusson Jr. [EMAIL PROTECTED] 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
On 9/15/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
On 9/15/06, Geir Magnusson Jr. [EMAIL PROTECTED] 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
On 9/15/06, Ivan Volosyuk [EMAIL PROTECTED] 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
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.
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
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
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
Hi,Egor:
On 14 Sep 2006 12:30:49 +0700, Egor Pasko [EMAIL PROTECTED] 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.
Leo Li wrote:
Hi,Egor:
On 14 Sep 2006 12:30:49 +0700, Egor Pasko [EMAIL PROTECTED] 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
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
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
On 9/14/06, Jimmy, Jing Lv [EMAIL PROTECTED] 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
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
On 9/14/06, Xiao-Feng Li [EMAIL PROTECTED] 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
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
On 9/15/06, Ivan Volosyuk [EMAIL PROTECTED] 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
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 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
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
On 9/15/06, Geir Magnusson Jr. [EMAIL PROTECTED] 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
Xiao-Feng Li wrote:
On 9/15/06, Geir Magnusson Jr. [EMAIL PROTECTED] 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
On 9/15/06, Geir Magnusson Jr. [EMAIL PROTECTED] 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
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
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
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
46 matches
Mail list logo
