groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: Removing our use of sun.misc.Unsafe
Date Fri, 13 Oct 2017 09:11:14 GMT

Am 13.10.2017 um 10:47 schrieb Jochen Theodorou:
> Am 13.10.2017 um 09:52 schrieb Uwe Schindler:
>> FYI,
>> getting Unsafe does not print a warning, as reflection is "open" on
>> the jdk.unsupported module. This was decided in JEP 260.
> ups, yes, sorry, forgot that.

and of course while true for Unsafe, we still have this:

>            try {
>                 return UNSAFE.objectFieldOffset(String.class.getDeclaredField(fieldName));
>             } catch (NoSuchFieldException e) {
>                 // field undefined
>             }

and this getDeclaredField field will cause a warning even with addopens. 
And who knows if in JDK10/18.3 or how they want to call this, there will 
be still unsafe like in JDK9. For me it is scheduled to go.

>> Uwe
>> -----
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> eMail:
>>> -----Original Message-----
>>> From: Jochen Theodorou []
>>> Sent: Friday, October 13, 2017 8:49 AM
>>> To:
>>> Subject: Re: Removing our use of sun.misc.Unsafe
>>> On 13.10.2017 05:41, Paul King wrote:
>>>> I was going to try to progress removing Unsafe but I am a little unsure
>>>> where others might have gotten up to in previous investigations. So, I
>>>> have a bunch of questions in case others have some answers/ideas.
>>>> Does anyone know whether variable handles might work for us? Inside
>>> some
>>>> kind of jdk9 plugin I guess?
>>> in my opinion no. Not to operate on private fields of java.lang.String
>>> without a Lookup object that has the rights to operate on the fields,
>>> which would come from java.lang.String itself. As such a thing is not
>>> provided, there will be no possibility.
>>>> Has anyone looked into how we might package up our unsafe usage in such
>>>> a way that it could be used in pre-jdk9 environments where var handles
>>>> aren't available but not result in errors/warnings in jdk9?
>>> to avoid the warning we would have to not even try to get Unsafe. I
>>> would extend our vmplugin system for this then.
>>>> What tests were being run to ensure that performance wasn't lost?
>>> None... but what are you going to do if there is a performance loss? If
>>> there is no alternative, then there is no alternative. And then there is
>>> nothing to compare against, thus there is no performance loss, as a loss
>>> requires a base, which then does not exist anymore.
>>>> Can we remove the OFFSET enum in FastStringUtils described as
>>>> applicable
>>>> for JDK4/5?
>>> Well... officially we do not JDK4... I think our minimum for 2.4 was
>>> JDK6? In that case... yeah I guess so ;)
>>> bye Jochen

View raw message