blob: 08c9786574a44d88e216c90d7f82c060a06536e8 [file] [log] [blame]
Copyright (c) 2007, 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.
All gc/lock/ tests do approximately the same thing. They verify that GC
is appropriately synchronized with certain class of functions.
- gc/lock/jni - uses JNI GetPrimitiveArrayCritical and GetStringCritical
- gc/lock/jniref - uses JNI NewGlobalRef, NewLocalRef, NewWeakGlobalRef
- gc/lock/malloc - uses malloc()
- gc/lock/jvmti - uses JVMTI Allocate
A number of threads is started. There are some threads that repeatedly
enter a critical section of code where functions describe above are
repeatedly called in a loop. There are also some threads that eat
memory in a loop. The idea here is to force GC to crash or deadlock.