RFR (L): 7054512: Compress class pointers after perm gen removal

[John Rose]

On Oct 3, 2012, at 11:06 AM, Christian Thalinger wrote:

>> I would personally try to restrict the changeset to the lines that contribute to the feature. Is there an agreed coding "policy" for this?
> 
> I don't think so.  People have different preferences.  But when I see code that is tidily arranged I usually keep that.  As I said, it's up to you.

Personally, I prefer to include simple cleanups in my changesets, if they are near to the essential changes.

Cleanup changes can make integration more expensive, when they interfere with other people's unrelated changes.  The opposing cost is of making cleanups so disproportionately inconvenient that they (in practice) never happen; the result will be a software base that looks like compost.  On balance, we need to feel free to tidy up small messes as we come across them.  And to use social pressure and good sense (before formal process) to regulate the flow of such changes.  (That means things like, "please give me a heads-up the next time you do something like that".  I see that hand...)

I believe we do not want to be in the habit of filing bugs of the form "adjust indentation in the foo method".  A few "adjust indentation" bugs are perfectly rational, if they batch up lots of similar problems.  But realistically speaking, many cleanups will happen on the fly, and will either accompany the main change, or never be done.

BTW, I am advocating (mainly) a "Lumper" point of view here, since that is my personal bent.
  http://en.wikipedia.org/wiki/Lumpers_and_splitters

A "Splitter" will be more uncomfortable with a miscellaneous changeset, since it does more than Just One Thing.  But even if you are a Splitter, you will probably admit that some tasks are too small to merit their own bug, which makes us both Lumpers; perhaps we would differ about the correct grouping algorithm for making the best Lumps.

That takes me back to my original point:  A practical changeset may include small changes in addition to its nominal change, if those changes are (somehow) reasonably close to the main change.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121003/337aed15/attachment.html