On 11/28/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Weldon Washburn wrote:
> On 11/25/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>>
>> On Saturday 25 November 2006 15:23 Evgueni Brevnov wrote:
>> > > > A1) segfault occured
>> > > > A2) grab "system hwe lock" and call vectored_exception_handler
>> > > > A3) instantiate NullPointerException object
>> > > > A4) set up throwing NullPointerExceptionObject in the register
>> snapshot
>> > > > A5) return from vectored_exception_handler release "system hwe
>> lock"
>> > > >
>> > > > Let's next assume that garbage collection was started exactly when
>> > > > thread A was in progress of running NullPointerException
>> constructor.
>> > > > Then, thread A will be suspended while still holding "system hwe
>> lock".
>> >
>> > I see two bad things here. The first one is a violation of the pretty
>> > known "rule". The rule is don't execute java methods under native
>> > lock. That was discussed several times already. Another problem is
>> > that two threads contend for the one lock while being in different
>> > modes. In other words the first thread gets the lock in suspend
>> > enabled state. The second thread tries to get the same lock in suspend
>> > disabled state. But the first thread is already suspended by GC what
>> > causes a deadlock. Thus it seems like another "rule" for me.
>> >
>> > Any native lock MUST be used either in suspend disabled or suspend
>> > enabled regions. It is prohibited to go outside of the region with the
>> > owned lock.
>
>
> The above seems to make sense. It might be possible to to add asserts to
> verify the rule is not violated.
>
> I agree with you. It is just not very obvious that the system kernel holds
>> some internal lock when a thread is executing VEH.
>
>
> hmm.... this conversation seems to be mixing DRLVM native code locks with
> locks that are internal to the underlying OS (or OS provided user-level
> libraries). Its important to sort out both issues. Gregory, can you
> clarify?
I didn't think I was mixing these locks. The deadlock which made us
change VEH handler code occurred as a deadlock between kernel internal
lock, and VM lock. Even if we create a facility which would allow to
check (via assertion) the locked/unlocked state of VM locks, it won't
help us when there are locks which we don't control, like in this case.
Seems like we mixing two diffrerent topics in one thread. Here is
another thread "[drlvm][threading] Native locks and thread suspension"
for discussing different deadlock scenarios...
Evgueni
> It is windows specific and
>> specific only to some windows versions. We know for sure that windows
>> 2003
>> server SP1 doesn't have this problem.
>
>
>
> I am not sure if it is documented anywhere. We've found the fact that this
>> lock exists in a hard way.
>>
>> > Does the above make sense? Could we somehow ensure this rule with
>> > assert statements?
>>
>> Yes it does. I've always wanted to have a function of Lock_Manager,
>> something
>> like bool is_locked_by_this_thread(). But asserts may be used only on the
>> lock which are controlled by VM. Internal kernel or C runtime locks
>> cannot
>> be
>> checked easily.
--
Gregory
