2362N/A * Copyright (c) 2001, 2008, Oracle and/or its affiliates. All rights reserved. 0N/A * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 0N/A * This code is free software; you can redistribute it and/or modify it 0N/A * under the terms of the GNU General Public License version 2 only, as 0N/A * published by the Free Software Foundation. 0N/A * This code is distributed in the hope that it will be useful, but WITHOUT 0N/A * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 0N/A * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 0N/A * version 2 for more details (a copy is included in the LICENSE file that 0N/A * accompanied this code). 0N/A * You should have received a copy of the GNU General Public License version 0N/A * 2 along with this work; if not, write to the Free Software Foundation, 0N/A * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 2362N/A * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 2362N/A * or visit www.oracle.com if you need additional information or have any 0N/A * @summary When the RMI runtime (lazily) spawns system threads that could 0N/A * outlive the application context in which they were (happened to be) 0N/A * created, such threads should not inherit (thread local) data specific to 0N/A * such an application context for various isolation reasons (see 4219095). 0N/A * While there is not yet a practical means for a general solution to this 0N/A * problem, the particular problem documented in 4404702-- the inheritance 0N/A * of the parent thread's context class loader, preventing that loader from 0N/A * being garbage collected in the future-- can be easily fixed. This test 0N/A * verifies that the context class loader in effect when the first remote 0N/A * object is exported (and thus when some long-lived RMI daemon threads are 0N/A * created) can be garbage collected after the remote object has been 0N/A * unexported. [Note that this test is somewhat at the mercy of other J2SE 0N/A * subsystems also not holding on to the loader in their daemon threads.] 0N/A * @author Peter Jones 0N/A * @build RuntimeThreadInheritanceLeak_Stub 169N/A * HACK: Work around the fact that java.util.logging.LogManager's 169N/A * (singleton) construction also has this bug-- it will register a 169N/A * "shutdown hook", i.e. a thread, which will inherit and pin the 169N/A * current thread's context class loader for the lifetime of the VM-- 169N/A * by causing the LogManager to be initialized now, instead of by 169N/A * RMI when our special context class loader is set. 169N/A * HACK: Work around the fact that the non-native, thread-based 169N/A * SecureRandom seed generator (ThreadedSeedGenerator) seems to 169N/A * have this bug too (which had been causing this test to fail 169N/A * when run with jtreg on Windows XP-- see 4910382). 169N/A "exported remote object with loader as context class loader");
169N/A * HACK: Work around the fact that the sun.misc.GC daemon thread 169N/A * also has this bug-- it will have inherited our loader as its 169N/A * context class loader-- by giving it a chance to pass away. 169N/A "waiting to be notified of loader being weakly reachable...");
169N/A "TEST FAILED: loader not deteced weakly reachable");
169N/A "TEST FAILED: loader not detected weakly reachable");
169N/A "TEST PASSED: loader detected weakly reachable");
0N/A * Dumps information about all live threads to System.err, 0N/A * including their context class loaders. 169N/A "current live threads and their context class loaders:");