URGENT: Request for review: 7122222: GC log is limited to 2G for 32-bit
tao.mao at oracle.com
Thu May 30 00:27:51 UTC 2013
Thank you, Mikael.
Please see inline.
Reviewers, please review it based on the following new observation.
On 5/27/13 2:05 AM, Mikael Gerdin wrote:
> On 2013-05-25 02:19, Tao Mao wrote:
>> 7ux bug
>> (1) make -D_FILE_OFFSET_BITS=64 only available to generating ostream.o
>> Why conservative rather than making -D_FILE_OFFSET_BITS=64 globally
>> 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
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" :)
>> (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.
More information about the hotspot-gc-dev