On 07/27/2015 03:56 PM, Simon Nash wrote:
Phil Race wrote:
> The jdeps tool bundled with current JDK 8 updates should help
> you produced a definitive list - of your current uses.
>
Thanks for your quick reply. I will run this tool to check that my list
is complete and correct.
> A web page about jpdeps and current recommended replacements for
> some internal APIs can be viewed at
>
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
>
I will look at this to see if it helps with my issues.
> jigsaw-...@openjdk.java.net is the list for the project under which the
> changes are being made, and folks there are probably aware of any
> likelihood of some of the non-client ones getting a replacement.
>
I will raise this topic on that list.
> I don't know how a classloader can prevent a dll being unloaded unless
> you have tied a call to dlclose into the classloader gc process
yourself.
> Can you explain this more ?
>
See the section "Library and Version Management" in this document:
http://docs.oracle.com/javase/1.5.0/docs/guide/jni/spec/invocation.html
Specifically:
So these dlls contain JNI code .. and need to be found by the VM.
I suspect that for client code there are few if any tests that really
exercise this.
(1) The same JNI native library cannot be loaded into more than one class
loader. Doing so causes UnsatisfiedLinkError to be thrown.
(2) In addition, native libraries can be unloaded when their
corresponding
class loaders are garbage collected.
Because of (1), a new version of the native library can't be loaded until
the old version is unloaded. Because of (2), the old version can't be
unloaded until the original classloader has been garbage collected. I
have
not tied anything into the classloader GC process myself.
> I do not see any likelihood of the client ones you list being made
public.
> Some of them are very deep in the details of the implementation.
>
Will there be any way to access these if they are not public (for
example,
by reflection)? If this is possible, I should be able to adapt my
current
workaround code to run on JDK 9.
My understanding is that you would have to use special command line options
but this is all a work in progress.
> A more viable line to file bugs describing where the leakage is -
and/or
> point us to any bugs that are already filed on these.
>
Some have existing bugs filed (6575402, 8029147) and many others don't.
To file bugs on everything I have found would be a huge effort because I
discovered these some time ago and my memory of the exact details has
faded by now. The only way to be sure I have the details correct
would be
to remove my workarounds and analyse the leakages again using JVisualVM.
This would require several weeks of work.
At present, a developer can work around a bug like this until a fix is
available in a new version of the JDK. If access to private classes is
removed completely, such workarounds will no longer be possible.
I believe it would be worthwhile to try to identify as many of these as
possible.
-phil.
Simon
Phil Race wrote:
The jdeps tool bundled with current JDK 8 updates should help
you produced a definitive list - of your current uses.
A web page about jpdeps and current recommended replacements for
some internal APIs can be viewed at
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
jigsaw-...@openjdk.java.net is the list for the project under which the
changes are being made, and folks there are probably aware of any
likelihood of some of the non-client ones getting a replacement.
I don't know how a classloader can prevent a dll being unloaded unless
you have tied a call to dlclose into the classloader gc process
yourself.
Can you explain this more ?
I do not see any likelihood of the client ones you list being made
public.
Some of them are very deep in the details of the implementation.
A more viable line to file bugs describing where the leakage is - and/or
point us to any bugs that are already filed on these.
-phil.
On 07/27/2015 01:15 PM, Simon Nash wrote:
I have recently discovered that applications will no longer be able
to access internal packages (sun.* and com.sun.*) in JDK 9. This is a
major problem for my application as it requires access to some internal
packages in order to work correctly.
In most cases, my need to access these internal classes is to work
around
"object leakage" in Swing that results in objects being created and
held
by Swing with no means of freeing these objects by any application
action.
In some cases, these "leaked" objects reference my application
classloader
via their protection domain, and this means that my application
classloader
cannot be garbage collected even if I remove all references to it from
within my application. My application uses native DLLs that
sometimes need
to be replaced by new versions and these DLLs cannot be unloaded and
reloaded unless the application classloader that loaded these DLLs
has been
garbage collected.
The only workaround I have found for this problem is to use internal
APIs
together with reflection to locate the fields that are holding these
internal "leaked" objects and set these fields to null.
It is hard to provide a definitive list of all the internal packages
that
I need because the list tends to grow each time I use additional Swing
functionality in my application. At present, the packages are:
sun.awt.AppContext
sun.awt.image.MultiResolutionToolkitImage$ObserverCache
sun.awt.X11.XBaseWindow
sun.lwawt.LWComponentPeer
sun.java2d.pipe.BufferedContext
sun.java2d.pipe.RenderQueue
sun.java2d.pipe.hw.BufferedContextProvider
In addition, my application is using some APIs from internal
packages to
access functionality that isn't available via official APIs. These
aren't
Swing or AWT packages, so this mailing list probably isn't the right
place
to go into details. Any suggestions for the correct list(s) to
raise this
issue would be appreciated. The packages are:
com.sun.management.HotSpotDiagnosticMXBean
sun.misc.Signal
sun.misc.SignalHandler
sun.nio.ch.ChannelInputStream
Best regards,
Simon Nash
