ARM: Enable safepoints for JIT-compiled code

[Andrew Haley]

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.

> 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.

>> It doesn't make much sense for technical reviews (for correctness,
>> appropriateness, and so on) to be done on the release branch patches:
>> that should get done on trunk.
> 
> This doesn't happen.  It would be nice if it did, but it just
> doesn't on IcedTea.

It's still the right place to do it.

>> The only matter for the branch is
>> whether that patch is appropriate for the branch.
> 
> This we agree on.  But that obviously requires understanding the
> impact of said patch.

Of course.

Andrew.