Add a workaround for empty Slice copy SIGSEGV

[lukasz-stec]

Description

Due to jvm bug, compiled code could fail
with SIGSEGV when copying 0 bytes from an empty Slice.
This change avoids copy attempts altogether, which
additionally increases performance in empty Slice case.

Is this change a fix, improvement, new feature, refactoring, or other?

fix

Is this a change to the core query engine, a connector, client library, or the SPI interfaces? (be specific)

core query engine

How would you describe this change to a non-technical end user or system administrator?

Avoid worker process crash when using vulnerable JVM version

Related issues, pull requests, and links

• Fixes JVM crashing with SIGSEGV due to union query #12821

Documentation

( ) No documentation is needed.
( ) Sufficient documentation is included in this PR.
( ) Documentation PR is available with #prnumber.
( ) Documentation issue #issuenumber is filed, and can be handled later.

Release notes

( ) No release notes entries required.
( ) Release notes entries required with the following suggested text:

# Section
* Fix some things. ({issue}`issuenumber`)

[findepi]

• Fixes JVM crashing with SIGSEGV due to union query #12821

@martint offered a different fix: #12841

[lukasz-stec]

• Fixes JVM crashing with SIGSEGV due to union query #12821

@martint offered a different fix: #12841

This change may also be considered a performance improvement (avoiding unnecessary work)

[electrum]

Per the Javadoc for Unsafe:

Note: It is the responsibility of the caller to make sure arguments are checked before the methods are called. While some rudimentary checks are performed on the input, the checks are best effort and when performance is an overriding priority, as when methods of this class are optimized by the runtime compiler, some or all checks (if any) may be elided. Hence, the caller must not rely on the checks and corresponding exceptions!

However, I can't see an argument that copying zero bytes should ever try to read from the source, so this does indeed seem like a bug in the JVM.

[martint]

#12841 is merged, so this workaround shouldn't be needed anymore.

[lukasz-stec]

#12841 is merged, so this workaround shouldn't be needed anymore.

let's close it.

[raunaqmorarka]

@lukasz-stec could we keep the test case from this PR to detect this problem more easily in case it reoccurs in future ?

[lukasz-stec]

@lukasz-stec could we keep the test case from this PR to detect this problem more easily in case it reoccurs in future ?

@raunaqmorarka created #12927