8029383: assert(counter_changed) failed: failed dependencies, but counter didn't change

Vladimir Kozlov vladimir.kozlov at oracle.com
Mon Dec 9 13:44:40 PST 2013


Good.

Vladimir

On 12/9/13 1:05 PM, Roland Westrelin wrote:
>
> Hi Vladimir,
>
> Thanks for reviewing this change.
>
>> CC to serviceability group.
>>
>> I am for "always call notice_modification() in parse_stream()”.
>
> This then:
>
> http://cr.openjdk.java.net/~roland/8029383/webrev.01/
>
> Roland.
>
>>
>> The method SystemDictionary::number_of_modifications() is used only by ciEnv::system_dictionary_modification_counter_changed() which checks only not equal state. So the value is not important, only difference.
>>
>> Add new comment to separate from existing one. Otherwise it looks strange:
>>         // But, do not add to system dictionary.
>> +       if (notice) {
>> +         notice_modification();
>>
>> Thanks,
>> Vladimir
>>
>> On 12/9/13 9:03 AM, Roland Westrelin wrote:
>>> http://cr.openjdk.java.net/~roland/8029383/webrev.00/
>>>
>>> When an anonymous class is defined through Unsafe (not recorded in the system dictionary), SystemDictionary::notice_modification() is not called and failed dependencies can be missed when class loading happens concurrently with a compilation (for this test case, a new implementor for an interface).
>>>
>>> There are 2 calls to SystemDictionary::parse_stream(). One is from jvmti and as I understand the call to SystemDictionary::notice_modification() once all new class definitions are done which is fine because this happens at a safepoint. The other call is when the class is defined through Unsafe. I added a call to SystemDictionary::notice_modification() in that case and it must happen with the CompileLock held. Maybe, we could as well always call notice_modification() in parse_stream() and remove the call from the jvmti code.
>>>
>>> Roland.
>>>
>


More information about the hotspot-compiler-dev mailing list