3 ms·
This isn't a bug in the compiler or the JVM. The Java spec explicitly allows this optimization to happen. From The Java Language Specification (SE 7), section 1
by DerekL 12y ago
This isn't a bug in the compiler or the JVM. The Java spec explicitly allows this optimization to happen. From The Java Language Specification (SE 7), section 12.6.1:
> Optimizing transformations of a program can be designed that reduce the number of objects that are reachable to be less than those which would naively be considered reachable. For example, a Java compiler or code generator may choose to set a variable or parameter that will no longer be used to null to cause the storage for such an object to be potentially reclaimable sooner.
Also, the "this" keyword is treated like a parameter. (See the end of section 2.6.1 of the JVM spec.)
- divs1210 12y agoso then why do you think the segfault is occurring?
- barrkel 12y agoFully agree. This is a well known issue that users of native interop from managed languages commonly encounter when they first start out. One of the first bugs I found in .NET related to this; the Ping component didn't expect that Finalize could be called on the same instance before a method on that instance finished executing. What is less convenient is that Java doesn't have a handy method to ensure that an object is reachable, that the JVM won't optimize away or eliminate. .NET has GC.KeepAlive; AFAIK, Java doesn't have an equivalent. I asked a question about this on SO[1] some time ago. An approximate equivalent can be cobbled together, with probabilistic assignments to a volatile variable. [1] http://stackoverflow.com/questions/22457002/whats-the-java-equivalent-of-nets-gc-keepalive http://stackoverflow.com/questions/22457002/whats-the-java-e...