JDK-7015652 : src/os/solaris, src/os/linux and src/os/bsd should not contain duplicate code
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7
  • Priority: P3
  • Status: Resolved
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2011-01-28
  • Updated: 2015-09-22
  • Resolved: 2015-08-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10
10Resolved
Related Reports
Relates :  
JDK-8134537 - Much nearly duplicated code for sun.misc.Signal support
Relates :  
JDK-8134538 - Duplicate implementations of os::lasterror
Relates :  
JDK-8136978 - Much nearly duplicated code for vmError support
Relates :  
JDK-8079449 - Improve os::attempt_reserve_memory_at() fallback coding on Linux, BSD, Solaris
Relates :  
JDK-8134540 - Much nearly duplicated code for PerfMemory support
Description
The src/os/solaris and src/os/linux directories contain quite a lot of duplicate code.
A tiny start has been made by abstracting the launcher for both into src/os/posix, but
as much refactoring between solaris and linux as possible should be done.  The use of 'posix' as a directory name is perhaps a bit unfortunate, because it implies that
only posix-compliant code should exist there, when in fact much of the common code
between solaris and linux isn't posix-related or posix-compliant.  We might create a 'unix'
os directory to contain the solaris/linux common code.  We should also take into account
BSD and OSX in the refactoring process.
Comments
This is no longer a general issue we wish to address.
13-08-2015
I don't think this should be done anymore. There have been many cleanups in the os code that have moved duplicate functionality into os_posix (that also use posix functions so the name is appropriate). I found <100 lines of trivially duplicated code. The rest of the code that has similar functionality should be cleaned up while addressing that specific functionality, for example, the memory reservation code has non-trivial differences that should be addressed (see linked bug). The general issue is not an issue (anymore).
13-08-2015
There are a lot of functions that are simply duplicates. There is also the mis-named posix directory. This bug is create the xnix directory, move the posix files there, and factor more duplicate functions out. After this initial work is done we can file more RFE's for unifying the implementations as you suggest. This can be done in stages and tested in between. Some sparing use of conditionals will be allowed to avoid virtual function dispatch or a lot of extra delegation code. It's TBD while refactoring how much we will need. I anticipate that there will be more discussion as this work is investigated and likely a JEP produced. Stay tuned. I took off "starter".
09-10-2013
This bug needs updating, it should now read src/os/solaris, src/os/linux, src/os/bsd and soon src/os/aix should not contain duplicate code! We should factor out the POSIX using implementations into a common file/class. This includes pthreads usage. We need to clean up all the historical anachronisms related to old LinuxThreads and NPTL bugs and the fact that some symbols weren't available on our old 2.4 build machines. Dynamic lookup should not be needed when building and running on current supported platforms. If we converted Solaris UI threads to pthreads then more sharing would be possible - but that can be done later. So ironically the initial step here would be to get linux and bsd using common code - at least in pthreads area. Note that BSD simply, and often incorrectly, copied the linux code in many cases (including bug workarounds that were completely irrelevant). Similarly any other shared API's from SUSv2 or BSD'isms used in Solaris (and BSD of course) should be factored out. It is unclear to me how to structure this to allow sharing but also allow overriding. The obvious approach would be inheritance and virtual methods, but that doesn't work in with the current OS class structure (with platform specific includes). Nor can it handle mixing POSIX and BSD API in Solaris - or can it? My C++ multiple-inheritance knowledge is a bit rusty, I suspect we would inherit from NIX and BSD and then define the Solaris method to call the NIX or BSD method as appropriate. The other obvious approach is to just use delegation but that still causes duplication albeit much smaller than at present - and then there is the issue of whether the indirection would cause performance issues. Also note that OSX complicates things as it is different to BSD in many cases but defined as a variant of the BSD code. It may be that as part of this src/os/osx needs to be defined. After all that the AIX folks can follow suit :) PS. Labelling this as a "starter" bug is completely wrong - this is a major piece of reengineering in the codebase.
09-10-2013
The JDK code has directories for native code called windows and solaris where the solaris directory contains solaris/linux/bsd/aix etc code with ifdefs. They really want to fix this. I proposed that the jdk use the same name "xnix" for the unix common code and they will be writing a JEP for this work. Our fix for doing the same thing should be included with this JEP and we should work together on this.
26-09-2013
I don't mind looking into it, though if anyone else wants, please feel free to take it.
26-09-2013
Recent discussion led to the idea to name the common directory xnix rather than posix (not completely true) or unix (copyrighted or something). I think someone new to the project should pick this up.
10-04-2013