69 lines
2.5 KiB
Plaintext
69 lines
2.5 KiB
Plaintext
Copyright (c) 2013, 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.
|
|
|
|
DESCRIPTION
|
|
|
|
This is a lock coarsening test. There are 2 threads, trying to acquire a shared
|
|
resource. The 1st thread has a number of adjacent lock that are subject to lock
|
|
coarsening:
|
|
|
|
...
|
|
|
|
synchronized( lock )
|
|
{
|
|
lock.foo();
|
|
}
|
|
|
|
// (*)
|
|
|
|
synchronized( lock )
|
|
{
|
|
lock.foo();
|
|
}
|
|
|
|
...
|
|
|
|
|
|
The test is written in such a way, that thread 2 will acquire the lock, if and
|
|
only if thread 1 is somewhere at point (*). Therefore, the fact that lock
|
|
coarsening occurred is described by the condition (numAcquiredLocks != 0).
|
|
|
|
IMPLEMENTATION
|
|
The test has one parameter, -eliminateLocks, that tells whether the JVM option
|
|
-XX:+EliminateLocks has been specified, so running the test without
|
|
-eliminateLocks checks that lock coarsening didn't occur, and running it with
|
|
this option check that lock coarsening occurred.
|
|
|
|
Some hacks have been made to force JIT compile the method doit() (see comments in
|
|
the source).
|
|
|
|
FAILURE ANALYSIS
|
|
If test fails try to run it with -XX:+PrintOptoAssembly and -XX:+LogCompilation
|
|
to understand if this is a test or product bug.
|
|
|
|
If compiled code of Thread_1::doit method have lot of locks that surround each
|
|
lock.foo() then coarsening did not happen and this is a product bug.
|
|
|
|
If lock coarsening occurs but not triggered by test then it's a test bug
|
|
that should be investigated. One of such problems could be caused if method doit()
|
|
was not compiled due to insufficient warm-up iterations. Also there may be a product bug
|
|
in compilation.
|