[drlvm][threading] questions about H3413, Refactoring exception safepoint callback

[Weldon Washburn <we...@gmail.com>]

Pavel,

The code in this patch looks much better than the original code.  Thanks for
focusing on cleaning this code up.

A question about the use of  the disable_count field in struct hythread_t.
I notice in hythread_exception_safe_point() that the old value of this field
is saved.  The field is then specifically set to a value of one and once the
exception callback is processed, the field is returned to its original
value.  Is this a case where disable_count is actually be overloaded with
another use?  Would it make sense to split the two uses into two seperate,
distinct fields??

-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

Re: [drlvm][threading] questions about H3413, Refactoring exception safepoint callback

[Pavel Rebriy <pa...@gmail.com>]

Patch in JIRA issue is update. Comment for hythread_exception_safe_point()
function is added.

On 20/03/07, Weldon Washburn <we...@gmail.com> wrote:
>
> This makes sense.  Can you add the below as a comment in the code?  I
> tried
> to clean it up and make it clearer.  Since this is tricky code, feel free
> to
> add even more comments.
>
> On 3/19/07, Pavel Rebriy <pa...@gmail.com> wrote:
> >
> > There is a contract between disable_count value and Java code execution:
> > during Java code execution disable_count should be equal to 1. It means
> > that
> > garbage collection
>
>
> while in native code can only take place when the native code makes
> disable_count equal to zero.  To do this, the native code must guarantee
> that the GC is able to see all live references the native code is working
> with.  And that the native code will not read/write live references while
> disable_count is equal to zero.  This happens
>
>
> >  within suspension safe points or
> > within VM helpers.
> >
> > Execution of safepoint callback function could call Java code.
>
>
> If this happens,
>
> disable_count
>
> must
>
> be set to 1 before callback function execution.
>
> Field disable_count cannot be changed by another thread. It value changes
> only by the same thread. So there is no race condition or separate usage
> in
> setting disable_count to 1.
>
> On 19/03/07, Weldon Washburn <we...@gmail.com> wrote:
> >
> > Pavel,
> >
> > The code in this patch looks much better than the original code.  Thanks
> > for
> > focusing on cleaning this code up.
> >
> > A question about the use of  the disable_count field in struct
> hythread_t.
> > I notice in hythread_exception_safe_point() that the old value of this
> > field
> > is saved.  The field is then specifically set to a value of one and once
> > the
> > exception callback is processed, the field is returned to its original
> > value.  Is this a case where disable_count is actually be overloaded
> with
> > another use?  Would it make sense to split the two uses into two
> seperate,
> > distinct fields??
> >
> > --
> > Weldon Washburn
> > Intel Enterprise Solutions Software Division
> >
>
>
>
> --
> Best regards,
> Pavel Rebriy
>
>
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>



-- 
Best regards,
Pavel Rebriy

Re: [drlvm][threading] questions about H3413, Refactoring exception safepoint callback

[Weldon Washburn <we...@gmail.com>]

This makes sense.  Can you add the below as a comment in the code?  I tried
to clean it up and make it clearer.  Since this is tricky code, feel free to
add even more comments.

On 3/19/07, Pavel Rebriy <pa...@gmail.com> wrote:
>
> There is a contract between disable_count value and Java code execution:
> during Java code execution disable_count should be equal to 1. It means
> that
> garbage collection


while in native code can only take place when the native code makes
disable_count equal to zero.  To do this, the native code must guarantee
that the GC is able to see all live references the native code is working
with.  And that the native code will not read/write live references while
disable_count is equal to zero.  This happens


>  within suspension safe points or
> within VM helpers.
>
> Execution of safepoint callback function could call Java code.


If this happens,

disable_count

must

be set to 1 before callback function execution.

Field disable_count cannot be changed by another thread. It value changes
only by the same thread. So there is no race condition or separate usage in
setting disable_count to 1.

On 19/03/07, Weldon Washburn <we...@gmail.com> wrote:
>
> Pavel,
>
> The code in this patch looks much better than the original code.  Thanks
> for
> focusing on cleaning this code up.
>
> A question about the use of  the disable_count field in struct hythread_t.
> I notice in hythread_exception_safe_point() that the old value of this
> field
> is saved.  The field is then specifically set to a value of one and once
> the
> exception callback is processed, the field is returned to its original
> value.  Is this a case where disable_count is actually be overloaded with
> another use?  Would it make sense to split the two uses into two seperate,
> distinct fields??
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>



--
Best regards,
Pavel Rebriy




-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

Re: [drlvm][threading] questions about H3413, Refactoring exception safepoint callback

[Pavel Rebriy <pa...@gmail.com>]

There is a contract between disable_count value and Java code execution:
during Java code execution disable_count should be equal to 1. It means that
garbage collection could have place only within suspension safe points or
within VM helpers.

Execution of safepoint callback function could call Java code. That is
disable_count should be set to 1 before callback function execution.

Field disable_count cannot be changed by another thread. It value changes
only by the same thread. So there is no race condition or separate usage in
setting disable_count to 1.

On 19/03/07, Weldon Washburn <we...@gmail.com> wrote:
>
> Pavel,
>
> The code in this patch looks much better than the original code.  Thanks
> for
> focusing on cleaning this code up.
>
> A question about the use of  the disable_count field in struct hythread_t.
> I notice in hythread_exception_safe_point() that the old value of this
> field
> is saved.  The field is then specifically set to a value of one and once
> the
> exception callback is processed, the field is returned to its original
> value.  Is this a case where disable_count is actually be overloaded with
> another use?  Would it make sense to split the two uses into two seperate,
> distinct fields??
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>



-- 
Best regards,
Pavel Rebriy