Heads Up! GC directory structure cleanup

[Per Liden]

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.

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