Coming soon: second generation prototype of Hg forest consolidation

[Magnus Ihse Bursie]

On 2017-04-11 12:45, Claes Redestad wrote:
>
> On 04/11/2017 11:48 AM, David Holmes wrote:
>> Hi Stefan,
>>
>> On 11/04/2017 3:47 AM, Stefan Karlsson wrote:
>>> Hi all,
>>>
>>> Great to see that the consolidation work is going forward!
>>>
>>> I have comment specific to the HotSpot code layout:
>>>
>>> We previously had this layout (using a small set of directories as an
>>> example):
>>>  hotspot/src/share/vm
>>>  hotspot/src/os/linux/vm
>>>  hotspot/src/os/solaris/vm
>>>  hotspot/src/os/solaris/dtrace
>>>  hotspot/src/os/bsd/launcher
>>>  hotspot/src/share/tools/hsdis
>>>
>>> and this is the new layout:
>>>  src/hotspot/share/vm
>>>  src/hotspot/os/linux/vm
>>>  src/hotspot/os/solaris/vm
>>>  src/hotspot/os/solaris/dtrace
>>>  src/hotspot/os/bsd/launcher
>>>  src/hotspot/share/tools/hsdis
>>>
>>> should we consider changing the layout of the HotSpot code so that we
>>> don't mix the source code for the vm, tools, launcher? For example:
>>>  src/hotspot/vm/share
>>>  src/hotspot/vm/os/linux
>>>  src/hotspot/vm/os/solaris
>>>  src/hotspot/launcher/os/bsd
>>>  src/hotspot/tools/hsdis
>>>  src/hotspot/dtrace/os/solaris
>>>
>>> I'm not sure that we would want to include such a change in the
>>> consolidation effort, but we are changing all file paths so maybe it's
>>> the right time to think about this.
>>
>> Not sure what you mean about "mix the source code" but I much prefer 
>> the familiar hotspot layout:
>> - share
>> - os
>> - os_cpu
>> etc
>
> Familiar isn't necessarily good - my outsider perspective is that the 
> layout that
> Stefan proposes seems the more natural grouping when exploring the code:
> hotspot is built up of vm, launcher, tools, dtrace, each of which 
> *can* have
> shared and specialized implementations.

Which really is completely misleading. Hotspot is made up of the libjvm. 
Period. The rest is just small, more or less irrelevant utilities, or 
misplaced/forgotten code. I think a new code structure which does not 
give this fact proper weight would be unfortunate.

(Just to be clear, I agree with you but think you must go one step further.)

/Magnus

>
> The current structure requires a newbie to look in four or more seemingly
> unrelated trees to even start getting a grasp on where the meat is at, 
> while the
> proposal would make it immediately obvious that, say, hsdis is all 
> just in one place,
> which is a big win when on-boarding developers to a code base that is 
> already
> quite challenging to get familiar with.
>
> $.02
>
> /Claes
>