RFR: JDK-8205549 JDK-8205698 Support of flattened values in Unsafe

Frederic Parain frederic.parain at oracle.com
Fri Jun 29 21:50:01 UTC 2018


Breaking the rules even internally is dangerous.
There’s currently no guarantee at the Java level that the
value being operated on is not shared with other threads.
__MakeDefault is not new, you don’t have the guarantee that
you’ll get a fresh unshared value.In fact, it currently returns
a shared instance, and modifying it would corrupt all future
new values. Many other optimizations are already in place in
the JVM strongly relying on the immutability of values, adding
sharing and aliasing in many places (arrays, LVT in the
interpreter). Situation is even worse in JIT compiled code,
where object_base + offset has no direct meaning because
of values scalarization.

I like the caveat "as long as the intermediate breaking effects
are contained and cannot be observed externally”, but I’m
curious to know how it will be checked or enforced.

Fred


> On Jun 29, 2018, at 17:36, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> 
>> This also reminds me that we need a way to use Unsafe
>> to patch value instance fields.  Here's how I would like to
>> do this, as a first cut:
>> 
> 
> That’s a good observation. The lack of enforcement on Unsafe allow us to internally break the rules (as long as the intermediate breaking effects are contained and cannot be observed externally). I can see interesting usages for object + fused tail and writing values to that tail, or even perhaps scribbling values that contain no oops to a byte buffer.
> 
> Paul.




More information about the valhalla-dev mailing list