RFR (M): JDK-8038587: [TESTBUG] Create CDS tests to exercise region sizes and classlist

[Ioi Lam]

Hi Misha,

SharedBaseAddress.java:

    During dumping, the VM will first try to map at the address
    specified by -XX:SharedBaseAddress. However, if this fails (another
    mapping already exists there, the VM will simply map a random
    address (as selected by the OS).

    I am not sure if there's anything you need to check here, but just FYI.

SpaceUtilizationCheck:

    It will probably never happen, but in the rare case you may have
    100% utilization. So for robustness, you may want to handle this in

        result.add(input.substring(m.start() + 1, m.start() + 3 ));

    Also, 75% may be a good value for 32-bit (where available address
    space is scarce), but for 64-bit, I think it's OK to have a low
    utilization (i.e., a large default size) so that it's easier for the
    user to try different class list without having to worry about the
    region sizes.

Thanks

- Ioi




On 5/15/14, 4:15 PM, Mikhailo Seledtsov wrote:
> Hi David, team,
>
>  After  more discussions on the usefulness and stability of the 
> ClassListExerciser test with the team, we have decided that this test 
> is not that useful. Thank you David for your comments again.
> I have kept two other tests, and added a new test: 
> SharedBaseAddress.java, which was in the plans and is intended to 
> exercise various values for the SharedBaseAddress CL flag.
>
> The updated webrev can be found at: 
> http://cr.openjdk.java.net/~mseledtsov/8038587/webrev.01/
> The bug name has been changed to: [TESTBUG] Create CDS tests to 
> exercise region sizes and base address
>
> Thank you,
> Misha
>
> On 4/2/2014 7:55 PM, Mikhailo Seledtsov wrote:
>> David,
>>
>>  Thank you. I will rework ClassListExerciser test to take your 
>> comments into consideration, and will submit a new webrev.
>>
>> Misha
>>
>> On 4/1/2014 9:52 PM, David Holmes wrote:
>>> On 2/04/2014 7:06 AM, Mikhailo Seledtsov wrote:
>>>> Hi David,
>>>>
>>>>   Thank you for review and your feedback.
>>>>
>>>> The intent of this test is sanity check of basic functionality, making
>>>> sure the shared classes are loaded w/o crashes or errors. Even though
>>>> creating a shared archive with -Xshare:dump does exercise loading 
>>>> of the
>>>> classes from the classlist, I believe SQE should verify it, by
>>>> explicitly performing this operation. In my experience I have found 
>>>> that
>>>> basic tests often find interesting bugs.
>>>>
>>>> I did drop the attempt to instantiate classes, because  the amount of
>>>> classes in the class list that have default constructors and 
>>>> instantiate
>>>> successfully is quite small, and not worth the trouble. Many classes
>>>> fail instantiation due to the absence of UI, or other valid reasons.
>>>
>>> Okay. Dropping that seems to alleviate most of my concerns.
>>>
>>>> What I have found, however, as part of this exercise, is that the
>>>> default SE classlist is optimized for the client, not the server.
>>>>
>>>> As for classes that are part of the classlist, but are really missing
>>>> from rt.jar: will you consider this to be a bug?
>>>
>>> No. The default classlist, as you note is defined for a particular 
>>> scenario - at the moment "client" apps. But many of those classes 
>>> are not present in Compact Profiles. So unless/until we have 
>>> customized default classlists for Compact Profiles, missing classes 
>>> can be expected. I don't see this as an issue that warrants such 
>>> customized classlists.
>>>
>>> Thanks,
>>> David
>>>
>>>>
>>>> Thank you,
>>>> Misha
>>>>
>>>>
>>>> On 4/1/2014 1:46 AM, David Holmes wrote:
>>>>> Hi Misha,
>>>>>
>>>>> On 28/03/2014 5:34 AM, Mikhailo Seledtsov wrote:
>>>>>> Please review these 3 new CDS tests, an ongoing effort in 
>>>>>> implementation
>>>>>> of the CDS test specification.
>>>>>>
>>>>>>      JBS: https://bugs.openjdk.java.net/browse/JDK-8038587
>>>>>>      Webrev: 
>>>>>> http://cr.openjdk.java.net/~mseledtsov/8038587/webrev.00/
>>>>>>      Testing:
>>>>>>          Local testing on multiple platforms
>>>>>>          JPRT to exercise the added tests:
>>>>>> 2014-03-27-184953.mseledtsov.cds (PASS)
>>>>>>          These tests found 2 bugs, and one potential issue
>>>>>
>>>>> I don't quite get the point of the ClassListExerciser test. The
>>>>> classlist may well contain classes that do not exist, or that can not
>>>>> be instantiated in the test context, even if they have a no-arg
>>>>> constructor. Simply creating an archive "exercises" the classlist, so
>>>>> I'm really not sure what this test is intending to test.
>>>>>
>>>>> Also this test won't work with SE Embedded as we have a customized
>>>>> default classlist for the Embedded stack.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Thank you,
>>>>>> Misha
>>>>
>>
>