Heads Up! GC directory structure cleanup

[Per Liden]

On 2015-05-08 12:38, Per Liden wrote:
> On 2015-05-07 13:42, Per Liden wrote:
>> Hi Mattis,
>>
>> On 2015-05-07 12:45, Mattis Castegren wrote:
>>> Hi
>>>
>>> Will this just be a change in directory names, or will the code be
>>> changed as well?
>>
>> This is mainly a change of directory names, but this means that a number
>> of #include "gc_impl..." and #ifndef SHARE_VM_GC_IMPL..., etc will also
>> need to change. Other than that there will be no changes to any C++ code.
>>
>> Btw, same goes for the SA, where some package and import lines will be
>> updated to reflect the new paths.
>>
>>>
>>> If it is just a change in directory names, would it make sense to add
>>> this to the unshuffle script,
>>> http://cr.openjdk.java.net/~chegar/docs/portingScript.html
>>>
>>> This script currently unshuffles the directory name changes for the
>>> jigsaw project to allow backporting of fixes between 9 and 8. We in
>>> Sustaining will still backport bug fixes and security fixes to JDK 8
>>> and below, so it should be good if we did the same for GC changes.
>>>
>>> Do you think that would be possible?
>>
>> That sounds like a good idea. I will look into it.
>
> I had look at the unshuffle scipt and talked to Mattis about their
> needs. The conclusion is that with some adjustments to the
> unshuffle_patch.sh script it can do what we want. However, the
> sustaining org is almost always interested in back porting, forward
> porting is very rare. For back porting, it is fairly easy to query the
> hg repo to figure out if/how a file has moved around. This also allows
> you to backport a patch to any given revision (not just post -> pre the
> GC directory restructure) and works for any file in any repo (not just
> hotspot and the GC files).
>
> Attaching an example of what such a script could look like.

Ok, the mail server/list ate the patch, here it is inline.

#!/bin/bash
#
# backport_patch: Adjust patch to match old file/path names
#

if [ $# != 3 ]; then
         echo "usage: backport_patch <Rev> <Patch> <NewPatch>"
         echo ""
         echo "  <Rev>       Revision to backport to"
         echo "  <Patch>     Patch file to backport"
         echo "  <NewPatch>  Output result in new patch file"
         exit 1
fi

REV=$1
PATCH=$2
NEW_PATCH=$3

if [ ! -f "$PATCH" ]; then
         echo "File not found: $PATCH"
         exit 1
fi

if [ -f "$NEW_PATCH" ]; then
         echo "File already exists: $NEW_PATCH"
         exit 1
fi

if ! hg log -r $REV &> /dev/null; then
         echo "Unknown revision \"$REV\""
         exit 1
fi

get_old_name() {
         hg log -fpg -r $REV..tip $1 | awk '
                 BEGIN                  { from=""; }
                 /^(copy|rename) from / { from=$3; }
                 END                    { print from; }'
}

echo "Backporting to revision $REV"

cat $PATCH > $NEW_PATCH
FILES=$(grep '^diff --git ' $PATCH | sed 's|diff --git a/\([^ ]*\) 
b/.*$|\1|')
for NEW_FILE in $FILES; do
         OLD_FILE=$(get_old_name $NEW_FILE)
         if [ "$OLD_FILE" ]; then
                 echo " * $NEW_FILE -> $OLD_FILE"
                 sed -i "s|\( [ab]/\)$NEW_FILE|\1$OLD_FILE|g" $NEW_PATCH
         else
                 echo " * $NEW_FILE -> $NEW_FILE (Same)"
         fi
done

echo "Done"

# End of file

cheers,
/Per

>
> cheers,
> /Per
>
>>
>> cheers,
>> /Per
>>
>>>
>>> Kind Regards
>>> /Mattis
>>>
>>> -----Original Message-----
>>> From: Per Liden
>>> Sent: den 7 maj 2015 10:23
>>> To: hotspot-dev at openjdk.java.net
>>> Subject: Heads Up! GC directory structure cleanup
>>>
>>> Hi all,
>>>
>>> This is a heads up to let everyone know that the GC team is planning to
>>> do a cleanup of the directory structure for GC code. This change will
>>> affect people working on changes which touch GC-related code, and could
>>> mean that such patches need to be updated before applying cleanly to the
>>> new directory structure.
>>>
>>>
>>> Background
>>> ----------
>>> In the continuous work to address technical debt, the time has come to
>>> make some changes to how the GC code is organized. Over time the GC code
>>> has spread out across a number of directories, and currently looks like
>>> this:
>>>
>>> - There are three "top-level" directories which contain GC-related code:
>>> src/share/vm/gc_interface/
>>> src/share/vm/gc_implementation/
>>> src/share/vm/memory/
>>>
>>> - Our collectors are roughly spread out like this:
>>> src/share/vm/gc_implementation/parallelScavenge/     (ParallelGC)
>>> src/share/vm/gc_implementation/g1/                   (G1)
>>> src/share/vm/gc_implementation/concurrentMarkSweep/  (CMS)
>>> src/share/vm/gc_implementation/parNew/               (ParNewGC)
>>> src/share/vm/gc_implementation/shared/               (MarkSweep)
>>> src/share/vm/memory/                                 (DefNew)
>>>
>>> - We have common/shared code in the following places:
>>> src/share/vm/gc_interface/              (CollectedHeap, etc)
>>> src/share/vm/gc_implementation/shared/  (counters, utilities, etc)
>>> src/share/vm/memory/                    (BarrierSet, GenCollectedHeap,
>>> etc)
>>>
>>>
>>> New Structure
>>> -------------
>>> The plan is for the new structure to look like this:
>>>
>>> - A single "top-level" directory for GC code:
>>> src/share/vm/gc/
>>>
>>> - One sub-directory per GC:
>>> src/share/vm/gc/cms/
>>> src/share/vm/gc/g1/
>>> src/share/vm/gc/parallel/
>>> src/share/vm/gc/serial/
>>>
>>> - A single directory for common/shared GC code:
>>> src/share/gc/shared/
>>>
>>>
>>> FAQ
>>> ---
>>> Q: How will this affect me?
>>> A: Moving files around could mean that the patch you are working on will
>>> fail to apply cleanly. hg does a fairly good job of tracking
>>> moves/renames, but if you're using other tools (like patch, mq, etc) you
>>> might need to update/merge your patch manually.
>>>
>>> Q: When will this happen?
>>> A: A patch for this is currently being worked on and tested. A review
>>> request will be sent to hotspot-dev in the near future.
>>>
>>> Q: Why do this now?
>>> A: All major back-porting work to 8u has been completed. If we want to
>>> do this type of cleanup in jdk9, then now is a good time. The next
>>> opportunity to do this will be in jdk10, after all major back-porting
>>> work to 9u has been completed. We would prefer to do it now.
>>>
>>> regards,
>>> The GC Team
>>>