[concurrency-interest] Mechanical sympathy used in hashtable

Kirk Pepperdine kirk at kodewerk.com
Mon Jun 17 03:14:15 EDT 2013


Hi Peter,

Every VM I've ever used has an equivalent to unsafre. So if this is an historical artifact it seems sensible that we finally recognize the need and get a spec for it. I'd also suggest that there is behaviour such as Fence that should be moved into the JDK. Unfortunately this couldn't happen until 9 but for it to be in 9 work on it would have to start now.

-- Kirk

On 2013-06-16, at 1:01 PM, Peter Lawrey <peter.lawrey at gmail.com> wrote:

> Gil's very good arguments aside, while sun.misc.Unsafe is rarely missing as a class, it's methods are not the same across JVMs.  So while you can be reasonably sure the class exists, you can't be sure that all it's methods exist or what they might do.  From example, if you do a 
> 
>     UNSAFE.putOrderedInt(Object o, long offset, int value)
> 
> It is pretty vague about what happens if you give it a null and if you call this with putOrderInt(null, address, value) this will write to an address not an object. But you can't be sure unless you test it.
> 
> The Javadoc says
> 
> > @param Object o Java heap object in which the variable resides, if any, else null
> > @param offset indication of where the variable resides in a Java heap object, if any, else a memory address locating the variable statically
> 
> In short Unsafe is a hack, almost by design, but without a spec.  It is very much use at your own risk.
> 
> Why do I use Unsafe?  because the alternative is to use JNI in some cases, and this is less portable (between OSes 32/64-bit), slower, no more reliable and more difficult to work with than using Unsafe.
> 
> Peter.
> .
> 
> 
> On 16 June 2013 00:00, Gil Tene <gil at azulsystems.com> wrote:
> It's got nothing to do with portability, and everything to do with the big bad waring sign hanging on top of the entire name space.
> 
> Unsafe is.... Un-Safe!
> 
> As in "nothing is guaranteed to be checked." and "Any use of this without knowing exactly what you are doing and how the JVM will handle it may result in random crashes in your code."
> 
> Remember:
> 
> - You can access the wrong field of an object with unsafe.
> 
> - You can easily corrupt the heap with unsafe.
> 
> - There is no consistent bounds checking, type checking or any other checking being enforced.
> 
> The reason you see most JVMs implement sun.misc.Unsafe is not that it's part of some standard. It's simply becasue most JDKs use core libraries that are based on Sun/Oracle's core library implementation, and the quickest way to support that code with a new JVM is to implement the same ad-hoc APIs that happen to be needed by the precise version of library code used.
> 
> Unsafe is intended to inly be used from within the core libraries that ship with the JDK. It was never intended to be used by "user" code directly. The fact that this can be done so easily is a bug. The fact that so many people are actually using it is a very real problem. The notion that having a way to do something with Unsafe means we don't need an actual, well-speced Java API for that behavior is plain dangerous. Any common use of Unsafe form outside of the JDK libraries should be taken seriously (much more so than it seems to be) as a hint that future JDK specs need to add some proper API spec'ed functionality to cure the evident need to do this obviously broken stuff.
> 
> Remember, Unsafe it is nowhere in the Java SE Spec. It is (quite intentionally) not well documented and is not an official API for Java applications to use or rely on. A compatible Java platform doesn't need to expose it (or even have it) in any way.
> 
> Unsafe APIs can legitimately be modified and "broken" in any JDK release (including underscores releases). All it takes to [legitimately] get rid of or change the semantics of an existing unsfae API call is to have all the code in the core libraries (and *only* in the core libraries) that ship in the same JDK as the new JVM change to adapt. Since the two are released and shipped together, that's a pretty simple thing to do (and actually happens more often than you may think).
> 
> My biggest issue is knowing what to do when things crash. We have this relatively rare clarity in the JVM world: As a JVM builder, if a JVM crashes, our knee jerk assumption is that we have a bug in our code. "User code" is never supposed to be able to core-dump a JVM. If a JVM core dumps, it is *always* a JVM bug. Unless, of course, the user code happens to have used Unsafe or JNI, and corrupted things with some bug. We make it intentionally extra-hard for JNI to corrupt and mess up the Java heap. Unfortunately Unsafe is basically a toolchain for messing up and corrupting the heap.
> 
> So, back to the original point in hand: Fence operations should be added in the form of actual Java APIs. Using them before that, especially if they are just now being added, is a very risky thing from a code longevity point of view.
> 
> -- Gil.
> 
> On Tuesday, June 11, 2013 9:27:58 AM UTC-4, Wojciech Kudla wrote:
> > Because it's not portable
> 
> Any example of a popular JVM with sun.misc.Unsafe missing?
> 
> 
> 2013/6/11 Simone Bordet <sbo... at intalio.com>
> Hi,
> 
> >> 2013/6/11 Kirk Pepperdine <ki... at kodewerk.com>
> 
> >> Too bad they are in unsafe... :-\
> 
> > On Tue, Jun 11, 2013 at 3:09 PM, Michał Warecki <michal.... at gmail.com> wrote:
> > Hmm, Why? Do you see better place for them?
> 
> Because it's not portable.
> Does not work in non-Oracle JVMs, and it's very OSGi unfriendly: for
> applications to use Unsafe in OSGi, you need to crack a black egg,
> spill dragon blood, burn everything with a fire ignited by a lightning
> and, well... just hope.
> 
> --
> Simone Bordet
> ----
> http://cometd.org
> http://webtide.com
> http://intalio.com
> Developer advice, training, services and support
> from the Jetty & CometD experts.
> Intalio, the modern way to build business applications.
> 
> -- 
> You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130617/2d9e63ba/attachment-0001.html>


More information about the Concurrency-interest mailing list