Heads Up! GC directory structure cleanup

[Per Liden]

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.

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
>