[8u] RFR 6424123: JVM crashes on failed 'strdup' call

[Hohensee, Paul]

I took a look at the webrev. Doesn't seem that extensive (or risky) to me.

Summary of changes: 69 lines changed: 40 ins; 0 del; 29 mod; 31448 unchg.

If we don't do it, besides making future backports a bit more difficult, we'll have a (admittedly subtle) behavioral difference with Oracle, which in this case doesn’t seem justified to me.

Thanks,
Paul

On 7/16/20, 6:19 AM, "jdk8u-dev on behalf of Zhengyu Gu" <jdk8u-dev-retn at openjdk.java.net on behalf of zgu at redhat.com> wrote:

    >>
    >> To my mind, that doesn't really change anything from a technical
    >> standpoint, but I'll leave the final say to Andrew Haley.
    >
    > Hmm. Once strdup() has failed, the whole program is basically dead in
    > the water, and throwing an OutOfMemoryError only delays the
    > inevitable. It might even be argued that a VM error is more
    > informative than an OutOfMemoryError, because then the problem doesn't
    > look like heap exhaustion.
    >
    > The fact that this is now a parity backport does swing me more to
    > saying "yes", but this is an extensive change and that makes me
    > nervous, so I'm leaning towards "no". I am aware that I'm swithering
    > here, but it's a genuine dilemma: neither course of action is great.
    >

    So, it it a rejection?

    Another drawback for not backporting parity bugs, is making future
    backports harder.

    Thanks,

    -Zhengyu