up!
Dan
Original Message
Subject: Re: hsx24 backport: Request for review: 712: GC log is
limited to 2G for 32-bit
Date: Mon, 01 Jul 2013 23:05:46 -0700
From: Tao Mao
Organization: Oracle Corporation
To: hotspot-gc-...@openjdk.java.net
, build-dev@openjdk.java.net
ev.01/
(original) hsx25 webrev:
http://cr.openjdk.java.net/~tamao/712/webrev.00/
Test:
Builds were tested on Linux-i586, Solaris-i586, and Solaris-sparc.
Builds were successful and they all passed test of the gc-log size limit
of 2G.
Passed JPRT.
Thanks.
Tao
On 7/1/13 1:18 PM, Tao Mao
ev.01/
(original) hsx25 webrev:
http://cr.openjdk.java.net/~tamao/712/webrev.00/
Test:
Builds were tested on Linux-i586, Solaris-i586, and Solaris-sparc.
Builds were successful and they all passed test of the gc-log size limit
of 2G.
Thanks.
Tao
On 7/1/13 1:18 PM, Tao Mao wrote:
The hsx2
The hsx25 fix has been pushed already. Then I got the
7u40-critical-approved.
When I tried backporting to hsx24, it didn't apply to the hsx24 repo
cleanly. Thus, I made the patch manually (copy-and-paste style) and now
need some quick reviews to get it in since it's 7u40 related P3 CR.
hsx24
f);
#endif // defined(_LP64) || defined(_GNU_SOURCE) || _FILE_OFFSET_BITS==64
This piece of code handles some exception I need to fix. It is not what
I want to change but rather what I have to change.
Please see inline.
Thanks.
Tao
On 6/5/13 9:02 AM, Mikael Gerdin wrote:
Tao,
On 2013-06-05 17:
ndows, that the CRT fopen() already seems to
handle large files and that ftell64() and fseek64() have slightly
different names on Windows. I don't think this is a large hurdle and I
think we know how to solve this problem.
As I said, nothing was changed for Windows code.
/Mikael
Dan
On 6
Thank you for reviewing, Tim.
Tao
On 6/4/13 5:30 PM, Tim Bell wrote:
I am OK with the Makefile changes.
Dan - Thanks for looking after the deeper questions.
Tim
On 06/ 4/13 05:25 PM, Tao Mao wrote:
Thank you for your explanation and a "OK", Dan.
Tao
On 6/4/13 5:21 PM, Daniel D.
ile at the same
time, then we have bigger issues. :-)
I'm good with these changes now. I agree that solving the problem of
setting _FILE_OFFSET_BITS=64 for the entire VM build doesn't have to
solved right now.
Dan
On 6/4/13 6:06 PM, Tao Mao wrote:
Thank you for review, Dan.
I'll
the RDP2 limit, but this
change has too many open questions (for now)...
BTW, it is not at all clear whether Win32 will be able to write a 2GB+
GC log or not. The conversation below didn't help me at all.
I used a jdk7 (just any) to successfully generate a log file larger than
4GB. So, it s
ODEL ?= 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 ch
Thank you, Thomas.
Tao
On 6/4/13 4:11 PM, Thomas Schatzl wrote:
On Tue, 2013-06-04 at 16:03 -0700, Tao Mao wrote:
Since the changeset touched makefiles, I've included
build-dev@openjdk.java.net .
I need to push the hsx24 bug asap. Please review it.
Looks okay to me.
Thomas
Since the changeset touched makefiles, I've included
build-dev@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,
Please reply to this thread to make sure all interested parties can see it.
Tao
On 2/20/2013 11:53 AM, John Coomes wrote:
Erik Joelsson (erik.joels...@oracle.com) wrote:
I was wrong, just setting the macros below did not generate 10.7
compatible bits when built on 10.8. Since I already pushed t
13 matches
Mail list logo
