What are the conflicting points between Class-Data Sharing and ParNew/CMS/ParallelScavenge/G1?

[Paul Hohensee]

CDS stores a non-relocatable permgen image, so in order to use it, the
jvm must be able to load it at the same address it occupied when it was
generated.  If I remember correctly, serial and CMS/Parnew/G1 put the
permgen above the old/young gens in the address space, while the
parallel collectors put it below the old/young gens.  There can be issues
with trying to map the permgen in the latter case, esp. on windows where
it's already a pain to find contiguous virtual address space for the heap
(dlls are loaded all over the place).  I believe CDS more-or-less works
with CMS/Parnew/G1, but no one's had time to get all the bugs out.
We'd welcome help. :)

Paul

On 4/14/11 5:14 AM, Krystal Mok wrote:
> Hi all,
>
> I've had this doubt for quite a long time but was too shy to ask on 
> this list. Anyway, here I go:
>
> According to the logic in hotspot/src/share/vm/runtime/arguments.cpp, 
> CDS doesn't work with ParNew/CMS/PS/G1. That means only serial GCs 
> works with CDS.
> I'd like to know, what are the conflicting points between CDS and 
> these parallel/concurrent GCs? Are there any plans to resolve the 
> conflicts, or are there any suggestions on how the conflicts would be 
> resolved?
>
> Sincerely,
> Kris Mok
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20110427/5509dfc1/attachment.htm>