Project Proposal: BSD port

[Kelly O'Hair]

I think I'm mostly in agreement with Martin here.
Hotspot is different, and I'm not speaking to that, just what is
in the jdk7/jdk repository.

I have tried over time to make any C code I see be standard conforming
and avoided using the src/windows and src/solaris directories, favoring
using the src/share area for as much as possible.
I don't have the history on why the share vs. solaris vs. linux vs. windows
separations were originally created and populated, I think someone with some
ancient jdk history might speak to the real meaning of "share".
I've treated "share" as "generic" code.

I myself would prefer to have one implementation source file with a clean
#ifdef approach rather than copied sources, but that's just me.
I prefer to see all the implementations of a function in one file.

However, I've adapted and over the years have experimented with many
ways to do this.

A couple of small examples in the OpenJDK sources I am familiar with:

hprof, hprof_md.h is in the share area, and it's implemention is split:

http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/share/demo/jvmti/hprof/hprof_md.h
http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/solaris/demo/jvmti/hprof/hprof_md.c
http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/windows/demo/jvmti/hprof/hprof_md.c

   Note the #ifdef LINUX used in the solaris file.

backend (backend to debugger), has different *_md.h files and implementations:

http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/solaris/back/
http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/windows/back/

   Note that the share source is actually #including different files and could
   be influenced by those files doing different #includes.
   I liked the hprof approach better, but I ended up with ONE file in each
   of the src/windows/demo/jvmti/hprof and src/solaris/demo/jvmti/hprof
   directories. And I'd hate to see this file replicated again.

How valuable is it to have completely different root source trees for windows and solaris?
Could one file with a huge #ifdef in it been any better?
Or just *_windows.c and *_posix.c names on the files and keep them in one src tree?

Just making the observations, I have no great answers...

-kto


Martin Buchholz wrote:
> I mostly agree with Volker.
> 
> The JDK code base has historically been targeted at a
> small number (like 10) of very specific build environments.
> The "must be windows or solaris or linux" assumption
> is a big one, but just one of many.
> Introducing a configure step is probably the right idea.
> The BSD port is a fine time to make OpenJDK at least
> more generally portable to any kind of Unix.
> BSD porters: Please don't just add else-if-BSD everywhere.
> 
> On the other hand, I don't dislike #ifdefs as much as
> others (e.g. Volker) do.  They need to be isolated, certainly,
> but with careful coding they have their place.
> I think #ifdefs are very much preferable to copying the
> entire src/solaris tree to src/bsd, for example.
> 
> Unfortunately, there seems to be no way to change the
> portability layer of OpenJDK without introducing some instability.
> Good pre-integration testing is key.
> 
> Martin
> 
> On Sat, Aug 2, 2008 at 1:14 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>> On 8/2/08, Rob Ross <rob.ross at gmail.com> wrote:
>>> I'm trying to clarify my understanding of what this means for a Mac-native
>>> version of OpenJDK.
>>>
>>> One of the implementation details of this project will be, for example, the
>>> addition of a "BSD" directory under .../jdk/src/, to go along with the
>>> existing "linux", "solaris", "windows", folders.
>>>
>>> Is this correct?
>>>
>> I think this is a crucial question and the answer is not as clear as
>> it may seem at a first glance. The problem is, that currently the
>> "linux" directory contains only the Linux man-pages while the
>> "solaris" directory contains all the "*nix" coding. While Linux and
>> Solaris obviously share a great amount of code, the differences
>> between the systems are factored out by numerous "ifdef" cascades.
>> There are also a lot of places in the code which implicitely assume
>> that the code is onlycompiled on Solaris and Linux (e.g. "ifndef
>> SOLARIS" is used as a marker for Linux).
>>
>> Now that many new ports are created, I think this code organization
>> should be seriously reconsidered, because:
>>
>> - if every port just changes the existing "solaris" source tree and
>> inserts just one more cascade of platform specific macros it will
>> become impossible to merge two or more of these ports together (i.e.
>> to have one source repository which builds on every supported
>> platform). But I think t his must be the final goal - having one
>> source repository which contains as many ports as possible.
>>
>> - if every port makes a copy of the current solaris directory (i.e.
>> the "bsd" directory in this context) this would make merging different
>> ports easier. But it would also lead to a considerable amount of code
>> duplication and maintaining the new ports would be a nightmare,
>> because any changes to the original "solaris" directory, would have to
>> be integrated in all the copies for the different ports.
>>
>> So in my opinion, the right way to go would be to factor out the
>> common "*nix" code into a generic, say "Posix" directory and let the
>> different platform directories ("solaris", "linix", "bsd", "haiku",
>> ...) only contain the differences with regard to the common "Posix"
>> directory (much like the "hotspot" directory is organized into a
>> "shared", "cpu", "os" and "os_cpu" part).
>>
>> The drawback of this solution is that it would require a considerable
>> amount of work (and a lot of work from Sun) because the code for the
>> Solaris and Linux ports would have to be changed.
>>
>> Probably it would be wise, if the porters group would sponsor such an
>> effort in the first place, if it is really interested in having many
>> stable platform ports in the future.