Pushed into tl8. Thanks for the reviews! On Mon, Jan 28, 2013 at 3:36 AM, Alan Bateman <alan.bate...@oracle.com>wrote:
> On 26/01/2013 17:14, Martin Buchholz wrote: > >> : >> Following up on this, I have a simple webrev: >> >> http://cr.openjdk.java.net/~**martin/webrevs/openjdk8/**LARGEFILE/<http://cr.openjdk.java.net/~martin/webrevs/openjdk8/LARGEFILE/> >> >> with an "obviously correct" fix. However: >> >> - we need a bug filed >> - This change is completely untested. I no longer have access to native >> 32-bit systems where this bug might be manifested. I have not tried to >> actually provoke a failure, although it should not be too hard to create a >> 3GB jar file with the contents of interest at the end, on a system where >> off_t is signed 32-bit. >> - As we discussed, it might be better to have a JLI_Open (or even better, >> common C-level infrastructure for the whole project) but only you guys >> have >> access to the variety of systems to write and test such a thing, even if >> it >> is just a few lines of code. >> >> So next step here is up to you. >> > I've created a bug to track this first installation: > > 8006995: java launcher fails top en executable JAR > 2GB > > I think the proposed changes are okay, a no-brainer really. It would be > nice if the open were moved to platform specific code, then we could use > open64 and drop O_LARGEFILE flag. That might be something for future > refactoring (I think JLI_Open was suggested in an earlier mail). > > Ideally we should have a test but we've had a lot of bad experience with > files that need multi-GB zip files (slow, need lots of disk space) so I > think it would be saner to leave it out this time. > > -Alan. >
