URGENT: Request for review: 7122222: GC log is limited to 2G for 32-bit
tao.mao at oracle.com
Thu May 30 17:21:49 UTC 2013
Included runtime dev to see whether they have some idea to handle the
For now, it's been verified that the fix is functionally sufficient.
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.
> 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
> 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
>>> following configurations.
>>> Linux * i586
>>> Solaris * i586
>>> Solaris * sparc
>>> (2) Need a JPRT test for sanity check.
More information about the hotspot-gc-dev