Re: Early Access builds of JDK 9 b118 & JDK 9 with Project Jigsaw, b118 (#4987) are available on java.net

[Rory O'Donnell]

Thanks Mark, I'll update the bug.

Rgds,Rory


On 03/06/2016 12:32, Mark Thomas wrote:

On 01/06/2016 15:45, Rory O'Donnell wrote:

Hi Mark,

JDK-8158237  : JVMTI
hides critical debug information for memory leak tracing

Is closed as a duplicate of JDK-8033735
 : make
Throwable.backtrace visible to Class.getDeclaredField again.

And this bug was fixed in JDK9 build 116.

Can you confirm ?

Sorry to be the bearer of bad news, but this bug is NOT fixed. I've just
tested this with b120 and b121 and in both cases the memory leak is
traceable if I use an HPROF format heap dump but not if I use the
YourKit format heap dump obtained via JVMTI.

Kind regards,

Mark



Rgds,Rory


On 20/05/2016 15:17, Rory O'Donnell wrote:

Thanks Mark!



On 20 May 2016, at 14:51, Mark Thomas  wrote:


On 19/05/2016 11:05, Rory O'Donnell wrote:
Hi Mark,

I just had some time to review your email in detail, can you log bugs
for items
3,4 and 5 and send me the JI numbers ?

See in-line.

Many thanks,

Mark


3. Memory leak in sun.rmi.transport.GC
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040893.html


JI-9038057


4. API to trace RMI Target memory leaks without resorting to
reflection
(I accept that this is unlikely but If you don't ask...)
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040855.html


JI-9038059


5. Rare memory leak in sun.security.pkcs11.SunPKCS11 poller thread
http://mail.openjdk.java.net/pipermail/security-dev/2016-May/013841.html


Looks like someone created a bug for this:
https://bugs.openjdk.java.net/browse/JDK-8156841




--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Early Access builds of JDK 9 b118 & JDK 9 with Project Jigsaw, b118 (#4987) are available on java.net

[Mark Thomas]

On 01/06/2016 15:45, Rory O'Donnell wrote:
> Hi Mark,
> 
> JDK-8158237  : JVMTI
> hides critical debug information for memory leak tracing
> 
> Is closed as a duplicate of JDK-8033735
>  : make
> Throwable.backtrace visible to Class.getDeclaredField again.
> 
> And this bug was fixed in JDK9 build 116.
> 
> Can you confirm ?

Sorry to be the bearer of bad news, but this bug is NOT fixed. I've just
tested this with b120 and b121 and in both cases the memory leak is
traceable if I use an HPROF format heap dump but not if I use the
YourKit format heap dump obtained via JVMTI.

Kind regards,

Mark


> 
> Rgds,Rory
> 
> 
> On 20/05/2016 15:17, Rory O'Donnell wrote:
>> Thanks Mark!
>>
>>
>>> On 20 May 2016, at 14:51, Mark Thomas  wrote:
>>>
 On 19/05/2016 11:05, Rory O'Donnell wrote:
 Hi Mark,

 I just had some time to review your email in detail, can you log bugs
 for items
 3,4 and 5 and send me the JI numbers ?
>>> See in-line.
>>>
>>> Many thanks,
>>>
>>> Mark
>>>
> 3. Memory leak in sun.rmi.transport.GC
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040893.html
>
>>> JI-9038057
>>>
> 4. API to trace RMI Target memory leaks without resorting to
> reflection
> (I accept that this is unlikely but If you don't ask...)
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040855.html
>
>>> JI-9038059
>>>
> 5. Rare memory leak in sun.security.pkcs11.SunPKCS11 poller thread
> http://mail.openjdk.java.net/pipermail/security-dev/2016-May/013841.html
>
>>> Looks like someone created a bug for this:
>>> https://bugs.openjdk.java.net/browse/JDK-8156841
>>>
>>>
> 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Early Access builds of JDK 9 b118 & JDK 9 with Project Jigsaw, b118 (#4987) are available on java.net

[Rory O'Donnell]

Hi Mark,

JDK-8158237  : JVMTI 
hides critical debug information for memory leak tracing


Is closed as a duplicate of JDK-8033735 
 : make 
Throwable.backtrace visible to Class.getDeclaredField again.


And this bug was fixed in JDK9 build 116.

Can you confirm ?

Rgds,Rory


On 20/05/2016 15:17, Rory O'Donnell wrote:

Thanks Mark!



On 20 May 2016, at 14:51, Mark Thomas  wrote:


On 19/05/2016 11:05, Rory O'Donnell wrote:
Hi Mark,

I just had some time to review your email in detail, can you log bugs
for items
3,4 and 5 and send me the JI numbers ?

See in-line.

Many thanks,

Mark


3. Memory leak in sun.rmi.transport.GC
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040893.html

JI-9038057


4. API to trace RMI Target memory leaks without resorting to reflection
(I accept that this is unlikely but If you don't ask...)
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040855.html

JI-9038059


5. Rare memory leak in sun.security.pkcs11.SunPKCS11 poller thread
http://mail.openjdk.java.net/pipermail/security-dev/2016-May/013841.html

Looks like someone created a bug for this:
https://bugs.openjdk.java.net/browse/JDK-8156841




--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

Re: Early Access builds of JDK 9 b118 & JDK 9 with Project Jigsaw, b118 (#4987) are available on java.net

[Rory O'Donnell]

Thanks Mark!


> On 20 May 2016, at 14:51, Mark Thomas  wrote:
> 
>> On 19/05/2016 11:05, Rory O'Donnell wrote:
>> Hi Mark,
>> 
>> I just had some time to review your email in detail, can you log bugs
>> for items
>> 3,4 and 5 and send me the JI numbers ?
> 
> See in-line.
> 
> Many thanks,
> 
> Mark
> 
>>> 3. Memory leak in sun.rmi.transport.GC
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040893.html
> 
> JI-9038057
> 
>>> 4. API to trace RMI Target memory leaks without resorting to reflection
>>> (I accept that this is unlikely but If you don't ask...)
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040855.html
> 
> JI-9038059
> 
>>> 5. Rare memory leak in sun.security.pkcs11.SunPKCS11 poller thread
>>> http://mail.openjdk.java.net/pipermail/security-dev/2016-May/013841.html
> 
> Looks like someone created a bug for this:
> https://bugs.openjdk.java.net/browse/JDK-8156841
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Early Access builds of JDK 9 b118 & JDK 9 with Project Jigsaw, b118 (#4987) are available on java.net

[Mark Thomas]

On 19/05/2016 11:05, Rory O'Donnell wrote:
> Hi Mark,
> 
> I just had some time to review your email in detail, can you log bugs
> for items
> 3,4 and 5 and send me the JI numbers ?

See in-line.

Many thanks,

Mark

>> 3. Memory leak in sun.rmi.transport.GC
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040893.html

JI-9038057

>> 4. API to trace RMI Target memory leaks without resorting to reflection
>> (I accept that this is unlikely but If you don't ask...)
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040855.html

JI-9038059

>> 5. Rare memory leak in sun.security.pkcs11.SunPKCS11 poller thread
>> http://mail.openjdk.java.net/pipermail/security-dev/2016-May/013841.html

Looks like someone created a bug for this:
https://bugs.openjdk.java.net/browse/JDK-8156841



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Early Access builds of JDK 9 b118 & JDK 9 with Project Jigsaw, b118 (#4987) are available on java.net

[Rory O'Donnell]

Hi Mark,

I just had some time to review your email in detail, can you log bugs 
for items

3,4 and 5 and send me the JI numbers ?

Rgds,Rory


On 18/05/2016 12:33, Mark Thomas wrote:

Rory,

Thanks for letting us know that a new build is available. We continue to
test Tomcat with Java 9 and are tracking multiple issues. The majority
of these have emerged as a result of a review of Tomcat's memory leak
prevention and detection code.

We would appreciate any help you can provide in nudging the following
issues towards resolution. Some of these are very new so it is not
surprising that not much has happened so far.

1. JVMTI bug that prevents tools like YourKit and Eclipse MAT
identifying the root causes of memory leaks caused by initialization of
static Exception fields.
Review ID: JI-9037905

2. Memory leak in com.sun.jndi.ldap.pool.PoolCleaner
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040988.html
https://bugs.openjdk.java.net/browse/JDK-8156824

3. Memory leak in sun.rmi.transport.GC
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040893.html

4. API to trace RMI Target memory leaks without resorting to reflection
(I accept that this is unlikely but If you don't ask...)
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040855.html

5. Rare memory leak in sun.security.pkcs11.SunPKCS11 poller thread
http://mail.openjdk.java.net/pipermail/security-dev/2016-May/013841.html

We have also noticed that JSP compilation is broken. Our current
understanding is that we should be able to fix this with an update to
the Eclipse JDT compiler. We'll let you know if that changes.

Finally, there are still some memory leak issues we haven't reviewed. As
that progresses, we may have a few more issues to add to the memory leak
issues listed above.

Kind regards,

Mark


On 18/05/2016 09:31, Rory O'Donnell wrote:

Hi Mark,

Early Access b118  for JDK 9 is
available on java.net, summary of  changes are listed here
.

Early Access b118  (#4913) for JDK 9 with
Project Jigsaw is available on java.net.

JDK 9 Build 118 includes a refresh of the module system.

There are several changes in this update, JDK 9 b118 has the updated
policy for root modules described
in JEP 261 [1]. This means that java.corba and the 6 EE modules aren't
resolved by default and so it will
look "as if" the types in these modules have been removed. More info on
the JDK 9 dev mailing list [2].

A change that went into JDK 9 b102 is worth mentioning:
JDK9: Remove stopThread RuntimePermission  from the default java.policy
In previous releases, untrusted
code had the "stopThread" RuntimePermission granted by default. This
permission allows untrusted code
to call Thread.stop(), initiating an asynchronous ThreadDeath Error, on
threads in the same thread group.
Having a ThreadDeath Error thrown asynchronously is not something that
trusted code should be expected
to handle gracefully. The permission is no longer granted by default.

Rgds,Rory


[1] http://openjdk.java.net/jeps/261
[2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-May/004309.html



--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

Re: Early Access builds of JDK 9 b118 & JDK 9 with Project Jigsaw, b118 (#4987) are available on java.net

[Mark Thomas]

On 18/05/2016 12:47, Rory O'Donnell wrote:
> Thanks Mark, I'll see what I can do.

Thanks. This might help:

https://github.com/markt-asf/memory-leaks

It contains simple demonstrations of each of the leaks. Some of the
demonstrations are a little contrived but the leaks demonstrated were
all observed in production by one of more Tomcat users.

Comments at the start of each class indicate if the leak has been fixed
and, if so, in what version(s).

Thanks again,

Mark

> 
> Rgds, Rory
> 
> 
> On 18/05/2016 12:33, Mark Thomas wrote:
>> Rory,
>>
>> Thanks for letting us know that a new build is available. We continue to
>> test Tomcat with Java 9 and are tracking multiple issues. The majority
>> of these have emerged as a result of a review of Tomcat's memory leak
>> prevention and detection code.
>>
>> We would appreciate any help you can provide in nudging the following
>> issues towards resolution. Some of these are very new so it is not
>> surprising that not much has happened so far.
>>
>> 1. JVMTI bug that prevents tools like YourKit and Eclipse MAT
>> identifying the root causes of memory leaks caused by initialization of
>> static Exception fields.
>> Review ID: JI-9037905
>>
>> 2. Memory leak in com.sun.jndi.ldap.pool.PoolCleaner
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040988.html
>> https://bugs.openjdk.java.net/browse/JDK-8156824
>>
>> 3. Memory leak in sun.rmi.transport.GC
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040893.html
>>
>> 4. API to trace RMI Target memory leaks without resorting to reflection
>> (I accept that this is unlikely but If you don't ask...)
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040855.html
>>
>> 5. Rare memory leak in sun.security.pkcs11.SunPKCS11 poller thread
>> http://mail.openjdk.java.net/pipermail/security-dev/2016-May/013841.html
>>
>> We have also noticed that JSP compilation is broken. Our current
>> understanding is that we should be able to fix this with an update to
>> the Eclipse JDT compiler. We'll let you know if that changes.
>>
>> Finally, there are still some memory leak issues we haven't reviewed. As
>> that progresses, we may have a few more issues to add to the memory leak
>> issues listed above.
>>
>> Kind regards,
>>
>> Mark
>>
>>
>> On 18/05/2016 09:31, Rory O'Donnell wrote:
>>> Hi Mark,
>>>
>>> Early Access b118  for JDK 9 is
>>> available on java.net, summary of  changes are listed here
>>> .
>>>
>>> Early Access b118  (#4913) for JDK 9 with
>>> Project Jigsaw is available on java.net.
>>>
>>> JDK 9 Build 118 includes a refresh of the module system.
>>>
>>> There are several changes in this update, JDK 9 b118 has the updated
>>> policy for root modules described
>>> in JEP 261 [1]. This means that java.corba and the 6 EE modules aren't
>>> resolved by default and so it will
>>> look "as if" the types in these modules have been removed. More info on
>>> the JDK 9 dev mailing list [2].
>>>
>>> A change that went into JDK 9 b102 is worth mentioning:
>>> JDK9: Remove stopThread RuntimePermission  from the default java.policy
>>> In previous releases, untrusted
>>> code had the "stopThread" RuntimePermission granted by default. This
>>> permission allows untrusted code
>>> to call Thread.stop(), initiating an asynchronous ThreadDeath Error, on
>>> threads in the same thread group.
>>> Having a ThreadDeath Error thrown asynchronously is not something that
>>> trusted code should be expected
>>> to handle gracefully. The permission is no longer granted by default.
>>>
>>> Rgds,Rory
>>>
>>>
>>> [1] http://openjdk.java.net/jeps/261
>>> [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-May/004309.html
>>>
> 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Early Access builds of JDK 9 b118 & JDK 9 with Project Jigsaw, b118 (#4987) are available on java.net

[Rory O'Donnell]

Thanks Mark, I'll see what I can do.

Rgds, Rory


On 18/05/2016 12:33, Mark Thomas wrote:

Rory,

Thanks for letting us know that a new build is available. We continue to
test Tomcat with Java 9 and are tracking multiple issues. The majority
of these have emerged as a result of a review of Tomcat's memory leak
prevention and detection code.

We would appreciate any help you can provide in nudging the following
issues towards resolution. Some of these are very new so it is not
surprising that not much has happened so far.

1. JVMTI bug that prevents tools like YourKit and Eclipse MAT
identifying the root causes of memory leaks caused by initialization of
static Exception fields.
Review ID: JI-9037905

2. Memory leak in com.sun.jndi.ldap.pool.PoolCleaner
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040988.html
https://bugs.openjdk.java.net/browse/JDK-8156824

3. Memory leak in sun.rmi.transport.GC
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040893.html

4. API to trace RMI Target memory leaks without resorting to reflection
(I accept that this is unlikely but If you don't ask...)
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040855.html

5. Rare memory leak in sun.security.pkcs11.SunPKCS11 poller thread
http://mail.openjdk.java.net/pipermail/security-dev/2016-May/013841.html

We have also noticed that JSP compilation is broken. Our current
understanding is that we should be able to fix this with an update to
the Eclipse JDT compiler. We'll let you know if that changes.

Finally, there are still some memory leak issues we haven't reviewed. As
that progresses, we may have a few more issues to add to the memory leak
issues listed above.

Kind regards,

Mark


On 18/05/2016 09:31, Rory O'Donnell wrote:

Hi Mark,

Early Access b118  for JDK 9 is
available on java.net, summary of  changes are listed here
.

Early Access b118  (#4913) for JDK 9 with
Project Jigsaw is available on java.net.

JDK 9 Build 118 includes a refresh of the module system.

There are several changes in this update, JDK 9 b118 has the updated
policy for root modules described
in JEP 261 [1]. This means that java.corba and the 6 EE modules aren't
resolved by default and so it will
look "as if" the types in these modules have been removed. More info on
the JDK 9 dev mailing list [2].

A change that went into JDK 9 b102 is worth mentioning:
JDK9: Remove stopThread RuntimePermission  from the default java.policy
In previous releases, untrusted
code had the "stopThread" RuntimePermission granted by default. This
permission allows untrusted code
to call Thread.stop(), initiating an asynchronous ThreadDeath Error, on
threads in the same thread group.
Having a ThreadDeath Error thrown asynchronously is not something that
trusted code should be expected
to handle gracefully. The permission is no longer granted by default.

Rgds,Rory


[1] http://openjdk.java.net/jeps/261
[2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-May/004309.html



--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

Re: Early Access builds of JDK 9 b118 & JDK 9 with Project Jigsaw, b118 (#4987) are available on java.net

[Mark Thomas]

Rory,

Thanks for letting us know that a new build is available. We continue to
test Tomcat with Java 9 and are tracking multiple issues. The majority
of these have emerged as a result of a review of Tomcat's memory leak
prevention and detection code.

We would appreciate any help you can provide in nudging the following
issues towards resolution. Some of these are very new so it is not
surprising that not much has happened so far.

1. JVMTI bug that prevents tools like YourKit and Eclipse MAT
identifying the root causes of memory leaks caused by initialization of
static Exception fields.
Review ID: JI-9037905

2. Memory leak in com.sun.jndi.ldap.pool.PoolCleaner
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040988.html
https://bugs.openjdk.java.net/browse/JDK-8156824

3. Memory leak in sun.rmi.transport.GC
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040893.html

4. API to trace RMI Target memory leaks without resorting to reflection
(I accept that this is unlikely but If you don't ask...)
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040855.html

5. Rare memory leak in sun.security.pkcs11.SunPKCS11 poller thread
http://mail.openjdk.java.net/pipermail/security-dev/2016-May/013841.html

We have also noticed that JSP compilation is broken. Our current
understanding is that we should be able to fix this with an update to
the Eclipse JDT compiler. We'll let you know if that changes.

Finally, there are still some memory leak issues we haven't reviewed. As
that progresses, we may have a few more issues to add to the memory leak
issues listed above.

Kind regards,

Mark


On 18/05/2016 09:31, Rory O'Donnell wrote:
> 
> Hi Mark,
> 
> Early Access b118  for JDK 9 is
> available on java.net, summary of  changes are listed here
> .
> 
> Early Access b118  (#4913) for JDK 9 with
> Project Jigsaw is available on java.net.
> 
> JDK 9 Build 118 includes a refresh of the module system.
> 
> There are several changes in this update, JDK 9 b118 has the updated
> policy for root modules described
> in JEP 261 [1]. This means that java.corba and the 6 EE modules aren't
> resolved by default and so it will
> look "as if" the types in these modules have been removed. More info on
> the JDK 9 dev mailing list [2].
> 
> A change that went into JDK 9 b102 is worth mentioning:
> JDK9: Remove stopThread RuntimePermission  from the default java.policy
> In previous releases, untrusted
> code had the "stopThread" RuntimePermission granted by default. This
> permission allows untrusted code
> to call Thread.stop(), initiating an asynchronous ThreadDeath Error, on
> threads in the same thread group.
> Having a ThreadDeath Error thrown asynchronously is not something that
> trusted code should be expected
> to handle gracefully. The permission is no longer granted by default.
> 
> Rgds,Rory
> 
> 
> [1] http://openjdk.java.net/jeps/261
> [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-May/004309.html
> 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Early Access builds of JDK 9 b118 & JDK 9 with Project Jigsaw, b118 (#4987) are available on java.net

[Rory O'Donnell]

Hi Mark,

Early Access b118  for JDK 9 is 
available on java.net, summary of  changes are listed here 
.


Early Access b118  (#4913) for JDK 9 with 
Project Jigsaw is available on java.net.


JDK 9 Build 118 includes a refresh of the module system.

There are several changes in this update, JDK 9 b118 has the updated 
policy for root modules described
in JEP 261 [1]. This means that java.corba and the 6 EE modules aren't 
resolved by default and so it will
look "as if" the types in these modules have been removed. More info on 
the JDK 9 dev mailing list [2].


A change that went into JDK 9 b102 is worth mentioning:
JDK9: Remove stopThread RuntimePermission  from the default java.policy 
In previous releases, untrusted
code had the "stopThread" RuntimePermission granted by default. This 
permission allows untrusted code
to call Thread.stop(), initiating an asynchronous ThreadDeath Error, on 
threads in the same thread group.
Having a ThreadDeath Error thrown asynchronously is not something that 
trusted code should be expected

to handle gracefully. The permission is no longer granted by default.

Rgds,Rory


[1] http://openjdk.java.net/jeps/261
[2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-May/004309.html

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland