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

Filipp Zhinkin filipp.zhinkin at oracle.com
Wed Jul 10 05:54:37 PDT 2013


On 07/09/2013 01:52 AM, Vladimir Kozlov wrote:
> 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.
Got it. I'll try to implement it then.

Thanks,
Filipp.
>
> 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.
>>>
>>



More information about the hotspot-compiler-dev mailing list