RFR(M): 8185436: jtreg: introduce keyword to disable cds tests
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Thu Aug 10 04:43:12 UTC 2017
Hi mikhailo,
Thanks for sponsoring!
Best regards, götz
> Am 08.08.2017 um 20:05 schrieb mikhailo <mikhailo.seledtsov at oracle.com>:
>
> Hi Goetz,
>
> I will test your patch and then will do a sponsor push.
>
>
> Thank you,
>
> Mikhailo
>
>
>> On 08/08/2017 02:00 AM, Lindenmaier, Goetz wrote:
>> Hi Mikhailo,
>>
>> yes, I please need a sponsor.
>> Thanks for the help with working on this change!
>> I added Ioi as reviewer in the webrev, so the patches
>> can be pushed as is.
>>
>> Thanks,
>> Goetz.
>>
>>> -----Original Message-----
>>> From: Mikhailo Seledtsov [mailto:mikhailo.seledtsov at oracle.com]
>>> Sent: Dienstag, 8. August 2017 00:01
>>> To: Ioi Lam <ioi.lam at oracle.com>
>>> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Igor Ignatyev
>>> <igor.ignatyev at oracle.com>; hotspot-runtime-dev at openjdk.java.net
>>> Subject: Re: RFR(M): 8185436: jtreg: introduce keyword to disable cds tests
>>>
>>> Hi Goetz,
>>>
>>> Please let me know if you need a sponsor for this change.
>>>
>>> Mikhailo
>>>
>>>> On 8/7/17, 10:44 AM, Ioi Lam wrote:
>>>> Looks good to me, too. Reviewed.
>>>>
>>>> Thanks
>>>>
>>>> - Ioi
>>>>
>>>>
>>>>
>>>>> On 8/7/17 9:46 AM, Mikhailo Seledtsov wrote:
>>>>> The change looks good to me,
>>>>>
>>>>> Thank you,
>>>>> Mikhailo
>>>>>
>>>>>> On 8/7/17, 1:02 AM, Lindenmaier, Goetz wrote:
>>>>>> Hi,
>>>>>>
>>>>>> webrev with Whitebox:
>>>>>> http://cr.openjdk.java.net/~goetz/wr17/8185436-cdsKey/webrev.04/
>>>>>> http://cr.openjdk.java.net/~goetz/wr17/8185436-cdsKey/webrev.04-hs/
>>>>>>
>>>>>> I don't see so much of a difference to throwing an exception, if
>>>>>> Whitebox is not properly implemented you get one, anyways:
>>>>>> Exception in thread "main" java.lang.UnsatisfiedLinkError:
>>>>>> sun.hotspot.WhiteBox.isCDSIncludedInVmBuild()Z
>>>>>> at sun.hotspot.WhiteBox.isCDSIncludedInVmBuild(Native Method)
>>>>>> Maybe it's a bit less likely to break, though.
>>>>>>
>>>>>> I'm fine with this, too.
>>>>>>
>>>>>> Best regards,
>>>>>> Goetz.,
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Mikhailo Seledtsov [mailto:mikhailo.seledtsov at oracle.com]
>>>>>>> Sent: Freitag, 4. August 2017 21:35
>>>>>>> To: Ioi Lam<ioi.lam at oracle.com>; Lindenmaier, Goetz
>>>>>>> <goetz.lindenmaier at sap.com>; Igor Ignatyev<igor.ignatyev at oracle.com>
>>>>>>> Cc: hotspot-runtime-dev at openjdk.java.net
>>>>>>> Subject: Re: RFR(M): 8185436: jtreg: introduce keyword to disable
>>>>>>> cds tests
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have an alternative solution that is IMO rather simple,
>>>>>>> reliable
>>>>>>> and will
>>>>>>> solve some issues we discussed (e.g. no need to throw
>>>>>>> exceptions, no
>>>>>>> need to handle failure to map an archive).
>>>>>>> The proposed solution uses White Box test API to determine
>>>>>>> whether VM
>>>>>>> is compiled with INCLUDE_CDS on or off.
>>>>>>> I implemented and tested it today, it works for me.
>>>>>>>
>>>>>>> The patch is attached. Please let me know what you think.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Mikhailo
>>>>>>>
>>>>>>>> On 8/3/17, 11:39 PM, Ioi Lam wrote:
>>>>>>>> Hi Goetz,
>>>>>>>>
>>>>>>>> Instead of testing -Xshare:on, I think you should test with
>>>>>>>> -Xshare:auto, which sets the flags
>>>>>>>>
>>>>>>>> UseSharedSpaces = true
>>>>>>>> RequireSharedSpaces = false
>>>>>>>>
>>>>>>>> and will reliably print "Shared spaces are not supported in this VM"
>>>>>>>> if-and-only-if INCLUDE_CDS is disabled (see arguments.cpp):
>>>>>>>>
>>>>>>>>
>>>>>>>> #if !INCLUDE_CDS
>>>>>>>> if (DumpSharedSpaces || RequireSharedSpaces) {
>>>>>>>> jio_fprintf(defaultStream::error_stream(),
>>>>>>>> "Shared spaces are not supported in this VM\n");
>>>>>>>> return JNI_ERR;
>>>>>>>> }
>>>>>>>> if ((UseSharedSpaces&& FLAG_IS_CMDLINE(UseSharedSpaces)) ||
>>>>>>>> log_is_enabled(Info, cds)) {
>>>>>>>> warning("Shared spaces are not supported in this VM");
>>>>>>>> FLAG_SET_DEFAULT(UseSharedSpaces, false);
>>>>>>>> LogConfiguration::configure_stdout(LogLevel::Off, true,
>>>>>>>> LOG_TAGS(cds));
>>>>>>>> }
>>>>>>>> no_shared_spaces("CDS Disabled");
>>>>>>>> #endif // INCLUDE_CDS
>>>>>>>>
>>>>>>>>
>>>>>>>> That way, you don't need to test any other output message or exit
>>>>>>>> conditions(such as mapping error).
>>>>>>>>
>>>>>>>>
>>>>>>>> E.g.:
>>>>>>>>
>>>>>>>> ioilinux /jdk/iter/build/linux-x64$ ./images/jdk/bin/java
>>>>>>>> -Xshare:auto
>>>>>>>> -version
>>>>>>>> java version "10-internal"
>>>>>>>> Java(TM) SE Runtime Environment (build
>>>>>>>> 10-internal+0-2017-08-04-0614567.iklam.iter)
>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build
>>>>>>>> 10-internal+0-2017-08-04-0614567.iklam.iter, mixed mode)
>>>>>>>>
>>>>>>>>
>>>>>>>> ioilinux /jdk/iter/build/linux-x64$ ./images/jdk/bin/java
>>>>>>>> -XXaltjvm=minimal -Xshare:auto -version
>>>>>>>> Java HotSpot(TM) 64-Bit Minimal VM warning: Shared spaces are not
>>>>>>>> supported in this VM
>>>>>>>> java version "10-internal"
>>>>>>>> Java(TM) SE Runtime Environment (build
>>>>>>>> 10-internal+0-2017-08-04-0614567.iklam.iter)
>>>>>>>> Java HotSpot(TM) 64-Bit Minimal VM (build
>>>>>>>> 10-internal+0-2017-08-04-0614567.iklam.iter, mixed mode)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> - Ioi
>>>>>>>>
>>>>>>>>> On 8/3/17 10:58 PM, Lindenmaier, Goetz wrote:
>>>>>>>>> Hi Mikhailo,
>>>>>>>>>
>>>>>>>>> I put in your version of vmCDS() into this new webrev.
>>>>>>>>> I also had to update the list of tests marked in hotspot,
>>>>>>>>> as tests were removed and added in between, and resolved
>>>>>>>>> it against the aot change:
>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr17/8185436-cdsKey/webrev.03/
>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr17/8185436-cdsKey/webrev.03-hs/
>>>>>>>>>
>>>>>>>>> I don't think it's a good idea to swallow the exception silently
>>>>>>>>> as you propose.
>>>>>>>>> In our test setup, the tests would just be switched off if something
>>>>>>>>> breaks, and no one will see that. If they fail though, it's an easy
>>>>>>>>> and quick fix. I would at least switch them on, then one sees the
>>>>>>>>> failing tests in case switching them on was the wrong guess.
>>>>>>>>> Also, below, the method dump() throws an exception.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Goetz
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: mikhailo [mailto:mikhailo.seledtsov at oracle.com]
>>>>>>>>>> Sent: Tuesday, August 01, 2017 11:49 PM
>>>>>>>>>> To: Lindenmaier, Goetz<goetz.lindenmaier at sap.com>
>>>>>>>>>> Cc: hotspot-runtime-dev at openjdk.java.net
>>>>>>>>>> Subject: Re: RFR(M): 8185436: jtreg: introduce keyword to disable
>>>>>>>>>> cds tests
>>>>>>>>>>
>>>>>>>>>> Hi Goetz,
>>>>>>>>>>
>>>>>>>>>> I have reviewed your updated changes, and they overall look good to
>>>>>>> me.
>>>>>>>>>> However, I have some comments + concerns regarding
>>>>>>> VMProps.vmCDS():
>>>>>>>>>> 1. Throwing exceptions from within the vmCDS() method.
>>>>>>>>>>
>>>>>>>>>> The VMProps properties are evaluated at the start of each
>>>>>>>>>> run. If
>>>>>>>>>> the exception is thrown here the whole test run will fail (not
>>>>>>>>>> just the
>>>>>>>>>> test that uses '@requires vm.cds'). The failure will occur shortly
>>>>>>>>>> after
>>>>>>>>>> the start of jtreg test run with a message:
>>>>>>>>>> "java.lang.RuntimeException: Can not start VM to
>>>>>>>>>> test to
>>>>>>>>>> find out it's features. Switching off class data sharing (CDS)."
>>>>>>>>>>
>>>>>>>>>> Your method has 2 throw statements: "new
>>>>>>>>>> RuntimeException("Can
>>>>>>>>>> not
>>>>>>>>>> start VM..." and "java.lang.RuntimeException: Can not start VM
>>>>>>>>>> to test
>>>>>>>>>> to...". I would recommend a more graceful way to fail, e.g. to
>>>>>>>>>> print
>>>>>>>>>> the
>>>>>>>>>> message and to return "false" instead. This way the rest of the
>>>>>>>>>> test
>>>>>>>>>> run
>>>>>>>>>> will continue, but the tests requiring vm.cds will be skipped with
>>>>>>>>>> qualification of "not selected".
>>>>>>>>>>
>>>>>>>>>> 2. The check for "An error has occurred while processing the shared
>>>>>>>>>> archive file." assumes that archive was not created prior to the
>>>>>>>>>> execution of this evaluation code. However, there are test modes
>>>>>>> where
>>>>>>>>>> archive is created prior to test run. We use such mode on regular
>>>>>>>>>> basis.
>>>>>>>>>> In such cases the code will fail.
>>>>>>>>>> I recommend to run "-Xshare:on -version", and check the
>>>>>>>>>> following match that would result in return of "true":
>>>>>>>>>> "Java HotSpot.*sharing"
>>>>>>>>>>
>>>>>>>>>> 3. On occasion the mapping of shared archive region to a specified
>>>>>>>>>> address will fail (due to system configuration, space already
>>>>>>>>>> occupied,
>>>>>>>>>> ASLR, etc.)
>>>>>>>>>>
>>>>>>>>>> Hence I recommend checking for such conditions as well:
>>>>>>>>>>
>>>>>>>>>> if (output.firstMatch("Unable to map") != null) {
>>>>>>>>>> System.out.println("VMProps.vmCDS() encountered an
>>>>>>>>>> archive
>>>>>>>>>> mapping failure, still proceeding with vm.cds=true");
>>>>>>>>>> return "true";
>>>>>>>>>> }
>>>>>>>>>> I am returning true here because seeing this output means
>>>>>>>>>> that
>>>>>>>>>> CDS
>>>>>>>>>> feature is supported, however in this particular instance archive
>>>>>>>>>> failed
>>>>>>>>>> to map.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The rest of the changes looks good to me.
>>>>>>>>>>
>>>>>>>>>> See for my version of VMProps.vmCDS() below. Let me know what you
>>>>>>>>>> think.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>>
>>>>>>>>>> Mikhailo
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ================== my update of VMProps.vmCDS()
>>>>>>>>>>
>>>>>>>>>> protected String vmCDS() {
>>>>>>>>>> System.setProperty("test.jdk",
>>>>>>>>>> System.getProperty("java.home"));
>>>>>>>>>> ProcessBuilder pb =
>>>>>>>>>> ProcessTools.createJavaProcessBuilder("-Xshare:on", "-version");
>>>>>>>>>> OutputAnalyzer output;
>>>>>>>>>>
>>>>>>>>>> try {
>>>>>>>>>> output = new OutputAnalyzer(pb.start());
>>>>>>>>>> } catch (IOException e) {
>>>>>>>>>> System.err.println( "Can not start VM to test to
>>>>>>>>>> find out
>>>>>>>>>> it's features. " +
>>>>>>>>>> "Switching off class data
>>>>>>>>>> sharing (CDS)." + e);
>>>>>>>>>> return "false";
>>>>>>>>>> }
>>>>>>>>>> if (output.firstMatch("Shared spaces are not
>>>>>>>>>> supported in
>>>>>>>>>> this
>>>>>>>>>> VM") != null) {
>>>>>>>>>> return "false";
>>>>>>>>>> }
>>>>>>>>>> if (output.firstMatch("An error has occurred while
>>>>>>>>>> processing
>>>>>>>>>> the shared archive file.") != null) {
>>>>>>>>>> return "true";
>>>>>>>>>> }
>>>>>>>>>> if (output.firstMatch("Java HotSpot.*sharing") !=
>>>>>>>>>> null) {
>>>>>>>>>> return "true";
>>>>>>>>>> }
>>>>>>>>>> if (output.firstMatch("Unable to map") != null) {
>>>>>>>>>> System.out.println("VMProps.vmCDS() encountered an
>>>>>>>>>> archive
>>>>>>>>>> mapping failure, still proceeding with vm.cds=true");
>>>>>>>>>> return "true";
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> return "false";
>>>>>>>>>> }
>>>>>>>>>> ==================
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On 08/01/2017 07:20 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I made new webrevs implementing the change with @requires:
>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr17/8185436-cdsKey/webrev.02/
>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr17/8185436-cdsKey/webrev.02-
>>>>>>> hs/
>>>>>>>>>>> I also changed the bug description and synopsis.
>>>>>>>>>>>
>>>>>>>>>>> For the jtreg runner I would propose to set the property test.jdk
>>>>>>>>>>> so that it is available in VMProps. Igor also ran into this
>>>>>>>>>>> issue.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Goetz.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Mikhailo Seledtsov [mailto:mikhailo.seledtsov at oracle.com]
>>>>>>>>>>>> Sent: Montag, 31. Juli 2017 22:19
>>>>>>>>>>>> To: Lindenmaier, Goetz<goetz.lindenmaier at sap.com>
>>>>>>>>>>>> Cc: hotspot-runtime-dev at openjdk.java.net
>>>>>>>>>>>> Subject: Re: RFR(M): 8185436: jtreg: introduce keyword to
>>>>>>>>>>>> disable cds
>>>>>>>>>> tests
>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>
>>>>>>>>>>>> I have an idea on how to address your second use case.
>>>>>>>>>>>> The idea is to define a special test property (e.g.
>>>>>>>>>>>> test.cds.disable.cds.support) which will override logic inside
>>>>>>>>>>>> the
>>>>>>>>>>>> VMProps.vmCDSSupported(). If this property is defined to
>>>>>>>>>>>> "true" in
>>>>>>>>>>>> test
>>>>>>>>>>>> invocation command then vmCDSSupported() returns false (CDS is
>>>>>>>>>> disabled,
>>>>>>>>>>>> not supported), and all tests marked with "@requires
>>>>>>>>>>>> vm.cds.supported"
>>>>>>>>>>>> will be skipped.
>>>>>>>>>>>>
>>>>>>>>>>>> How to use it:
>>>>>>>>>>>> jtreg -Dtest.cds.disable.cds.support=true<tests-to-run>
>>>>>>>>>>>> E.g.: jtreg -Dtest.cds.disable.cds.support=true
>>>>>>>>>>>>
>>>>>>> hs/hotspot/test/runtime/SharedArchiveFile/ArchiveDoesNotExist.java
>>>>>>>>>>>> I prototyped this approach, it works for me. I have attached the
>>>>>>>>>>>> diff.
>>>>>>>>>>>> Let me know whether this works for your use case, or if you
>>>>>>>>>>>> have any
>>>>>>>>>>>> questions.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you,
>>>>>>>>>>>> Mikhailo
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On 7/31/17, 1:45 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>> Hi Mikhailo,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Basically I'm fine with using the @requires property.
>>>>>>>>>>>>> But is there a way to overrule the outcome of the method
>>>>>>>>>>>>> implemented In VMProps.java computing the property?
>>>>>>>>>>>>> I have two use cases for the key I want to introduce.
>>>>>>>>>>>>>
>>>>>>>>>>>>> First, our internal VM (we are Oracle licensees) is compiled
>>>>>>>>>>>>> without
>>>>>>>>>>>>> CDS support. Thus we don't want to run the CDS tests. Currently
>>>>>>>>>>>>> we have them all listed in the ProblemList, but that's not nice,
>>>>>>>>>>>>> especially
>>>>>>>>>>>>> because we have to adapt it whenever a new test is added.
>>>>>>>>>>>>> As I understand, the @requires property works fine, here.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Second, we also test the two ports we contributed (ppc and
>>>>>>>>>>>>> s390).
>>>>>>>>>>>>> These
>>>>>>>>>>>> contain
>>>>>>>>>>>>> rudimentary cds support and so far passed all tests.
>>>>>>>>>>>>> Unfortunately it
>>>>>>>>>> broke
>>>>>>>>>>>>> lately in jdk10. Instead of fixing it (our people are
>>>>>>>>>>>>> working on
>>>>>>>>>>>>> finishing
>>>>>>>>>> our
>>>>>>>>>>>>> internal Java 9 port) I would like to switch off all cds tests.
>>>>>>>>>>>>> As I can set the key on the command line of jtreg, I easily can
>>>>>>>>>>>>> do that.
>>>>>>>>>>>>> Is there a way to do similar with the @requires property?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>> Goetz.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: Mikhailo Seledtsov
>>> [mailto:mikhailo.seledtsov at oracle.com]
>>>>>>>>>>>>>> Sent: Freitag, 28. Juli 2017 23:53
>>>>>>>>>>>>>> To: Lindenmaier, Goetz<goetz.lindenmaier at sap.com>
>>>>>>>>>>>>>> Cc: hotspot-runtime-dev at openjdk.java.net
>>>>>>>>>>>>>> Subject: Re: RFR(M): 8185436: jtreg: introduce keyword to
>>>>>>>>>>>>>> disable cds
>>>>>>>>>>>> tests
>>>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am a HotSpot SQE Engineer at Oracle. I have
>>>>>>>>>>>>>> discussed your
>>>>>>>>>> proposed
>>>>>>>>>>>>>> fix with Igor Ignatyev (also VM SQE Engineer), and we have the
>>>>>>>>>> following
>>>>>>>>>>>>>> feedback on this change.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. As part of streamlining and simplifying SQE process and the
>>>>>>>>>>>>>> use of
>>>>>>>>>>>>>> test tools we have narrowed down the test selection mechanisms.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. Our preferred test selection mechanism is use of "@requires"
>>>>>>>>>>>>>> and a
>>>>>>>>>>>>>> corresponding test/jtreg-ext/requires/VMProps.java. Even though
>>>>>>>>>> JTREG
>>>>>>>>>>>>>> supports use of "@key", we prefer the use of "@requires" as a
>>>>>>>>>>>>>> first
>>>>>>>>>>>> choice.
>>>>>>>>>>>>>> 3. If it is not possible to use "@requires" for a given
>>>>>>>>>>>>>> situation then
>>>>>>>>>>>>>> use "@key" mechanism. We would ask you if you could explore
>>> the
>>>>>>>>>>>>>> possibility of implementing this change via @requires first.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here are several hints that may help:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. Take a look at<top>/test/jtreg-ext/requires/VMProps.java.
>>>>>>>>>>>>>> The
>>>>>>>>>>>>>> value
>>>>>>>>>>>>>> of a given "requires property" is evaluated inside this file
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> placed
>>>>>>>>>>>>>> into a map (see public call() method). Add your evaluation code
>>>>>>>>>>>>>> here,
>>>>>>>>>>>>>> and then follow the pattern used for other properties. Create a
>>>>>>>>>> property
>>>>>>>>>>>>>> (e.g. vm.cds.supported, with values of true/false). Create a
>>>>>>> method
>>>>>>>>>> that
>>>>>>>>>>>>>> evaluates the property value (e.g. isCDSSupported() or
>>>>>>>>>>>>>> similar).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. The method could use several options to evaluate whether CDS
>>>>>>> is
>>>>>>>>>>>>>> supported.
>>>>>>>>>>>>>> A. WhiteBox API. Create a new WB test API method
>>>>>>>>>>>>>> which can
>>>>>>>>>> return
>>>>>>>>>>>>>> true if CDS_ compiler flag is defined, otherwise false.
>>>>>>>>>>>>>> Call WB API from VMProps.java. See
>>>>>>>>>>>>>> WB.getBooleanVMFlag("EnableJVMCI") as an example. Or create
>>>>>>> your
>>>>>>>>>>>> own
>>>>>>>>>>>>>> WB.isCDSSupported()
>>>>>>>>>>>>>> WhiteBox.java resides in
>>>>>>>>>>>>>> test/lib/sun/hotspot/WhiteBox.java
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> B. Another options is to evaluate by running VM with
>>>>>>>>>>>>>> sharing on and
>>>>>>>>>>>>>> checking the return (may be not as reliable as option A)
>>>>>>>>>>>>>> C. Other ideas welcome.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 3. Include "@requres vm.cds.supported == true" to the
>>>>>>> appropriate
>>>>>>>>>> tests.
>>>>>>>>>>>>>> Let me know if you have any questions.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>> Mikhailo
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 7/28/17, 12:58 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> we compile the VM without CDS support. Thus the CDS tests
>>>>>>>>>>>>>>> fail. This change introduces a keyword 'cds' and marks
>>>>>>>>>>>>>>> the tests accordingly.
>>>>>>>>>>>>>>> This change also fixes the keywords specified in
>>>>>>>>>>>>>> gc/g1/TestSharedArchiveWithPreTouch.java.
>>>>>>>>>>>>>>> There may only be one @key keyword in the test specification.
>>>>>>>>>>>>>>> In runtime/CompressedOops/CompressedClassPointers.java
>>> only
>>>>>>> one
>>>>>>>>>>>> test
>>>>>>>>>>>>>>> case required CDS. I changed this sub case to succeed if
>>>>>>>>>>>>>>> CDS is
>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>> available.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please review this change. I please need a sponsor.
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr17/8185436-
>>>>>>> cdsKey/webrev.01/
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>> Goetz.
>
More information about the hotspot-runtime-dev
mailing list