Removing our use of sun.misc.Unsafe

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Removing our use of sun.misc.Unsafe

paulk_asert

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?

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?

What tests were being run to ensure that performance wasn't lost?

Can we remove the OFFSET enum in FastStringUtils described as applicable for JDK4/5?


Cheers, Paul.

Reply | Threaded
Open this post in threaded view
|

Re: Removing our use of sun.misc.Unsafe

Jochen Theodorou
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
Reply | Threaded
Open this post in threaded view
|

RE: Removing our use of sun.misc.Unsafe

Uwe Schindler-2
FYI,

getting Unsafe does not print a warning, as reflection is "open" on the jdk.unsupported module. This was decided in JEP 260.

Uwe

-----
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: [hidden email]

> -----Original Message-----
> From: Jochen Theodorou [mailto:[hidden email]]
> Sent: Friday, October 13, 2017 8:49 AM
> To: [hidden email]
> 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

Reply | Threaded
Open this post in threaded view
|

Re: Removing our use of sun.misc.Unsafe

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.

> Uwe
>
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: [hidden email]
>
>> -----Original Message-----
>> From: Jochen Theodorou [mailto:[hidden email]]
>> Sent: Friday, October 13, 2017 8:49 AM
>> To: [hidden email]
>> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Removing our use of sun.misc.Unsafe

Jochen Theodorou


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
>> http://www.thetaphi.de
>> eMail: [hidden email]
>>
>>> -----Original Message-----
>>> From: Jochen Theodorou [mailto:[hidden email]]
>>> Sent: Friday, October 13, 2017 8:49 AM
>>> To: [hidden email]
>>> 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
>>
Reply | Threaded
Open this post in threaded view
|

Re: Removing our use of sun.misc.Unsafe

jwagenleitner
In reply to this post by paulk_asert
I would be in favor of removing Unsafe from the groovy-json subproject which I think is the only place where it's used. I had planned to propose this to the dev list but never got around to it. With compat strings in Java 9 I believe it will no longer be a viable optimization (at least not without quite a bit of effort) and while there may be some performance (or memory) impact for those using Java 7/8 I suspect it wont be that noticeable for most all workloads.

I not sure var handles will help much given the work that would be needed to decode the new byte array that String uses in 9. I definitely think offset can be removed since now we are Java 6 minimum, though I would propose Unsafe be removed altogether from 2.5 onwards.

On Thu, Oct 12, 2017 at 8:41 PM, Paul King <[hidden email]> 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?

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?

What tests were being run to ensure that performance wasn't lost?

Can we remove the OFFSET enum in FastStringUtils described as applicable for JDK4/5?


Cheers, Paul.


Reply | Threaded
Open this post in threaded view
|

Re: Removing our use of sun.misc.Unsafe

paulk_asert
We could use a multi-release jar to still provide a faster option for pre jdk9 users but avoiding that added complexity would also be a good thing.


On Sat, Oct 14, 2017 at 12:28 AM, John Wagenleitner <[hidden email]> wrote:
I would be in favor of removing Unsafe from the groovy-json subproject which I think is the only place where it's used. I had planned to propose this to the dev list but never got around to it. With compat strings in Java 9 I believe it will no longer be a viable optimization (at least not without quite a bit of effort) and while there may be some performance (or memory) impact for those using Java 7/8 I suspect it wont be that noticeable for most all workloads.

I not sure var handles will help much given the work that would be needed to decode the new byte array that String uses in 9. I definitely think offset can be removed since now we are Java 6 minimum, though I would propose Unsafe be removed altogether from 2.5 onwards.

On Thu, Oct 12, 2017 at 8:41 PM, Paul King <[hidden email]> 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?

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?

What tests were being run to ensure that performance wasn't lost?

Can we remove the OFFSET enum in FastStringUtils described as applicable for JDK4/5?


Cheers, Paul.



Reply | Threaded
Open this post in threaded view
|

Re: Removing our use of sun.misc.Unsafe

Remi Forax
Hi Paul,
multi-release jars are not well supported by the ecosystem yet,
eclipse and idea do not support it well, junit do not support it (all tools that does annotations scanning in fact), maven do not support it well, proguards do not support it, etc

Rémi


De: "Paul King" <[hidden email]>
À: "dev" <[hidden email]>
Envoyé: Samedi 14 Octobre 2017 02:52:30
Objet: Re: Removing our use of sun.misc.Unsafe
We could use a multi-release jar to still provide a faster option for pre jdk9 users but avoiding that added complexity would also be a good thing.

On Sat, Oct 14, 2017 at 12:28 AM, John Wagenleitner <[hidden email]> wrote:
I would be in favor of removing Unsafe from the groovy-json subproject which I think is the only place where it's used. I had planned to propose this to the dev list but never got around to it. With compat strings in Java 9 I believe it will no longer be a viable optimization (at least not without quite a bit of effort) and while there may be some performance (or memory) impact for those using Java 7/8 I suspect it wont be that noticeable for most all workloads.
I not sure var handles will help much given the work that would be needed to decode the new byte array that String uses in 9. I definitely think offset can be removed since now we are Java 6 minimum, though I would propose Unsafe be removed altogether from 2.5 onwards.

On Thu, Oct 12, 2017 at 8:41 PM, Paul King <[hidden email]> 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?

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?

What tests were being run to ensure that performance wasn't lost?

Can we remove the OFFSET enum in FastStringUtils described as applicable for JDK4/5?


Cheers, Paul.