5 ms·

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

_old_dude_ 4y ago
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.
- layer8 4y ago
  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 https://stackoverflow.com/a/35169705/623763)
  - parttimenerd 4y ago
    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.
aardvark179 4y ago
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?
- brewmarche 4y ago
  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?
  - aardvark179 4y ago
    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.
    - parttimenerd 4y ago
      Thanks, I implemented it using a boolean flag.

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.

layer8 4y ago
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 https://stackoverflow.com/a/35169705/623763)
- parttimenerd 4y ago
  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.

aardvark179 4y ago

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?

brewmarche 4y ago
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?
- aardvark179 4y ago
  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.
  - parttimenerd 4y ago
    Thanks, I implemented it using a boolean flag.