ARM: Enable safepoints for JIT-compiled code
aph at redhat.com
Wed Jan 11 07:55:08 PST 2012
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
>>> 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.
More information about the distro-pkg-dev