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 08:47:46 GMT

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
> 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