jcstress | https | Testing library
kandi X-RAY | jcstress Summary
kandi X-RAY | jcstress Summary
The Java Concurrency Stress (jcstress) is the experimental harness and a suite of tests to aid the research in the correctness of concurrency support in the JVM, class libraries, and hardware.
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
- Main entry point
- Run the test
- Rehashes the map
- Copies the given result
- Emit test report for given test
- Selects the color of the given type
- Print the header of the test result
- Formats the command line options
- Returns a line for the given option descriptor
- Drains the stream
- Prints out allocation profile
- Returns all keys in the specified multiset
- Get the Unsafe Unsafe
- Copy a file to a temporary file
- Main method for testing
- Two actors
- Gets the global affinity map
- Post update
- Awaits until the checkpoint is reached
- Convert an object to string representation
- Generate a string representation of the result
- Acquires the specified instance
- Command line parser
- Renumber all packages
- Tries to initialize allocation
- Renumber cores
jcstress Key Features
jcstress Examples and Code Snippets
Community Discussions
Trending Discussions on jcstress
QUESTION
While playing with some jcstress code, I noticed two parameters that are very new to me: StressLCM and StressGCM.
The very first thing to do for me was searching for these in the source code itself and while I have found some things, it is still unclear what they actually do. I was really hoping to see some comments in the source code that would shed some light, but no luck.
I also found the bug description where these have been added, but the explanation made no sense for me:
Randomize instruction scheduling in LCM/GCM.
Can someone explain what they do, if possible in plain english?
...ANSWER
Answered 2019-May-23 at 16:05LCM / GCM stands for Local Code Motion / Global Code Motion. To optimize CPU utilization, compiler may reorder independent instructions without changing the semantics of the code. Compiler tries to find the most optimal (from performance perspective) order of instructions. This is called instruction scheduling, and that's what LCM / GCM do.
With -XX:+StressLCM / -XX:+StressGCM options the instruction scheduling works in a bit different way. It no longer tries to find the best schedule, but instead chooses a random instruction order within the allowed constraints, still keeping the original semantics unchanged. Such nondeterministic behavior helps to test more combinations of instruction interleaving, which is essential in finding subtle concurrency issues.
QUESTION
I'm new to JCStress and I'm trying to run the "hello world" for JCStress but facing some problems. I think there is some obvious thing that I'm missing.
I'm following this link to learn. And the samples that I'm trying are here.
I started with the template project created from the following public maven archetype:
...ANSWER
Answered 2018-Nov-24 at 14:10Ah, I figured out what I was missing.
We need to do a mvn clean install to get MyConcurrencyTest into the META-INF/TestList file.
Now I can run
QUESTION
I am trying to get to grips with JCStress. To ensure I understand it, I decided to write some simple tests for something that I know must be correct: java.util.concurrent.locks.ReentrantReadWriteLock.
I wrote some very simple tests to check lock mode compatibility. Unfortunately two of the stress tests are failing:
...X_S:
ANSWER
Answered 2018-Oct-04 at 07:16Your tests pass when run against jcstress 0.3. In version 0.4 the behaviour changed to include the results of the sanity checks that are run on startup (see this commit against the bug jcstress omits samples gathered during sanity checks).
Some of the sanity checks run in a single thread, and your test doesn't handle the case where both actors are called by the same thread; you're testing a reentrant lock, so the read lock will pass if the write lock is already held.
This is arguably a bug in jcstress, as the documentation on @Actor says the invariants are:
- Each method is called only by one particular thread.
- Each method is called exactly once per
Stateinstance.
While the documentation is not that clearly worded, the generated source makes it clear that the intention is to run each actor in its own thread.
One way to work around it would be to allow the single threaded case to pass:
QUESTION
I have main pom, and two modules (sub poms), first of them contains dependency to log4j. First module - some utility classes. Second - tests for first module (jcstress) that compiles to sub-jar using shade plugin. compilation works fine, but then run tests (second module), it fails with this error. I have to dependencies for log4j in first module and they are copied to second one:
...ANSWER
Answered 2018-Jun-05 at 08:56Remove log4j dependency in your POM and Add this dependency
QUESTION
@State
@JCStressTest
public class M {
class A {
int f;
A() {
f = 42;
}
}
private A a;
@Actor
void actor1(){
a = new A();
}
@Actor
void actor2(IntResult1 r){
r.r1 = 1;
if(a != null){
r.r1 = a.f;
}
}
}
ANSWER
Answered 2017-Sep-03 at 01:48I know that is is not obvious that I should see that output, but it's possible and I would like to see it.
You are correct that your code does have a data race.
(There is no happens-before chain between f = 42 and ... = a.f deducible under the rules set out in the JMM. Therefore, it is not guaranteed that a.f will always see the value 42.)
However, the nature of this race is such that it will only occur in extremely rare scenarios. It would most likely require a system with multiple cores, and either high memory load or an involuntary thread context switch at just the wrong instant. And it would be dependent on the native code emitted by the JIT compiler1.
Is there any JVM option (like XX:....) to enforce it?
Unfortunately, no there isn't.
1 - Note you cannot draw sound inferences from the bytecodes. The JIT compiler is allowed (by the JLS / JVMS) to reorder instructions including memory reads and writes provided that they don't violate the JMM rules. This is important for performance of multi-threaded code.
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install jcstress
You can use jcstress like any standard Java library. Please include the the jar files in your classpath. You can also use any IDE and you can run and debug the jcstress component as you would do with any other Java program. Best practice is to use a build tool that supports dependency management such as Maven or Gradle. For Maven installation, please refer maven.apache.org. For Gradle installation, please refer gradle.org .
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page
