On 10/29/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
Weldon, the problem is, there is no well-established parallel
compaction algorithms. So far the best known work are 1. SUN's work;
2. IBM's work and 3. Compressor. No one knows which one is the best
for different workloads. We have to identify
Hi,
Does anyone have an accessible reference to the OOPSLA paper An efficient
parallel heap compaction algorithm by Abuaiadh, Ossia, Petrank,
Silbershtein that is cited as a reference in the paper Xiao Feng points
to below? All my google searches lead to the ACM Portal :-)
Thanks,
Rana
On
Is it the same?
http://citeseer.ist.psu.edu/630853.html
or
http://www.cs.technion.ac.il/~erez/Papers/parallel-compaction.ps
On 10/30/06, Rana Dasgupta [EMAIL PROTECTED] wrote:
Hi,
Does anyone have an accessible reference to the OOPSLA paper An
efficient
parallel heap compaction algorithm by
Perfect, thanks Mikhail
On 10/30/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Is it the same?
http://citeseer.ist.psu.edu/630853.html
or
http://www.cs.technion.ac.il/~erez/Papers/parallel-compaction.ps
On 10/30/06, Rana Dasgupta [EMAIL PROTECTED] wrote:
Hi,
Does anyone have an accessible
Are IBM's and Sun's are know to work well for production loads?
Xiao-Feng Li wrote:
Weldon, the problem is, there is no well-established parallel
compaction algorithms. So far the best known work are 1. SUN's work;
2. IBM's work and 3. Compressor. No one knows which one is the best
for
On 10/30/06, Weldon Washburn [EMAIL PROTECTED] wrote:
On 10/29/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
Weldon, the problem is, there is no well-established parallel
compaction algorithms. So far the best known work are 1. SUN's work;
2. IBM's work and 3. Compressor. No one knows which one
On 10/31/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Are IBM's and Sun's are know to work well for production loads?
Don't know. Probably yes. It's claimed that SUN's work is the first
parallel compaction design [1] and IBM's work is an improvement [2],
while Compressor is a further
This is a good idea, Ivan :-) We need implement at least a fall back
parallel algorithm for Compressor in case its required vitual space is
not enough.
Thanks,
xiaofeng
On 10/29/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
Excellent algorithm. I think it makes sense to implement it. If we
can't
On 10/29/06, Rana Dasgupta [EMAIL PROTECTED] wrote:
Xiao Feng,
I will read the reference to understand what are the compressor
advantages, and how the algorithm is implemented, thanks.
Even when you have 1GB of physical memory, is there not an overhead of page
faults?
Yes, I agree that page
Excellent algorithm. I think it makes sense to implement it. If we
can't use on 32 bit machines with plenty of ram, we can use it on 64
bit machines.
What about enabling the algorithm at runtime if required conditions
are met, otherwise falling back to some other algorithm?
--
Ivan
On 10/28/06,
Xiao Feng,
I will read the reference to understand what are the compressor
advantages, and how the algorithm is implemented, thanks.
Even when you have 1GB of physical memory, is there not an overhead of page
faults?
Is it an option to compact the heap in parts and/or to increase the number
of
Hi, all, the plan for GCv5 parallel compaction is to apply the idea of
Compressor [1]. But it has an issue I want to discuss with you.
Compressor needs to reserve an unmapped virtual space for compaction.
The size of the reserved part is the same as that of copy reserve
space in a semi-space
12 matches
Mail list logo
