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