/*

 * Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights reserved.

 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

 *

 * This code is free software; you can redistribute it and/or modify it

 * under the terms of the GNU General Public License version 2 only, as

 * published by the Free Software Foundation.

 *

 * This code is distributed in the hope that it will be useful, but WITHOUT

 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or

 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License

 * version 2 for more details (a copy is included in the LICENSE file that

 * accompanied this code).

 *

 * You should have received a copy of the GNU General Public License version

 * 2 along with this work; if not, write to the Free Software Foundation,

 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.

 *

 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA

 * or visit www.oracle.com if you need additional information or have any

 * questions.

 */

/*

 * @test

 * @key stress

 *

 * @summary converted from VM testbase nsk/stress/except/except001.

 * VM testbase keywords: [stress, diehard, slow, nonconcurrent, quick]

 * VM testbase readme:

 * DESCRIPTION

 *     This checks if OutOfMemoryError exception is correctly enwrapped into

 *     InvocationTargetException when thrown inside a method invoked via

 *     reflection.

 *     The test tries to occupy all of memory available in the heap by

 *     allocating lots of new Object() instances. Instances of the "empty"

 *     type Object are the smallest objects, so they apparently should occupy

 *     most fine-grained fragments in the heap. Thus, there apparently should

 *     not remain any free space to incarnate new Throwable instance, and VM

 *     possibly could crash while trying to throw new OutOfMemoryError and

 *     enwrap it into new InvocationTargetException instance.

 *     By the way, the test checks time elapsed to allocate memory. Both

 *     classic VM and HotSpot seem to fall into poor performance of memory

 *     allocation when heap is almost over. E.g.: HotSpot 1.3-betaH may spend

 *     more than 1 minute to allocate next Object in this case (tested on

 *     Pentium-II, 350MHz, 128Mb RAM). To avoid this problem, the test enforce

 *     OutOfMemoryError if more then 5 minutes is spent to allocate "last bytes"

 *     of memory.

 * COMMENTS

 *     HotSpot releases 1.0-fcsE (both Win32 and Sparc), and 1.3-betaH (Win32)

 *     fail on this test due to poor performance of memory allocation.

 *         #4248801 (P3/S5) slow memory allocation when heap is almost exhausted

 *     Despite this bug is treated fixed in HotSpot 1.0.1, it still does suffer

 *     slow memory allocation when running on PC having 64Mb or less of RAM.

 *     There is also a workaround involved to avoid the following bugs known

 *     for HotSpot and for classic VM:

 *         #4239841 (P1/S5) 1.1: poor garbage collector performance  (HotSpot bug)

 *         #4245060 (P4/S5) poor garbage collector performance       (Classic VM bug)

 *     However, printing of the test's error messages, warnings, and of execution

 *     trace may fail under JDK 1.2 for Win32 even so.

 *     HotSpot 2.0-devA (Win32) crashes due to the known HotSpot bug:

 *         #4239828 (P1/S4) 1.3c1: VM crashes when heap is exhausted

 *

 * @run main/othervm -Xms50M -Xmx200M nsk.stress.except.except001

 */

package nsk.stress.except;

import java.io.PrintStream;

import java.lang.reflect.InvocationTargetException;

import java.lang.reflect.Method;

/**

 * This checks if <code>OutOfMemoryError</code> exception is correctly

 * enwrapped into <code>InvocationTargetException</code> when thrown inside

 * a method invoked via reflection.

 * <p>

 * <p>The test tries to occupy all of memory available in the heap by

 * allocating lots of new <code>Object()</code> instances. Instances of the

 * ``empty'' type <code>Object</code> are the smallest objects, so they

 * apparently should occupy most fine-grained fragments in the heap.

 * Thus, there apparently should not remain any free space to incarnate new

 * <code>Throwable</code> instance, and VM possibly could crash while trying

 * to throw new <code>OutOfMemoryError</code> and enwrap it into new

 * <code>InvocationTargetException</code> instance.

 * <p>

 * <p>By the way, the test checks time elapsed to allocate memory.

 * Both classic VM and HotSpot seem to fall into poor performance of memory

 * allocation when heap is almost over. E.g.: HotSpot 1.3-betaH may spend

 * more than 1 minute to allocate next <code>Object</code> in this case

 * (tested on Pentium-II, 350MHz, 128Mb RAM). To workaround this problem,

 * the test enforces <code>OutOfMemoryError</code> if more then 5 minutes

 * is spent to allocate ``last bytes'' of the memory.

 */

public class except001 {

    /**

     * This field allows or supresses printing with <code>display()</code>

     * method.

     *

     * @see #display(Object)

     * @see #complain(Object)

     * @see #out

     */

    private static boolean MODE_VERBOSE = true;

    /*

    * Storage for a lot of tiny objects

    * "static volatile" keywords are for preventing heap optimization

    */

    private static volatile Object pool[] = null;

    /**

     * Print execution trace if <code>MODE_VERBOSE</code> is <code>true</code>

     * (optional).

     *

     * @see #MODE_VERBOSE

     * @see #complain(Object)

     * @see #out

     */

    private static void display(Object message) {

        if (MODE_VERBOSE)

            out.println(message.toString());

        out.flush();

    }

