vakabus / gcopdd Goto Github PK

Making them synchronized may be slow. Other solutions involve adding more complexity, methods, fields.

public static Foo getInstance() {
    if (instance == null) {
        /* HERE */
        instance = new Foo();
    }
    return instance;
}

Suppose following:

1. instance field is null.
2. Thread A calls getInstance() and gets to /* HERE */.
3. Thread A is preempted.
4. Thread B calls getInstance(), and as instance field is still null, it creates, saves and returns a new instance.
5. Thread B finishes or is preempted.
6. Thread A is resumed and continues from /* HERE */. A new instance of Foo is created, saved and returned.

For example, when you dump reports from this JAR file without renaming it, dump-browser won't display anything at all, even when you wan't to look at a different report.
http://repo.scalabench.org/snapshots/org/scalabench/benchmarks/scala-benchmark-suite/0.1.0-SNAPSHOT/scala-benchmark-suite-0.1.0-20120216.103539-3.jar

My proposed solution would be to dump metadata into another file and do not keep them in the filename. That's calling for trouble What if I name my program %20.jar or a+b.jar, this might also cause other problems...

So far, we are only working on dependency matrix collection. But there will be more tools, they will all need to export some data and they will all need some configuration. We should come up with a system to make everything work together.

We should consider:

• runtime data collection configuration
• compile time collection tool selection
• data dumping unification

If compilation can occur in multiple threads (and you use concurrent hash maps for phase dependency tracking), should perhaps the DependencyValue updates be atomic or synchronized ?

When running in CI, about half of build time is spent cloning Graal as a submodule. Shallow clones didn't work when the build system was first set up. We should determine if it's still the case and/or fix it.