sun.misc.Unsafe usage, etc.

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

sun.misc.Unsafe usage, etc.

Scott Stark
In case you didn't see the msg I sent to the core, I started up a discussion thread "What are our middleware sun.misc.Unsafe uses?" (https://developer.jboss.org/message/936359) to identify and track the replacement for all of the Unsafe uses. As the start of the discussion indicates, this came up because there was fear that Java 9 would prevent access to the various internal packages. There may be a Java EC working group on the problem, but it would be best for use to work on getting public replacements in place by working with our OpenJDK team lead by Andrew Haley.

I have some comments I collected from other threads on the topic from Andrew, Jason and David as well as the Java EC summary of the Unsafe situation as background at the start of the thread.

Please add to or correct anything that shows up on the thread as I work through the projects to identify what we are using and why.

The first think I checked out was the use of the Unsafe usage by jboss-modules in the current wildfly trunk build. That turns out to be synchronization primitives that have already been dropped in the 1.5.0 snapshot due to JDK7+ being required. Hopefully most of these are similar workarounds for older Java platforms, but where they are not, I want to make sure we are either tracking or creating an OpenJDK JEP (http://openjdk.java.net/jeps/1) for the public api replacement.


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: sun.misc.Unsafe usage, etc.

Scott Stark
One major usage jumping out is that of JSR166 java.util.concurrency class backports. These will be a non-issue once Java 8+ is a requirement.

----- Original Message -----
From: "Scott Stark" <[hidden email]>
To: [hidden email]
Sent: Tuesday, July 21, 2015 10:58:08 AM
Subject: [wildfly-dev] sun.misc.Unsafe usage, etc.

In case you didn't see the msg I sent to the core, I started up a discussion thread "What are our middleware sun.misc.Unsafe uses?" (https://developer.jboss.org/message/936359) to identify and track the replacement for all of the Unsafe uses. As the start of the discussion indicates, this came up because there was fear that Java 9 would prevent access to the various internal packages. There may be a Java EC working group on the problem, but it would be best for use to work on getting public replacements in place by working with our OpenJDK team lead by Andrew Haley.

I have some comments I collected from other threads on the topic from Andrew, Jason and David as well as the Java EC summary of the Unsafe situation as background at the start of the thread.

Please add to or correct anything that shows up on the thread as I work through the projects to identify what we are using and why.

The first think I checked out was the use of the Unsafe usage by jboss-modules in the current wildfly trunk build. That turns out to be synchronization primitives that have already been dropped in the 1.5.0 snapshot due to JDK7+ being required. Hopefully most of these are similar workarounds for older Java platforms, but where they are not, I want to make sure we are either tracking or creating an OpenJDK JEP (http://openjdk.java.net/jeps/1) for the public api replacement.


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: sun.misc.Unsafe usage, etc.

jtgreene
Administrator
Right, it effectively locks us out of creating either derivatives or backports of java.util.concurrent, which is an active project that moves along independently of the JDK, leaving it continually behind. So its still a problem after JDK8. There are ways around it, in that you can port them in many cases to using AtomicXXX or AtomicXXXReferenceFieldUpdater. However, these are currently slower.
 

> On Jul 21, 2015, at 3:44 PM, Scott Stark <[hidden email]> wrote:
>
> One major usage jumping out is that of JSR166 java.util.concurrency class backports. These will be a non-issue once Java 8+ is a requirement.
>
> ----- Original Message -----
> From: "Scott Stark" <[hidden email]>
> To: [hidden email]
> Sent: Tuesday, July 21, 2015 10:58:08 AM
> Subject: [wildfly-dev] sun.misc.Unsafe usage, etc.
>
> In case you didn't see the msg I sent to the core, I started up a discussion thread "What are our middleware sun.misc.Unsafe uses?" (https://developer.jboss.org/message/936359) to identify and track the replacement for all of the Unsafe uses. As the start of the discussion indicates, this came up because there was fear that Java 9 would prevent access to the various internal packages. There may be a Java EC working group on the problem, but it would be best for use to work on getting public replacements in place by working with our OpenJDK team lead by Andrew Haley.
>
> I have some comments I collected from other threads on the topic from Andrew, Jason and David as well as the Java EC summary of the Unsafe situation as background at the start of the thread.
>
> Please add to or correct anything that shows up on the thread as I work through the projects to identify what we are using and why.
>
> The first think I checked out was the use of the Unsafe usage by jboss-modules in the current wildfly trunk build. That turns out to be synchronization primitives that have already been dropped in the 1.5.0 snapshot due to JDK7+ being required. Hopefully most of these are similar workarounds for older Java platforms, but where they are not, I want to make sure we are either tracking or creating an OpenJDK JEP (http://openjdk.java.net/jeps/1) for the public api replacement.
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: sun.misc.Unsafe usage, etc.

Scott Stark
Your talking about why we need to still have a push for the features of Unsafe to be exposed in the jdk to allow for innovation? Agreed about that.

----- Original Message -----
From: "Jason Greene" <[hidden email]>
To: "Scott Stark" <[hidden email]>
Cc: [hidden email]
Sent: Tuesday, July 21, 2015 2:01:45 PM
Subject: Re: [wildfly-dev] sun.misc.Unsafe usage, etc.

Right, it effectively locks us out of creating either derivatives or backports of java.util.concurrent, which is an active project that moves along independently of the JDK, leaving it continually behind. So its still a problem after JDK8. There are ways around it, in that you can port them in many cases to using AtomicXXX or AtomicXXXReferenceFieldUpdater. However, these are currently slower.
 

> On Jul 21, 2015, at 3:44 PM, Scott Stark <[hidden email]> wrote:
>
> One major usage jumping out is that of JSR166 java.util.concurrency class backports. These will be a non-issue once Java 8+ is a requirement.
>
> ----- Original Message -----
> From: "Scott Stark" <[hidden email]>
> To: [hidden email]
> Sent: Tuesday, July 21, 2015 10:58:08 AM
> Subject: [wildfly-dev] sun.misc.Unsafe usage, etc.
>
> In case you didn't see the msg I sent to the core, I started up a discussion thread "What are our middleware sun.misc.Unsafe uses?" (https://developer.jboss.org/message/936359) to identify and track the replacement for all of the Unsafe uses. As the start of the discussion indicates, this came up because there was fear that Java 9 would prevent access to the various internal packages. There may be a Java EC working group on the problem, but it would be best for use to work on getting public replacements in place by working with our OpenJDK team lead by Andrew Haley.
>
> I have some comments I collected from other threads on the topic from Andrew, Jason and David as well as the Java EC summary of the Unsafe situation as background at the start of the thread.
>
> Please add to or correct anything that shows up on the thread as I work through the projects to identify what we are using and why.
>
> The first think I checked out was the use of the Unsafe usage by jboss-modules in the current wildfly trunk build. That turns out to be synchronization primitives that have already been dropped in the 1.5.0 snapshot due to JDK7+ being required. Hopefully most of these are similar workarounds for older Java platforms, but where they are not, I want to make sure we are either tracking or creating an OpenJDK JEP (http://openjdk.java.net/jeps/1) for the public api replacement.
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: sun.misc.Unsafe usage, etc.

jtgreene
Administrator
Yes thats exactly what I mean. These low level hooks have been a boon to innovation, and it would be a shame to stifle that. I am sympathetic to their desire to not provide compatibility guarantees around these methods, and to hide them by default. So if they go the route of a flag or a special module import/permission I think thats reasonable and accomplishes that goal. I am more worried about them being outright prevented and unreachable.

> On Jul 22, 2015, at 11:27 AM, Scott Stark <[hidden email]> wrote:
>
> Your talking about why we need to still have a push for the features of Unsafe to be exposed in the jdk to allow for innovation? Agreed about that.
>
> ----- Original Message -----
> From: "Jason Greene" <[hidden email]>
> To: "Scott Stark" <[hidden email]>
> Cc: [hidden email]
> Sent: Tuesday, July 21, 2015 2:01:45 PM
> Subject: Re: [wildfly-dev] sun.misc.Unsafe usage, etc.
>
> Right, it effectively locks us out of creating either derivatives or backports of java.util.concurrent, which is an active project that moves along independently of the JDK, leaving it continually behind. So its still a problem after JDK8. There are ways around it, in that you can port them in many cases to using AtomicXXX or AtomicXXXReferenceFieldUpdater. However, these are currently slower.
>
>> On Jul 21, 2015, at 3:44 PM, Scott Stark <[hidden email]> wrote:
>>
>> One major usage jumping out is that of JSR166 java.util.concurrency class backports. These will be a non-issue once Java 8+ is a requirement.
>>
>> ----- Original Message -----
>> From: "Scott Stark" <[hidden email]>
>> To: [hidden email]
>> Sent: Tuesday, July 21, 2015 10:58:08 AM
>> Subject: [wildfly-dev] sun.misc.Unsafe usage, etc.
>>
>> In case you didn't see the msg I sent to the core, I started up a discussion thread "What are our middleware sun.misc.Unsafe uses?" (https://developer.jboss.org/message/936359) to identify and track the replacement for all of the Unsafe uses. As the start of the discussion indicates, this came up because there was fear that Java 9 would prevent access to the various internal packages. There may be a Java EC working group on the problem, but it would be best for use to work on getting public replacements in place by working with our OpenJDK team lead by Andrew Haley.
>>
>> I have some comments I collected from other threads on the topic from Andrew, Jason and David as well as the Java EC summary of the Unsafe situation as background at the start of the thread.
>>
>> Please add to or correct anything that shows up on the thread as I work through the projects to identify what we are using and why.
>>
>> The first think I checked out was the use of the Unsafe usage by jboss-modules in the current wildfly trunk build. That turns out to be synchronization primitives that have already been dropped in the 1.5.0 snapshot due to JDK7+ being required. Hopefully most of these are similar workarounds for older Java platforms, but where they are not, I want to make sure we are either tracking or creating an OpenJDK JEP (http://openjdk.java.net/jeps/1) for the public api replacement.
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: sun.misc.Unsafe usage, etc.

Anil Saldanha
Totally agree with both of you. 
The reason a discussion on Unsafe is happening after all these years implies that a lot of projects have used it over the years and there is no way to completely shield it. Definitely some mechanism have to be put in place in the JDK to provide hooks to developers who need it.   
Remember, the setAccessible(true) for private fields? The existence of this mechanism helps when you need it.

On Wed, Jul 22, 2015 at 12:15 PM, Jason Greene <[hidden email]> wrote:
Yes thats exactly what I mean. These low level hooks have been a boon to innovation, and it would be a shame to stifle that. I am sympathetic to their desire to not provide compatibility guarantees around these methods, and to hide them by default. So if they go the route of a flag or a special module import/permission I think thats reasonable and accomplishes that goal. I am more worried about them being outright prevented and unreachable.

> On Jul 22, 2015, at 11:27 AM, Scott Stark <[hidden email]> wrote:
>
> Your talking about why we need to still have a push for the features of Unsafe to be exposed in the jdk to allow for innovation? Agreed about that.
>
> ----- Original Message -----
> From: "Jason Greene" <[hidden email]>
> To: "Scott Stark" <[hidden email]>
> Cc: [hidden email]
> Sent: Tuesday, July 21, 2015 2:01:45 PM
> Subject: Re: [wildfly-dev] sun.misc.Unsafe usage, etc.
>
> Right, it effectively locks us out of creating either derivatives or backports of java.util.concurrent, which is an active project that moves along independently of the JDK, leaving it continually behind. So its still a problem after JDK8. There are ways around it, in that you can port them in many cases to using AtomicXXX or AtomicXXXReferenceFieldUpdater. However, these are currently slower.
>
>> On Jul 21, 2015, at 3:44 PM, Scott Stark <[hidden email]> wrote:
>>
>> One major usage jumping out is that of JSR166 java.util.concurrency class backports. These will be a non-issue once Java 8+ is a requirement.
>>
>> ----- Original Message -----
>> From: "Scott Stark" <[hidden email]>
>> To: [hidden email]
>> Sent: Tuesday, July 21, 2015 10:58:08 AM
>> Subject: [wildfly-dev] sun.misc.Unsafe usage, etc.
>>
>> In case you didn't see the msg I sent to the core, I started up a discussion thread "What are our middleware sun.misc.Unsafe uses?" (https://developer.jboss.org/message/936359) to identify and track the replacement for all of the Unsafe uses. As the start of the discussion indicates, this came up because there was fear that Java 9 would prevent access to the various internal packages. There may be a Java EC working group on the problem, but it would be best for use to work on getting public replacements in place by working with our OpenJDK team lead by Andrew Haley.
>>
>> I have some comments I collected from other threads on the topic from Andrew, Jason and David as well as the Java EC summary of the Unsafe situation as background at the start of the thread.
>>
>> Please add to or correct anything that shows up on the thread as I work through the projects to identify what we are using and why.
>>
>> The first think I checked out was the use of the Unsafe usage by jboss-modules in the current wildfly trunk build. That turns out to be synchronization primitives that have already been dropped in the 1.5.0 snapshot due to JDK7+ being required. Hopefully most of these are similar workarounds for older Java platforms, but where they are not, I want to make sure we are either tracking or creating an OpenJDK JEP (http://openjdk.java.net/jeps/1) for the public api replacement.
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: sun.misc.Unsafe usage, etc.

Andrig Miller
In reply to this post by Scott Stark
My understanding was JDK9 was going to have a public API that replaces Unsafe.  It has been discussed on the concurrency interest list a number of times.  Is that not the case anymore?

Andy

----- Original Message -----

> From: "Scott Stark" <[hidden email]>
> To: [hidden email]
> Sent: Tuesday, July 21, 2015 11:58:08 AM
> Subject: [wildfly-dev] sun.misc.Unsafe usage, etc.
>
> In case you didn't see the msg I sent to the core, I started up a
> discussion thread "What are our middleware sun.misc.Unsafe uses?"
> (https://developer.jboss.org/message/936359) to identify and track
> the replacement for all of the Unsafe uses. As the start of the
> discussion indicates, this came up because there was fear that Java
> 9 would prevent access to the various internal packages. There may
> be a Java EC working group on the problem, but it would be best for
> use to work on getting public replacements in place by working with
> our OpenJDK team lead by Andrew Haley.
>
> I have some comments I collected from other threads on the topic from
> Andrew, Jason and David as well as the Java EC summary of the Unsafe
> situation as background at the start of the thread.
>
> Please add to or correct anything that shows up on the thread as I
> work through the projects to identify what we are using and why.
>
> The first think I checked out was the use of the Unsafe usage by
> jboss-modules in the current wildfly trunk build. That turns out to
> be synchronization primitives that have already been dropped in the
> 1.5.0 snapshot due to JDK7+ being required. Hopefully most of these
> are similar workarounds for older Java platforms, but where they are
> not, I want to make sure we are either tracking or creating an
> OpenJDK JEP (http://openjdk.java.net/jeps/1) for the public api
> replacement.
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: sun.misc.Unsafe usage, etc.

Scott Stark
It came up at the Java EC level that there was not going to be a public replacement. Hence, there was a concern raised and the OpenJDK teams have most recently replied with a new JEP that is addressing this issue.
http://openjdk.java.net/jeps/260 (JEP 260: Encapsulate Most Internal APIs)

Not every usage from Unsafe has a targeted public replacement, but they are asking for feedback on whether what is being targeted is sufficient.

----- Original Message -----
From: "Andrig T. Miller" <[hidden email]>
To: "Scott Stark" <[hidden email]>
Cc: [hidden email]
Sent: Thursday, August 6, 2015 12:05:44 PM
Subject: Re: [wildfly-dev] sun.misc.Unsafe usage, etc.

My understanding was JDK9 was going to have a public API that replaces Unsafe.  It has been discussed on the concurrency interest list a number of times.  Is that not the case anymore?

Andy

----- Original Message -----

> From: "Scott Stark" <[hidden email]>
> To: [hidden email]
> Sent: Tuesday, July 21, 2015 11:58:08 AM
> Subject: [wildfly-dev] sun.misc.Unsafe usage, etc.
>
> In case you didn't see the msg I sent to the core, I started up a
> discussion thread "What are our middleware sun.misc.Unsafe uses?"
> (https://developer.jboss.org/message/936359) to identify and track
> the replacement for all of the Unsafe uses. As the start of the
> discussion indicates, this came up because there was fear that Java
> 9 would prevent access to the various internal packages. There may
> be a Java EC working group on the problem, but it would be best for
> use to work on getting public replacements in place by working with
> our OpenJDK team lead by Andrew Haley.
>
> I have some comments I collected from other threads on the topic from
> Andrew, Jason and David as well as the Java EC summary of the Unsafe
> situation as background at the start of the thread.
>
> Please add to or correct anything that shows up on the thread as I
> work through the projects to identify what we are using and why.
>
> The first think I checked out was the use of the Unsafe usage by
> jboss-modules in the current wildfly trunk build. That turns out to
> be synchronization primitives that have already been dropped in the
> 1.5.0 snapshot due to JDK7+ being required. Hopefully most of these
> are similar workarounds for older Java platforms, but where they are
> not, I want to make sure we are either tracking or creating an
> OpenJDK JEP (http://openjdk.java.net/jeps/1) for the public api
> replacement.
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: sun.misc.Unsafe usage, etc.

Heiko W.Rupp
On 6 Aug 2015, at 21:41, Scott Stark wrote:

> It came up at the Java EC level that there was not going to be a
> public replacement. Hence, there was a concern raised and the OpenJDK
> teams have most recently replied with a new JEP that is addressing
> this issue.
> http://openjdk.java.net/jeps/260 (JEP 260: Encapsulate Most Internal
> APIs)

Mark Reinhold wrote this email 2 days ago, that (im my understanding)
says that Unsafe will stay:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-August/004433.html

This then refers to JEP 260, which says that Unsafe should stay as is.
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev