RFC (round 1), JEP draft: Low-level Object layout introspection methods

[Peter Levart]

On 8/17/20 5:57 PM, Andrew Dinn wrote:
> On 17/08/2020 16:19, Michael Kuhlmann wrote:
>> On 8/17/20 4:57 PM, Peter Levart wrote:

correction...


On 8/17/20 2:55 PM, Michael Kuhlmann wrote:
>> True, but when Unsafe is not available any more, you can't do much with
>> these numbers at all. Then it doesn't matter if the number if the
>> concrete memory address or not, you can't access it anyway except using
>> JNI.
> I completely agree with this view. I fear Brian's critique has
> apportioned blame to the wrong target. The problem here is not the
> exposure of raw addresses (also offsets, etc) that Aleksey's spec
> enables, it is the existence of a Java API that allows them to be used
> as raw addresses (etc). Take away that API (which is a task that is very
> much in hand) and it is hard to see why there is a problem with the
> exposure.
>
> Without such an API the values returned are a mere cipher form the point
> of view of the reporting JVM, providing no means to side effect its
> operation. Whereas, on the other hand, those same numbers -- if and when
> they are available -- may still be crunched  pairwise (or in some other
> statistically interesting aggregation) as numeric values to reveal a
> host of interesting and useful (albeit perhaps not always reproducible
> or reliable) properties of that JVM without in any way prejudicing its
> execution.
>
> You are right that this still leaves a wormhole open for abuse in JNI
> code. However, that wormhole is already present for anyone creative
> and/or stupid enough to use it so I don't see that as an argument
> against Aleksey's proposal. One should only guard so far against idiocy
> when the cost is to disable a legitimate (one might even claim pressing)
> need for sensible users to be able to measure how their code is operating.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Red Hat Distinguished Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill
>

I think that part of Brian's concern was rightly against 
addressOf(Object) since Unsafe is currently still present while its 
functionality is slowly being crippled while other APIs are replacing 
it. Suppose that in some future JDK the Unsafe.get/put methods that take 
an Object reference are taken away, but those that take long addresses 
are still kept to facilitate access to off-heap memory. This crippled 
Unsafe API could be seen by a newbie as a perfect match with the 
Aleksey's addressOf(Object) API to form a means to peek and poke into 
objects. It would mostly even work.


But see the Erik Österlund's reply which is more profound.


Regards, Peter