ARM: Enable safepoints for JIT-compiled code

[Andrew Haley]

On 01/11/2012 03:48 PM, Dr Andrew John Hughes wrote:
> On 13:32 Wed 11 Jan     , Andrew Haley wrote:
>> On 01/11/2012 01:26 PM, Dr Andrew John Hughes wrote:
>>> On 13:11 Wed 11 Jan     , Andrew Haley wrote:
>>>> On 01/11/2012 01:05 PM, Dr Andrew John Hughes wrote:
>>>>> On 14:31 Tue 10 Jan     , Andrew Haley wrote:
>>>>>> I've found the bug that broke safepoints.  It turns out that safepoints
>>>>>> do not convert a PC address to a bytecode index, so you have to set the
>>>>>> bytecode pointer explicitly whenever at a safepoint.  I'm intend to apply
>>>>>> this to trunk and branch, given RM approval.
>>>>>
>>>>> Patches to branches require approval by one other developer, not specifically
>>>>> the release manager.
>>>>
>>>> They require at least RM approval, for the obvious practical reasons.
>>
>>> I'm not sure what 'obvious practical reasons' you're referring to,
>>> but no they don't, and haven't for about the last two years.  It
>>> would have been a tremendous bottleneck if this was the case.
>>
>> The business of doing a release branch requires co-ordination of testing
>> and patches.  The RM knows about the testing cycle, and needs to know
>> when patches get committed, in order to synchronize the test cycle.
> 
> Knowing when patches are committed doesn't require them having sole
> say over approval.

Indeed not, but if a patch is good enough for trunk and submitted
for branch, the RM is at the helm.  Of course, the RM will solicit
consensus.

>>> Also what happens in the case that the maintainer of the branch
>>> submits a patch?  Should they get the right to dump whatever they
>>> want on the branch, but block the work of others?
>>
>> The RM is the maintainer of the branch.  It's their baby.  It's a
>> given that we trust them to do the right thing.  I take it for granted
>> that no RM will ever block the work of others.
> 
> Not purposefully maybe, but it does occur as a result of having one
> person as a bottleneck for release branch approvals, especially when
> we have people working in different timezones.  That's why I allow
> others to approve patches for the release branches I maintain and it
> hasn't caused any noticeable problems.  On the contrary, it's solved
> the problem of patches getting held up awaiting approval.

Fair enough: it's up to the RM to decide to allow that.

Andrew.