David, On 2015-01-13 08:10, David Holmes wrote: > > Short version: okay but I'm going to file a bug to have sun.misc.Perf > fixed properly.
Thank you and please, file a new bug (you can assign it to me directly). -Dmitry > > Long version ... read below :) > > Thanks, > David > > On 12/01/2015 11:49 PM, Dmitry Samersoff wrote: >> Hi Everybody, >> >> Please review the fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-7076820/webrev.01/ >> >> The fix explicitly checks for UsePerfData and if it's false make >> Perf:detach a NOP. > > That sidesteps the assertion failure but there is a bigger semantic > issue here I think - which is why the bug has remained open for so long. > UsePerfData can disable a part of the backend of the "perf" > functionality used via sun.misc.Perf, but sun.misc.Perf is completely > oblivious to that. It isn't even really clear what UsePerfData pertains > to. It impacts PerfMemory turning a number of methods into no-ops - but > it doesn't turn PerfMemory::attach nor PerfMemory::detach into no-ops. > What is a no-op is the initialization of PerfMemory (perfMemory_init) > during VM startup, and also the teardown (perfMemory_exit) during VM > shutdown (via at_exit handler). So the VM responds to the -UsePerfData > flag (in part) by not initializing the PerfMemory subsystem, but the > PerfMemory public apis are still enabled and invoked from the JDK code. > That doesn't make sense to me - we should fail to attach and in doing so > not put in place the Cleaner code that will attempt the detach. But > sun.misc.Perf doesn't understand that anything can fail. :( > > Your workaround avoids calling PerfMemory::detach from the Perf_detach > code by checking UsePerfData, but arguably the check should be inside > PerfMemory::detach operation (which unfortunately is OS specific). > >> >> -Dmitry >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.