[9] RFR(XXS): 8068661: Exclude compiler/whitebox/ForceNMethodSweepTest.java from nightly runs

[Albert Noll]

David, Valdimir, thanks for the reviews.

@David: The original bug is still open.

Best,
Albert

On 01/08/2015 06:09 PM, Vladimir Kozlov wrote:
> Good.
>
> Thanks,
> Vladimir
>
> On 1/8/15 3:46 AM, Albert Noll wrote:
>> Hi,
>>
>> this fix excludes compiler/whitebox/ForceNMethodSweepTest.java from 
>> the nightly runs.
>> The test is unstable for the following reasons:
>>
>> A) The test is started with: 
>> -XX:CompileCommand=compileonly,SimpleTestCase$Helper::*
>>      As a result, all methods of SimpleTestCase$Helper can be 
>> compiled. These include the following accessor methods:
>>      SimpleTestCase$Helper.access$1400()I alive
>>      SimpleTestCase$Helper.access$1300(LSimpleTestCase$Helper;)I alive
>>
>>      Since background compilation is enabled, it is possible that 
>> methods of the class SimpleTestCase$Helper are
>> compiled just after (3) is executed.
>>
>>      1) int afterCompilation = getTotalUsage();
>>      2) Asserts.assertGT(afterCompilation, usage, "compilation should 
>> increase usage");
>>      3) guaranteedSweep();
>>      4) int afterSweep = getTotalUsage();
>>      5) Asserts.assertLTE(afterSweep, afterCompilation, "sweep 
>> shouldn't increase usage");
>>
>> B) Another possible problem is that we have class loading in (2). 
>> Since adapters are created eagerly, there is a
>> potential allocation in the code cache for adapters. In the 
>> executions I observed, this was not a problem due to adapter
>> sharing (there already exists an adapter, since a class that contains 
>> a method with the same signature was loaded
>> before). However, there is no guarantee that adapter sharing will 
>> also make this test work in the future.
>>
>> Here is the webrev:
>> http://cr.openjdk.java.net/~anoll/8068661/webrev.00/
>>
>> Thanks,
>> Albert