URGENT: Request for review: 7122222: GC log is limited to 2G for 32-bit

[Yumin Qi]

Hi, Tao

   The change works only when LP64 is not defined as "1", I would think 
you need to check if it is defined instead. (how about LP64=other?, 
source code only check if it is defined).
   I am not a reviewer.

Thanks
Yumin

On 6/4/2013 4:03 PM, Tao Mao wrote:
> Since the changeset touched makefiles, I've included 
> build-dev at openjdk.java.net .
>
> I need to push the hsx24 bug asap. Please review it.
>
> Thanks.
> Tao
>
> On 6/4/13 2:37 PM, Tao Mao wrote:
>> Hi all,
>>
>> Need reviews to catch RDP2.
>>
>> The current webrev is a working solution to all platforms, Linux, 
>> Windows, and Solaris.
>> http://cr.openjdk.java.net/~tamao/7122222/webrev.00/
>>
>> Thanks.
>> Tao
>>
>> On 5/30/13 10:21 AM, Tao Mao wrote:
>>> Included runtime dev to see whether they have some idea to handle 
>>> the compilation choices.
>>>
>>> For now, it's been verified that the fix is functionally sufficient.
>>>
>>> Thanks.
>>> Tao
>>>
>>> On 5/29/13 5:27 PM, Tao Mao wrote:
>>>> Thank you, Mikael.
>>>>
>>>> Please see inline.
>>>>
>>>> Reviewers, please review it based on the following new observation.
>>>>
>>>> Tao
>>>>
>>>> On 5/27/13 2:05 AM, Mikael Gerdin wrote:
>>>>> Tao,
>>>>>
>>>>> On 2013-05-25 02:19, Tao Mao wrote:
>>>>>> 7ux bug
>>>>>>
>>>>>> webrev:
>>>>>> http://cr.openjdk.java.net/~tamao/7122222/webrev.00/
>>>>>>
>>>>>> changeset:
>>>>>> (1) make -D_FILE_OFFSET_BITS=64 only available to generating 
>>>>>> ostream.o
>>>>>>
>>>>>> Why conservative rather than making -D_FILE_OFFSET_BITS=64 globally
>>>>>> applicable?
>>>>>>
>>>>>> Global setting of -D_FILE_OFFSET_BITS=64 on linux works fine; 
>>>>>> however,
>>>>>> there are at least five code conflicts if introducing the flag 
>>>>>> globally
>>>>>> to Solaris.
>>>>>>
>>>>>> One was resolved as in os_solaris.inline.hpp, but the rest four 
>>>>>> files
>>>>>> had conflicts deep in c library. Even if they are excluded from 
>>>>>> setting
>>>>>> -D_FILE_OFFSET_BITS=64, the compiled VM is corrupted.
>>>>>>
>>>>>> (2) For now, no Windows solution.
>>>>>> I haven't found any clean solution for solving this problem on 
>>>>>> Windows.
>>>>>
>>>>> This seems like an insufficient fix if you can't make it work on 
>>>>> all platforms. I tried building with "-D_LARGEFILE64_SOURCE 
>>>>> -D_FILE_OFFSET_BITS=64" ons Solaris and hit an #error in libelf.h 
>>>>> saying it wasn't supported so I understand your problem there.
>>>> Yes, that's my grief :( you touched them, a bunch of them. That's 
>>>> why I chose to apply the flag only to the files (ostream.cpp and 
>>>> ostream.hpp) I want the effect.
>>>>>
>>>>> Instead I suggest that you use the compatibility API described in 
>>>>> lf64(5) on Solaris. This API consists of fopen64, ftell64 and 
>>>>> friends and is exposed when "-D_LARGEFILE64_SOURCE" is set.
>>>>>
>>>>> The same "-D_LARGEFILE64_SOURCE" is available on Linux and has the 
>>>>> added advantage of not changing any existing symbols and therefore 
>>>>> we can set the define for all files instead of just ostream
>>>>>
>>>>> This approach has the added advantage that it more closely 
>>>>> resembles the changes which will be needed for Windows anyway. 
>>>>> Those changes would consist of changing calls to ftell/fseek to 
>>>>> 64-bit versions and changing fopen to fopen64 on Solaris/Linux.
>>>> Both ways have pros and cons. The current implementation excludes 
>>>> the usage of fopen64, providing portability (since there's no 
>>>> fopen64 for Windows). Meanwhile, I understand your suggestion 
>>>> provides other benefits.
>>>>
>>>> This Sun White Paper 
>>>> (http://unix.business.utah.edu/doc/os/solaris/misc/largefiles.pdf) 
>>>> summarizes the usage of the flags on solaris (Page 5-26). And, it 
>>>> should apply to Linux the same way as was agreed across platforms.
>>>>
>>>>>
>>>>> Since there is no fopen64 on Windows it seems that the default 
>>>>> fopen already supports large files.
>>>> I tested, and you are correct that the 32-bit VM on Windows can 
>>>> write beyond 2GB (and beyond 4GB). Thank you, it's solved "half of 
>>>> my problem" :)
>>>>>
>>>>> /Mikael
>>>>>
>>>>>>
>>>>>> test:
>>>>>> (1) Ability to write over 2g file for 32-bit builds were verified 
>>>>>> on the
>>>>>> following configurations.
>>>>>>
>>>>>> Linux * i586
>>>>>> Solaris * i586
>>>>>> Solaris * sparc
>>>>>>
>>>>>> (2) Need a JPRT test for sanity check.
>>>>>