ARM: Enable safepoints for JIT-compiled code

[Dr Andrew John Hughes]

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.

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

To continue the baby analogy, think of it as me allowing relatives or
childminders to also look after it.  In some cases, Granny might know
best what to do as she's spent a lifetime hacking on ARM
architectures...

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

I concur.  It even says as much here:

"The following cases are exempt from review:

    Trivial fixes
        Typos, spelling mistakes
        Forgetting to add a required file in a previous commit 
    Commits to IcedTea6 HEAD (for legacy reasons)
    Commits to IcedTea7 HEAD / forest prior to 2.0 

For the latter two cases, we strongly recommend that reviews are requested, even though they are not required at present."

http://icedtea.classpath.org/wiki/CommitPolicy

Note that this does suggest that we'd enforce it on 7 post-2.0.  This
is something we need to discuss separately.

> 
> Andrew.

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120111/11907a0a/attachment.bin