groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <...@thetaphi.de>
Subject RE: Removing our use of sun.misc.Unsafe
Date Fri, 13 Oct 2017 07:52:42 GMT
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: uwe@thetaphi.de

> -----Original Message-----
> From: Jochen Theodorou [mailto:blackdrag@gmx.org]
> Sent: Friday, October 13, 2017 8:49 AM
> To: dev@groovy.apache.org
> 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


Mime
View raw message