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

[Tao Mao]

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