Hi Claes,
excellent idea, I'll point them to this thread.
Sanne
----- Original Message -----
> Hi!
>
> How about:
>
> int findIntegerCacheHighPropValue() {
> int test = 128; // minimum mandated by JLS is 127
> while (Integer.valueOf(test) == Integer.valueOf(test)) {
> test++;
> }
> return test - 1;
> }
>
> Since this runs through and hits the cache until the last step, it
> should be about as fast. Should also be more robust since it'll give the
> true value for any existing JLS-compliant VM no matter what mechanism
> they use to set up their integer cache.
>
> Thanks!
>
> /Claes
>
> On 2016-01-20 17:13, Sanne Grinovero wrote:
> > Hello,
> > thanks for clarifying about some APIs being considered "critical".
> >
> > No, I'm not seeing lots of usage: actually just one instance so far so it
> > should be possible to patch already with minimal impact.
> >
> > I'm understanding that this API will be hidden. Will there be an
> > alternative?
> > In this case it's just being used to invoke:
> >
> > sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high")
> >
> > I'm not entirely familiar with this code, but it seems the purpose is to
> > estimate memory usage at runtime for objects,
> > so it's attempting to read this value to disregard the Integer instances
> > which are being reused from the pool.
> >
> > Wondering if you could suggest an alternative, or should we plan for not
> > having this level of detail anymore?
> >
> > Thanks,
> > Sanne
> >
> >
> > ----- Original Message -----
> >>
> >> On 20/01/2016 15:18, Sanne Grinovero wrote:
> >>> Hello all,
> >>> while testing latest Java 9 build
> >>> 9-ea+101-2016-01-13-182959.javare.4276.nc
> >>> with some popular OSS libraries, I noticed that sun.misc.VM is gone and
> >>> this will cause some issues.
> >>>
> >>> This is causing compilation failures of type "cannot find symbol".
> >>> Similarly the same projects are using sun.misc.Unsafe, but in that case
> >>> we're getting a warning "sun.misc.Unsafe is internal proprietary API and
> >>> may be removed in a future release".
> >>>
> >>> Is it intentional that sun.misc.VM takes a more aggressive migration path
> >>> than the nice warnings we're getting for Unsafe?
> >>>
> >> sun.misc.VM is not one of the "critical internal APIs" that identified
> >> in JEP 260 [1]. There is ongoing work (mostly by Chris Hegarty) to move
> >> the non-critical APIs out of sun.misc and sun.reflect so that all that
> >> remains is the critical internal APIs.
> >>
> >> Are you seeing a lot of usage of sun.misc.VM? If so then best to bring
> >> usage data to jigsaw-dev to lobby for it to be considered as a critical
> >> internal API.
> >>
> >> -Alan.
> >>
> >> [1] http://openjdk.java.net/jeps/260
> >>
>
>
