Support large Zip files for JVM/64-bit

[lzhou2025]

The changes are to remove the 4GB size limit of Zip files and support LARGE FILE for JVM/64-bit. This PR doesn't support LARGE FILE for JVM/32-bit.

Fixes: #23441

[lzhou2025]

I believe all comments are resolved, please reopen if missed.

[keithc-ca]

The commit message would be improved by explicitly stating that this support is not yet complete for 32-bit platforms.

[lzhou2025]

I believe all comments are resolved, please reopen if missed.
For the legacy codes written decades ago, signed 32-bit integer (IDATA) is widely used in 32-bit platforms, will be replaced by I_64 in the next PR to support #23458 and LARGE FILE in 32-bit platforms.

[lzhou2025]

That IDATA is widely used in the zip codes appears because of OMR,

omrfile_read(struct OMRPortLibrary *portLibrary, intptr_t fd, void *buf, intptr_t nbytes)

intptr_t should be uintptr_t or size_t, because the read() calls of Unix like systems or POSIX are size_t, unsigned.

[keithc-ca]

omrfile_read(struct OMRPortLibrary *portLibrary, intptr_t fd, void *buf, intptr_t nbytes)

intptr_t should be uintptr_t or size_t, because the read() calls of Unix like systems or POSIX are size_t, unsigned.

Yes, perhaps the OMR API could be improved, but that is unrelated to the concepts involved here. The file format allows for large entries and files, perhaps larger than could exist in memory at any given time. Things could still be made to work if OMR only allowed reading 32kB in a single call (in support of even 32-bit zip files).

[lzhou2025]

omrfile_read(struct OMRPortLibrary *portLibrary, intptr_t fd, void *buf, intptr_t nbytes)

intptr_t should be uintptr_t or size_t, because the read() calls of Unix like systems or POSIX are size_t, unsigned.

Yes, perhaps the OMR API could be improved, but that is unrelated to the concepts involved here. The file format allows for large entries and files, perhaps larger than could exist in memory at any given time. Things could still be made to work if OMR only allowed reading 32kB in a single call (in support of even 32-bit zip files).

omrfile_read(struct OMRPortLibrary *portLibrary, intptr_t fd, void *buf, intptr_t nbytes)

intptr_t should be uintptr_t or size_t, because the read() calls of Unix like systems or POSIX are size_t, unsigned.

Yes, perhaps the OMR API could be improved, but that is unrelated to the concepts involved here. The file format allows for large entries and files, perhaps larger than could exist in memory at any given time. Things could still be made to work if OMR only allowed reading 32kB in a single call (in support of even 32-bit zip files).

The ZIP format supports up to 4Gb size of each individual uncompressed file. But depending how to decompress it, if trying to allocate that size of memory buffer in 32-bit system, I agree, that will exceed the maximum memory space.

[lzhou2025]

OMR layer doesn't know what size of data is required in applications. Before the zip functions call OMR interfaces, should allocate memory buffers, which is fit to uncompress logic.

[lzhou2025]

ZIP64 & LARGE FILE support in two PRs:

• This PR will support it for JVM/64-bit environment
• Next PR (Support ZIP64 for JVM/32-bit lzhou2025/openj9#1), will support it for JVM/32-bit environment