On May 12, 2014, at 12:42 PM, Alan Bateman <alan.bate...@oracle.com> wrote:
> On 12/05/2014 11:03, Paul Sandoz wrote: >> >> It covers many areas and i have grouped the patches into such areas to aid >> reviewing. When commenting please including core-libs. > The groupings are a bit odd Yeah, definitely idiosyncratic, i tried to lump 'em in terms of areas where people could focus their expertise without creating too few or too many webrevs. > but I looked through the -core, -io, -management and -rmi patches and don't > see any issues. Thanks! > Nothing jumped out to suggest that the StringBuffer could be leaked to other > threads. There are a few cases where additional work could be done but I > assume you want to focus on s/StringBuffer/StringBuilder/g. > It might be worth fixing those if they are not too disruptive. > You might want to hear from Remi or Kumar before including asm. I mention it > because there might be preference to get changes to ASM done upstream to > avoid the copy in OpenJDK from diverging. > Yes. > As a general point then I don't see any reason why this can't be one > change-set. Periodically it makes sense to do a coarse grain split, say core > + client but shouldn't be necessary here, unless of course there is some > major refactoring or other big changes in, or coming soon to, jdk9/client. A > coarse grain split just reduced the need for merging when sync'ing up > integration forests. > Ok. > One minor comment is that refactoring where you change the name of the local > can sometimes impact the alignment of statement that span several lines. > VMID.toString is the only one that I noticed here and it's no big deal. > I fixed that. Paul.
signature.asc
Description: Message signed with OpenPGP using GPGMail