    /**

     * Print error <code>message</code>.

     *

     * @see #display(Object)

     * @see #out

     */

    private static void complain(Object message) {

        out.println("# " + message);

        out.flush();

    }

    /**

     * The log-stream assigned at runtime by the method

     * <code>run(args,out)</code>.

     *

     * @see #display(Object)

     * @see #complain(Object)

     * @see #run(String[], PrintStream)

     */

    private static PrintStream out;

    /**

     * Try to allocate lots of instances of the type <code>Object</code>.

     * Such instances are most fine-grained, and thus they should occupy

     * smallest fragments of free memory in the heap.

     * <p>

     * <p>By the way, break the test, if JVM has spent more than

     * 5 minutes to allocate latest portions of memory.

     */

    public static void raiseOutOfMemory() throws OutOfMemoryError {

        try {

            // Repository for objects, which should be allocated:

            int index = 0;

            for (int size = 1 << 30; size > 0 && pool == null; size >>= 1)

                try {

                    pool = new Object[size];

                } catch (OutOfMemoryError oome) {

                }

            if (pool == null)

                throw new Error("HS bug: cannot allocate new Object[1]");

            // Sum up time spent, when it was hard to JVM to allocate next object

            // (i.e.: when JVM has spent more than 1 second to allocate new object):

            double totalDelay = 0;

            long timeMark = System.currentTimeMillis();

            for (; index < pool.length; index++) {

                //-------------------------

                pool[index] = new Object();

                long nextTimeMark = System.currentTimeMillis();

                long elapsed = nextTimeMark - timeMark;

                timeMark = nextTimeMark;

                //----------------------

                if (elapsed > 1000) {

                    double seconds = elapsed / 1000.0;

                    display(

                            "pool[" + index +

                                    "]=new Object(); // elapsed " + seconds + "s");

                    totalDelay += seconds;

                    if (totalDelay > 300) {

                        complain(

                                "Memory allocation became slow: so heap seems exhausted.");

                        throw new OutOfMemoryError();

                    }

                }

            }

            // This method should never return:

            throw new Error("TEST_BUG: failed to provoke OutOfMemoryError");

        } finally {

            // Make sure there will be enough memory for next object allocation

             pool = null;

        }

    }

    /**

     * Invoke the method <code>raiseOutOfMemory()</code> with reflection,

     * and check if the exception it throws is just

     * <code>OutOfMemoryError</code> enwrapped into

     * <code>InvocationTargetException</code> instance.

     * <p>

     * <p>Before the test begins, <code>this.out</code> filed is assigned

     * to the parameter <code>out</code>. Parameter <code>args[]</code>

     * is ignored.

     *

     * @see #raiseOutOfMemory()

     */

    public static int run(String args[], PrintStream out) {

        out.println("# While printing this message, JVM seems to initiate the output");

        out.println("# stream, so that it will not need more memory to print later,");

        out.println("# when the heap would fail to provide more memory.");

        out.println("# ");

        out.println("# That problem is caused by the known JDK/HotSpot bugs:");

        out.println("#     4239841 (P1/S5) 1.1: poor garbage collector performance");

        out.println("#     4245060 (P4/S5) poor garbage collector performance");

        out.println("# ");

        out.println("# This message is just intended to work-around that problem.");

        out.println("# If printing should fail even so.");

        if (args.length > 0) {

            if (args[0].toLowerCase().startsWith("-v"))

                MODE_VERBOSE = true;

        }

        except001.out = out;

        Class testClass = except001.class;

        try {

            Method testMethod = testClass.getMethod("raiseOutOfMemory", new Class [0]);

            Object junk = testMethod.invoke(null, new Object [0]);

        } catch (InvocationTargetException ite) {

            Throwable targetException = ite.getTargetException();

            if (targetException instanceof OutOfMemoryError) {

                display("OutOfMemoryError thrown as expected.");

                display("Test passed.");

                return 0;

            }

            complain("Unexpected InvocationTargetException: " + targetException);

            complain("Test failed.");

            return 2;

        } catch (Exception exception) {

            complain("Unexpected exception: " + exception);

            complain("Test failed.");

            return 2;

        }

        //

        complain("The test has finished unexpectedly.");

        complain("Test failed.");

        return 2;

    }

    /**

     * Re-call to <code>run(args,out)</code>, and return JCK-like exit status.

     * (The stream <code>out</code> is assigned to <code>System.out</code> here.)

     *

     * @see #run(String[], PrintStream)

     */

    public static void main(String args[]) {

            // Last try. If there is some exception outside the code, test should end correctly

            @Override

            public void uncaughtException(Thread t, Throwable e) {

                try {

                    pool = null;

                    System.gc();

                    if (e instanceof OutOfMemoryError) {

                        try {

                            System.out.println("OOME : Test Skipped");

                            System.exit(95);

                        } catch (Throwable ignore) {

                        } // No code in the handler can provoke correct exceptions.

                    } else {

                        e.printStackTrace();

                        throw (RuntimeException) e;

                    }

                } catch (OutOfMemoryError oome) {

                }

            }

        });

        int exitCode = run(args, System.out);

        System.exit(exitCode + 95);

        // JCK-like exit status.

    }

}