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

[Tao Mao]

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