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

[Andrew Dinn]

On 17/08/2020 16:19, Michael Kuhlmann wrote:
> 
> On 8/17/20 4:57 PM, Peter Levart 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