tag:blogger.com,1999:blog-1468479222802516939.post7549414512753381979..comments2023-09-30T05:55:46.349-04:00Comments on The Virtual Machinist: A subtle issue of reachabilityPeter Burkahttp://www.blogger.com/profile/15290253671442020919noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-1468479222802516939.post-59388862766958181552011-07-12T17:46:42.349-04:002011-07-12T17:46:42.349-04:00asvitkine: That might help in some cases, but can ...asvitkine: That might help in some cases, but can also just obscure the problem.<br /><br />What if you use a tool which in-lines methods directly in bytecode? javac used to do this in early versions, and there are a number of optimizers and obfuscators (e.g. http://proguard.sourceforge.net/) which do the same thing. Even if the VM treated the receiver (or all arguments) specially, in-lining a method using one of these tools could still change the reachability of objects.<br /><br />What if you're using invokedynamic (new in Java 7)? The "receiver" of a method might not be the first argument, or the method could be multidispatch polymorphic, in which case it could have more than one argument with a claim to be the receiver!Peter Burkahttps://www.blogger.com/profile/15290253671442020919noreply@blogger.comtag:blogger.com,1999:blog-1468479222802516939.post-11885739289390457522011-07-11T16:02:05.426-04:002011-07-11T16:02:05.426-04:00I'd argue that the VM should be treating the o...I'd argue that the VM should be treating the object referenced until any instance method of that object returns - sure it's not in the current spec (so a VM developer can shrug off any blame by pointing at the spec), but its the most intuitive behaviour as far as the programmer is concerned and certainly beats polluting the language with extra specialized keywords like keep_alive().Alexeihttps://www.blogger.com/profile/00312840128170044949noreply@blogger.comtag:blogger.com,1999:blog-1468479222802516939.post-3347808612462097662011-07-11T10:28:00.400-04:002011-07-11T10:28:00.400-04:00Of course, Peter, I approach this from the point o...Of course, Peter, I approach this from the point of view of OSGi, which adds component modularity to Java. Every module has a lifecycle that supports calling methods such as startup() and shutdown(). The big challenge is getting developers to understand how to design and implement Java modules, and it's even harder to get them to understand why loosely coupled and highly cohesive modules are a good thing. The new try-with-resources support in Java 7 sounds interesting... I must investigate. Thanks.Simon Archerhttps://www.blogger.com/profile/03583004412891607822noreply@blogger.comtag:blogger.com,1999:blog-1468479222802516939.post-21350224453207551322011-07-10T23:15:40.370-04:002011-07-10T23:15:40.370-04:00Simon: Your approach is sound. The difficulty is m...Simon: Your approach is sound. The difficulty is making sure that the shutdown() function is called in all paths, including errors. Java has some good tools to help with this, like try-finally and the new try-with-resources support in Java 7. (I think this Project Coin feature made it into Java 7).Peter Burkahttps://www.blogger.com/profile/15290253671442020919noreply@blogger.comtag:blogger.com,1999:blog-1468479222802516939.post-84216255712817295372011-07-10T22:01:35.647-04:002011-07-10T22:01:35.647-04:00Yes, finalize() is a dangerous method to rely upon...Yes, finalize() is a dangerous method to rely upon. But some developers yearn for a destructor in Java. My approach is to think of a constructor as an initializer, and then implement my own life-cycle methods, such as startup() and shutdown() that do the necessary construction and destruction of an object. Of course, these methods are not magic and must be called explicitly. And likewise, I never intend to implement a finalize() method since it's way more rope than I need.Simon Archerhttps://www.blogger.com/profile/03583004412891607822noreply@blogger.com