RFR: JDK-8001619: Remove usage of _ALLBSD_SOURCE in bsd files
Landon Fuller
landonf at plausible.coop
Tue Oct 30 10:15:06 PDT 2012
On Oct 29, 2012, at 7:54 AM, Daniel D. Daugherty wrote:
> On 10/29/12 7:23 AM, David Holmes wrote:
>> On 29/10/2012 7:30 PM, Staffan Larsen wrote:
>>> Here's a version with the zero changes as well: http://cr.openjdk.java.net/~sla/8001619/webrev.02/
>>>
>>> If it looks good, I'll push this version instead.
>>
>> Some of the conditionals are puzzling to me given this was all done for the MacOSX port:
>>
>> 326 #ifdef __APPLE__
>> ...
>> 331 #elif defined(__OpenBSD__)
>> ...
>> 342 #elif defined(_ALLBSD_SOURCE)
>> ...
>>
>> I would have expected __APPLE__ to always be defined (else it is redundant everywhere else!), but then that would preclude the _ALLBSD_SOURCE code from being used.
>
> The project that we (in Oracle) called the "MacOS X Port" project
> imported changes from the BSD Port project:
>
> http://hg.openjdk.java.net/bsd-port/bsd-port
>
> and from the MacOS X Port project:
>
> http://hg.openjdk.java.net/macosx-port/macosx-port
>
> so there are multiple "flavors" of BSD in the mix...
I'm probably the original author of much of the __APPLE__ code, predating even the OpenJDK bsd-port, back when the project was based on the SCSL and JRL source drops being patched by the BSDs.
As a general rule I relied on the BSD implementations where-ever possible, but there are numerous points where the code had to be specialized for Mac OS X in a significantly distinct manner the default BSD implementations. In cases such as the one referenced above, _ALLBSD_SOURCE provides the default common BSD implementation, with per-OS specialization in the case where implementation necessarily differed.
Causes for differentiation from the standard BSD code paths included thread handling (non-standard pthread*_np() functions, thread priority, thread suspension), signal handling (Darwin differs in the signals thrown for different conditions, both in terms of other BSDs, and on x86-32 vs x86-64, and required some code analysis to differentiate some signals), executable/shared library handling (dylib/macho vs. so/elf), etc.
FWIW,
-landonf
More information about the hotspot-dev
mailing list