Review Request: 8029921: CDS should allow user specify their own classlist

[David Holmes]

On 17/01/2014 1:15 PM, Jiangli Zhou wrote:
> Hi,
>
> Thanks very much for everyone's comments/inputs.
>
> I have to say that I share the same view as Coleen on this. There are
> existing CDS related options, which are grouped into:
>
>   -Xshare:<dump/auto/on/off>
>
> and
>
>   -XX: Shared* options
>
> The -Xshare: options is to dump/disable/enable CDS archive, and the
> other options are more fine-grained control for CDS functionality. I
> would think the new classlist option fits into the second category, and
> it's better to not differ it from the rest of the -XX:shared* options.

Did you see my response to that? The difference is the Xshare flags 
control the CDS feature whereas the XX flags control details of the 
implementation of CDS in hotspot.

So is providing a custom class list a feature of CDS or just something 
the hotspot implementation provides? I think it should be the former, 
but initially can be the latter.

> There were questions raised as part of the discussion, such as will CDS
> support multiple archives. Those are still open-ended questions at this
> point, and we don't have a clear answer yet. At stage I think
> -XX:SharedClassListFile serves our current needs, which is to allow user
> specify their own classlist. A redesign of the CDS options can be done
> later when we have more clear picture of the new CDS functionality.

Yes let's simply stick with -XX:SharedClassListFile for now.

David
-----


> Thanks,
> Jiangli
>
>
> On 01/15/2014 07:54 PM, Ioi Lam wrote:
>>
>> On 1/15/14, 7:22 AM, Bob Vandette wrote:
>>> On Jan 15, 2014, at 1:16 AM, David Holmes <David.Holmes at oracle.com>
>>> wrote:
>>>
>>>> Hi Jiangli,
>>>>
>>>> On 15/01/2014 3:19 AM, Jiangli Zhou wrote:
>>>>> Hi David,
>>>>>
>>>>> Thanks for the suggestion. How does it work with the existing
>>>>> -Xshare:dump/auto/on option? Is it possible to combine multiple
>>>>> sub-options, so it would be something like
>>>>> -Xshare:dump,classlist=XXXX?
>>>> Right - the classlist is only associated with dumping so some
>>>> modification to -Xshare:dump would be the way to do it. Exactly how
>>>> depends on what we think we may want to do in the future. For
>>>> example do we want to allow control over the name of the archive? If
>>>> so we might want something like:
>>>>
>>>> -Xshare:dump:in=xxx,out=yyy
>>>>
>>>> though I'm not sure of the best syntax/grammar to use for these kind
>>>> of compound options.
>>>>
>>>> At this stage we only want to define the class list file name so we
>>>> don't need to generalize too far, but we also want to choose a
>>>> syntax that doesn't preclude potential future changes.
>>>>
>>>> Comments from runtime folk (Hi Coleen!) would be appreciated. :)
>>> Do we want the ability to select different archives at startup that
>>> have been dumped with different class lists?
>>>
>>> If so, then we'd need a way to specify the archive for -Xshare:on, ie
>>> -Xshare:on,archive=xxxx
>>>
>>> -Xshare:dump,list=xxx,archive=yyy
>>> -Xshare:on,archive=yyy
>>>
>>> Otherwise if we don't want to support multiple archives, this option
>>> would be enough.
>>>
>>> -Xshare:dump,list=xxx
>>>
>>> Can we make the classlist easy to generate but either supporting  the
>>> -verbose:class output format or
>>> by adding a new -verbose:classlist option, please?
>>>
>>>
>> I am not fond of such comma-separated lists in general. They just make
>> the VM more complicated with a lot of parsing and syntax checks (which
>> come for free with the -XX options). They also make the user's life
>> more complicated. I.e., how would you quote space, comma and equal
>> signs, which may be part of file names?
>>
>> - Ioi
>>
>