RFR (M): 8019489: Add regression test for JDK-8000232

[Vladimir Kozlov]

It is better now.

What I wanted is new whitebox api to stop/resume compiler thread in 
different phases. One such phase is the beginning of 
ciEnv::register_method() method. You stop compiler, load class which 
breaks dependencies in an other thread, resume compiler and it does 
dependance check.

It will be very useful for writing other tests and this way we can 
guarantee the testing of the problem instead of relying on luck.

Thanks,
Vladimir

On 7/8/13 4:56 AM, Filipp Zhinkin wrote:
> Here is updated webrev:
> http://cr.openjdk.java.net/~vlivanov/filipp/8019489/webrev.01/
>
> Test was renamed and thread synchronisation was simplified:
> now cyclic barriers are used instead of queues.
> I've also remove all exception handlers from main(). It does not affect
> functionality,
> because previously they were just rethrowing exceptions.
> With this change code looks more readable.
>
> Thanks,
> Filipp.
>
> On 07/05/2013 02:50 PM, Filipp Zhinkin wrote:
>> Vladimir,
>>
>> On 07/03/2013 11:22 PM, Vladimir Kozlov wrote:
>>> Filipp,
>>>
>>> Can it be done as whitebox test? May be you can make it less complex
>>> using whitebox.
>> I can't see any way to implement it as whitebox test test, because I
>> need to load witness class
>> between ciEnv::set_dependencies and ciEnv::register_method calls and
>> both these methods
>> called in Compilation ctor for C1 and in Compile ctor for C2.
>> And ciEnv::validate_compile_task_dependencies is private, so I can't
>> call it directly.
>>>
>>> Also we start using new test naming:
>>>
>>> https://wikis.oracle.com/display/HotSpotInternals/Naming+HotSpot+JTReg+Tests
>>>
>>>
>>> so for your test it is
>>> test/compiler/logCompilation/DependencyChangeLog.java
>> OK, I've got it.
>>>
>>> Also the test needs code style clean up.
>>>
>>> And I don't like synchronization you are using, too complex:
>>>
>>>  150        while(true) {
>>>  151             try {
>>>  152                 return queue.take();
>>>  153             } catch (InterruptedException ie) {
>>>  154                 continue;
>>>  155             }
>>>  156         }
>> Is it about the way I deal with InterruptedException or about queues?
>> Or both? :)
>> I'll reimplement synchronization in a less complex fashion.
>>
>> Thanks,
>> Filipp.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 7/3/13 5:50 AM, Filipp Zhinkin wrote:
>>>> Hi,
>>>>
>>>> I would like to add regression test for 8000232: NPG: SIGSEGV in
>>>> Dependencies::DepStream::check_klass_dependency on solaris-x64.
>>>>
>>>> Original issue occurs when dependency became invalid during compilation
>>>> and HS tries to write dependency to compilation log.
>>>> In order to reproduce it my test force creation of unique concrete
>>>> method
>>>> dependency and tries to invalidate it during compilation.
>>>>
>>>> At first test loads two classes: ContextClass and SubtypeClass, such
>>>> that
>>>> ContextClass has method "m" and SubtypeClass extends ContextClass
>>>> without
>>>> overriding that method. After that method "m" is repeatedly invoked on
>>>> instance of ContextClass until amount of invocations will not be
>>>> equal to
>>>> CompilationThreshold-1. When method "m" invoked CompilationThreshold-1
>>>> times test loads class WitnessClass that extends ContextClass and
>>>> override
>>>> method "m" in separate thread and continue invocations of "m" on
>>>> instance
>>>> of ContextClass. WitnessClass will make unique concrete method
>>>> dependency
>>>> invalid and if issue described in 8000232exist JVM will crash.
>>>>
>>>> webrev: http://cr.openjdk.java.net/~vlivanov/filipp/8019489/
>>>>
>>>> I've run JPRT to check that there are no issues with test and it
>>>> passed.
>>>>
>>>> Thanks,
>>>> Filipp.
>>
>