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

[Tao Mao]

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.
>>>