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

Yumin Qi yumin.qi at oracle.com
Tue Jun 4 17:55:13 PDT 2013


You can ignore my noise.

Thanks
Yumin
On 6/4/2013 4:26 PM, Tao Mao wrote:
> Thank you for looking at it, Yumin.
>
> Please see inline.
>
> Tao
>
> On 6/4/13 4:14 PM, Yumin Qi wrote:
>> Hi, Tao
>>
>>   The change works only when LP64 is not defined as "1", I would 
>> think you need to check if it is defined instead. (how about 
>> LP64=other?, source code only check if it is defined).
> Is that true?
>
> I found the following exist in the current make files.
>
> make//bsd/makefiles/defs.make:34:ifeq ($(LP64), 1)
> make//linux/makefiles/defs.make:40:ifeq ($(LP64), 1)
> make//solaris/makefiles/defs.make:33:ifeq ($(LP64), 1)
>
> ifeq ($(LP64), 1)
>   ARCH_DATA_MODEL ?= 64
> else
>   ARCH_DATA_MODEL ?= 32
> endif
>
>
> It looks that it assumes users should set LP64=1 in order to get a 
> correct build.
>
> Just presenting something I found. I'm not sure about this, either. 
> The make files are a mystery to me.
>
>>   I am not a reviewer.
>>
>> Thanks
>> Yumin
>>
>> On 6/4/2013 4:03 PM, Tao Mao wrote:
>>> Since the changeset touched makefiles, I've included 
>>> build-dev at openjdk.java.net .
>>>
>>> I need to push the hsx24 bug asap. Please review it.
>>>
>>> Thanks.
>>> Tao
>>>
>>> On 6/4/13 2:37 PM, Tao Mao wrote:
>>>> 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.
>>>>>>>
>>



More information about the hotspot-runtime-dev mailing list