RFR(S): JDK-8133180 - [TESTBUG] runtime/SharedArchiveFile/SharedStrings.java failed with WhiteBox.class : no such file or directory
George Triantafillou
george.triantafillou at oracle.com
Wed Sep 2 14:55:58 UTC 2015
Hi Misha,
Please change the spelling of "interened" to "interned". Thanks.
-George
On 8/28/2015 3:38 PM, Mikhailo Seledtsov wrote:
> Hi Jiangli,
>
> I am back to this task after working on other stuff.
> As I started experimenting with your suggestions, I have found one
> potential problem.
> The fallback strategy that you suggest could create an ambiguity.
>
> For instance, there may be cases where both @build+ClassFileInstaller
> and @compile is used. The CFI will place classes in the current
> working directory, aka ".", where is @compile will place them under
> JTwork/../currentTest/classes/..
> In such cases, the test author will probably need to create 2 jars,
> one for classes in the local directory, and another for classes in the
> "@compile", and may want to be explicit what goes where, instead of
> JarBuilder trying to guess and leading to possible ambiguity and
> confusion.
>
> The key to solving this problem is to never assume the location of
> classes produced by @build. If using @build, the classes MUST be
> copied to the "." using ClassFileInstaller, since @build does not
> guarantee the presence of these classes in a specific location.
> Perhaps, the best solution here is to require all classes used by the
> JarBuilder to be in the "." directory, and require the test author to
> use ClassFileInstaller when necessary. In such cases, if the class is
> not in the test's current directory, the error will become obvious
> immediately instead of under some occasional conditions in the test
> system. It will also greatly simplify the tests and will make them
> more robust.
>
> Please let me know comments/objections on such approach.
>
> Thank you,
> Misha
>
>
> On 8/17/2015 6:18 PM, Mikhailo Seledtsov wrote:
>> Hi Jiangli,
>>
>> Thank you for your suggestion; it should make testing more robust.
>> I will try your suggestion; if I do not see any undesired side
>> effects I will rerun full testset and re-submit the updated review.
>>
>> Thank you,
>> Misha
>>
>> On 8/14/2015 5:43 PM, Jiangli Zhou wrote:
>>> Hi Misha,
>>>
>>> I have one suggestion. Instead of searching either the ‘work’ or
>>> ‘classes’ directory depending on the ‘classesInWorkDir’ argument,
>>> how about searching both directories? So the BasicJarBuilder.build()
>>> method would use the ‘classes’ directory first, then try the ‘work’
>>> directory if the file cannot be found in ‘classes'. That might be a
>>> more robust solution.
>>>
>>> Thanks,
>>> Jiangli
>>>
>>> On Aug 14, 2015, at 2:22 PM, Mikhailo Seledtsov
>>> <mikhailo.seledtsov at oracle.com> wrote:
>>>
>>>> Please review this fix to the CDS test bug. See the comments in the
>>>> bug for details.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8133180
>>>> Webrev: http://cr.openjdk.java.net/~mseledtsov/8133180.00/
>>>> Testing:
>>>> - ran the reproducer discussed in the bug description
>>>> rm -Rf JT* test
>>>> jtreg
>>>> /media/data3/hg/9/work01/hs-rt/hotspot/test/testlibrary_tests/ctw/JarDirTest.java
>>>> jtreg
>>>> /media/data3/hg/9/work01/hs-rt/hotspot/test/runtime/SharedArchiveFile/SharedStrings.java
>>>>
>>>> - ran the CDS tests in concurrent mode
>>>> - running CDS tests via multi-platform build-and-test system
>>>> (in progress)
>>>>
>>>> Thank you,
>>>> Misha
>>
>
More information about the hotspot-runtime-dev
mailing list