Hacker News Reader

Comment by parttimenerd | Hacker News Reader

Thanks. But this should only be a problem if the JVM terminates too fast, or am I wrong?

For the context, I'm re-reading Java concurrency in Practice now so I see publication issues everywhere.

I believe the issue is between the profiler thread and the shutdown hook thread. Both will run concurrently because the profiler thread is marked deamon. So the shutdown hook thread can see the Profiler fields not fully initialized. The call to addShutdownHook() should be done outside of the Profiler constructor.

You are correct. The solution is to use a static constructor method, like this:

    public static Profiler newInstance(Options options) {
        Profiler profiler = new Profiler(options);
        Runtime.getRuntime().addShutdownHook(new Thread(profiler::onEnd));
        return profiler;
    }

    private Profiler(Options options) {
        this.options = options;
        this.store = new Store(options.getFlamePath());
    }

In principle you can also use chained constructors:

    public Profiler(Options options) {
        this(options, null);
        Runtime.getRuntime().addShutdownHook(new Thread(this::onEnd));  // okay to leak this here
    }

    private Profiler(Options options, Void dummy) {
        this.options = options;
        this.store = new Store(options.getFlamePath());
    }

(cf. https://stackoverflow.com/a/35169705/623763)

Thank you. I fixed the code in the GitHub repository but kept the code on my blog the same, with a disclaimer regarding its problems.

It would have to be very quick as it would need the thread to be started before your object has finished being constructed. So it seems unlikely. What's not clear to me from a quick reading of the code is whether the store is actually correct. Although it is only being filled by a single thread that isn't the one that is going to read it on shutdown and I'm not clear on whether there is anything forcing a barrier before the onExit thread has starts reading the hash maps on the nodes.

Actually, is there anything stopping the sampler from taking another sample while onExit is running?

Would `volatile` help with the barrier?

Re the multi-threading issue, it should be possible to stop the profiler thread in the hook, if we keep a reference to the thread, no?

The fields are final, so they can't be volatile. :-) Using one of the fence methods on VarHandles would ensure the correct ordering. To stop the profiler thread it would be best to provide a controlled method of doing it, there's a lot of way it can be implemented but you probably want to signal it in some way and then do a join() to wait while it shuts down cleanly.

Thanks, I implemented it using a boolean flag.

Reply on news.ycombinator.com