From serkanozal86 at hotmail.com  Mon Mar  3 20:20:48 2014
From: serkanozal86 at hotmail.com (=?utf-8?B?c2Vya2FuIMO2emFs?=)
Date: Mon, 3 Mar 2014 22:20:48 +0200
Subject: =?utf-8?Q?Hiding_Cla?= =?utf-8?Q?ss_Definit?=
	=?utf-8?Q?ions_from_?= =?utf-8?Q?Compacting?= =?utf-8?Q?_At_GC_Cyc?=
	=?utf-8?B?bGXigI8=?=
Message-ID: <DUB129-W9237D0B634EEBB64A58D2CD98F0@phx.gbl>

Hi all,
I am not sure that target of mail is this group or not but I don't know better one for asking :)
I am currently working on an OffHeap solution and I have a problem with "Compact" phase of GC.As I see at "Compact" phase, location of classes may be changed. I tried class pinning with JNI by "NewGlobalRef" method but it doesn't prevent compacting. As I understood, it only hides object from garbage collected.
In brief, is there any way to prevent compacting of any specific class defition (or object) at GC cycle?Is there any bit, offset or field (such as mark_oop) in object header to prevent compacting of fully from GC for any specific object or class?
Thanks in advance.
--
Serkan ?ZAL
 		 	   		  

From martijnverburg at gmail.com  Mon Mar  3 21:13:23 2014
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 3 Mar 2014 21:13:23 +0000
Subject: =?UTF-8?Q?Re=3A_Hiding_Class_Definitions_from_Compacting_At_GC_C?=
	=?UTF-8?Q?ycle=E2=80=8F?=
In-Reply-To: <DUB129-W9237D0B634EEBB64A58D2CD98F0@phx.gbl>
References: <DUB129-W9237D0B634EEBB64A58D2CD98F0@phx.gbl>
Message-ID: <CAP7YuARp=RYCuPt65Ox3V2PRFXNdOoBvU4aJ8erQYYOvHB5dTA@mail.gmail.com>

Hi Serkan,

You'll want the hotspot-gc-use mailing list :-).

Cheers,
Martijn

On Monday, 3 March 2014, serkan ?zal <serkanozal86 at hotmail.com> wrote:

> Hi all,
> I am not sure that target of mail is this group or not but I don't know
> better one for asking :)
> I am currently working on an OffHeap solution and I have a problem with
> "Compact" phase of GC.As I see at "Compact" phase, location of classes may
> be changed. I tried class pinning with JNI by "NewGlobalRef" method but it
> doesn't prevent compacting. As I understood, it only hides object from
> garbage collected.
> In brief, is there any way to prevent compacting of any specific class
> defition (or object) at GC cycle?Is there any bit, offset or field (such as
> mark_oop) in object header to prevent compacting of fully from GC for any
> specific object or class?
> Thanks in advance.
> --
> Serkan ?ZAL
>



-- 
Cheers,
Martijn


From danilo.ansaloni at usi.ch  Wed Mar  5 09:14:31 2014
From: danilo.ansaloni at usi.ch (danilo.ansaloni at usi.ch)
Date: Wed, 5 Mar 2014 09:14:31 +0000
Subject: Early registration - Modularity'14
Message-ID: <BDEFD397B0F1C4499B0C9E42A876A51D4543640C@usimbox02.usilu.net>

*** MODULARITY '14 ***

13th International Conference on Modularity
April 22-25, 2014
Lugano, Switzerland
http://modularity.info/

In cooperation with:
* ACM SIGSOFT
* ACM SIGPLAN


------------------------------------------------------------------------
IMPORTANT DATES:
- Early registration is available now through March 14 at
  http://modularity14.inf.usi.ch/registration
------------------------------------------------------------------------


Modularity'14 is the premier forum for presentation of research results
and experience reports on software modularity, with an emphasis on
modular structures that cut across traditional abstraction boundaries. 
This year's conference continues the tradition of its successful
predecessors with research, which bring together leading researchers and
practitioners working in such fields as software engineering,
programming languages, systems, and others. 

Continuing the tradition of its successful predecessors, the program of
Modularity'14 will include:
- A Research Track presenting the newest research results.
- A Modularity Visions Track presenting ground-breaking new ideas and
  perspectives on modularity in software.
- Workshops for in-depth discussion of advanced topics in industry and
  research. 
- A coordinated educational program to provide foundations for research
  in the field. 
- Demonstrations of leading-edge technologies.

Modularity'14 will be hosted by the Faculty of Informatics, University
of Lugano (USI), Switzerland.

For complete information, visit: http://modularity.info/


From john.r.rose at oracle.com  Tue Mar 18 00:56:49 2014
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 17 Mar 2014 17:56:49 -0700
Subject: Project Proposal: Panama
Message-ID: <CA08CAD5-6422-4CFC-B48F-CA18CEC1B31C@oracle.com>

I would like to invite discussion on a proposal for a new OpenJDK
Project[1], to be titled "Project Panama", for native interconnect
between code managed by the JVM and APIs for libraries not managed by
the JVM.

To put it in general, basic, idealistic terms:

  If non-Java programmers find some library useful and easy to
  access, it should be similarly accessible to Java programmers.

That ideal is easy to state but hard to carry out.  It must be
carefully compromised relative to the important cultural differences
between unmanaged languages and JVM-based languages.
Java applications must preserve high levels of safety in the handling
of type checks, storage allocation, and exceptional conditions.

I have written out more detailed thoughts on my blog[2].

Goals for Project Panama could include:

 - A better experience than JNI for Java programmers to use C and C++ APIs.
 - Appropriate tools, APIs, and data formats to support these experiences.
 - Appropriate JVM and JDK infrastructure to work with native API elements
   (layouts, functions, etc.) from Java code (interpreter and JIT).
 - A range of options for using native libraries from Java with definite
   and reliable safety levels, allowing for engineered adjustments.

At a minimum, the project should create an integrated foreign function
interface of the type called for in Charles Nutter's JEP 191[3].

The Project should be sponsored by the HotSpot Group, since the JVM will
probably require significant modifications to meet Project goals.

I think the Project should have its own copy of JDK 9 repositories,
but should not feed change sets directly into any JDK.

For documentation beyond Java APIs, and for design works in progress,
the Project should be supplied with a wiki writable to all Project
committers.  Alternatively, the HotSpot wiki could be used.

The Project is likely to need a bug management system in the long run,
but perhaps not initially.  I would appreciate advice from people who
have run similar "feeder projects" for the JDK.

Finally, I would like to propose Charles Nutter of Red Hat as the Lead
for Project Panama.

[1] http://openjdk.java.net/projects/#new-project-vote
[2] https://blogs.oracle.com/jrose/entry/the_isthmus_in_the_vm
[3] http://openjdk.java.net/jeps/191



From gnu.andrew at redhat.com  Wed Mar 19 22:47:40 2014
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 19 Mar 2014 18:47:40 -0400 (EDT)
Subject: JDK 8: General Availability
In-Reply-To: <20140318115518.102088@eggemoggin.niobe.net>
References: <20140318115518.102088@eggemoggin.niobe.net>
Message-ID: <1866731418.2098075.1395269260493.JavaMail.zimbra@redhat.com>


----- Original Message -----
> I'm very pleased to announce that JDK 8 is finished -- two years,
> seven months, and eighteen days after the release of JDK 7.
> 
> My deepest thanks to everyone who contributed to this monumental
> release.
> 
> A few more thoughts: http://mreinhold.org/blog/jdk8-ga
> 
> - Mark
> 

Given the link to the binaries in the blog, I assume you're referring
to the proprietary Oracle release and not OpenJDK?  There also seems to
be a reference to at least one feature I believe isn't part of OpenJDK
(Java Mis?sion Con?trol and Java Flight Recorder) and a lack of reference
to at least one feature that I believe is (the PPC/AIX port).
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From gnu.andrew at redhat.com  Wed Mar 19 22:48:26 2014
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 19 Mar 2014 18:48:26 -0400 (EDT)
Subject: Fwd: [JBS] {Deleted} (JDK-8036469) Provide debugging information
	for programs
In-Reply-To: <JIRA.4716473.1393876232000.129245.1395268511313@aojmv0001.oracle.com>
References: <JIRA.4716473.1393876232000@aojmv0001.oracle.com>
	<JIRA.4716473.1393876232000.129245.1395268511313@aojmv0001.oracle.com>
Message-ID: <397016661.2098565.1395269306961.JavaMail.zimbra@redhat.com>

----- Forwarded Message -----
> 
> 		
> Jennifer Godinez deleted JDK-8036469
> Provide debugging information for programs
> 
> 	This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira
> 

Can someone explain what's going on here? I just got this message for
several of the fixes I've pushed.
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From mark.reinhold at oracle.com  Wed Mar 19 23:11:47 2014
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 19 Mar 2014 16:11:47 -0700
Subject: JDK 8: General Availability
In-Reply-To: <1866731418.2098075.1395269260493.JavaMail.zimbra@redhat.com>
References: <20140318115518.102088@eggemoggin.niobe.net>,
	<1866731418.2098075.1395269260493.JavaMail.zimbra@redhat.com>
Message-ID: <20140319161147.343739@eggemoggin.niobe.net>

2014/3/19 8:47 -0700, Andrew Hughes <gnu.andrew at redhat.com>:
> Given the link to the binaries in the blog, I assume you're referring
> to the proprietary Oracle release and not OpenJDK?

I am referring to both the JDK 8 Project here in OpenJDK and to Oracle's
related binary products.

>                                                     There also seems to
> be a reference to at least one feature I believe isn't part of OpenJDK
> (Java Mission Control and Java Flight Recorder)

Correct.  My blog is not hosted on OpenJDK infrastructure, so I consider
myself free to mention proprietary features.  If that offends you, then
don't read my blog.

>                                                 and a lack of reference
> to at least one feature that I believe is (the PPC/AIX port).

The PPC/AIX port is not in JDK 8.

- Mark


From gnu.andrew at redhat.com  Wed Mar 19 23:49:01 2014
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 19 Mar 2014 19:49:01 -0400 (EDT)
Subject: JDK 8: General Availability
In-Reply-To: <20140319161147.343739@eggemoggin.niobe.net>
References: <20140318115518.102088@eggemoggin.niobe.net>
	<1866731418.2098075.1395269260493.JavaMail.zimbra@redhat.com>
	<20140319161147.343739@eggemoggin.niobe.net>
Message-ID: <1122525822.2109424.1395272941846.JavaMail.zimbra@redhat.com>

----- Original Message -----
> 2014/3/19 8:47 -0700, Andrew Hughes <gnu.andrew at redhat.com>:
> > Given the link to the binaries in the blog, I assume you're referring
> > to the proprietary Oracle release and not OpenJDK?
> 
> I am referring to both the JDK 8 Project here in OpenJDK and to Oracle's
> related binary products.

Ok.

> 
> >                                                     There also seems to
> > be a reference to at least one feature I believe isn't part of OpenJDK
> > (Java Mission Control and Java Flight Recorder)
> 
> Correct.  My blog is not hosted on OpenJDK infrastructure, so I consider
> myself free to mention proprietary features.  If that offends you, then
> don't read my blog.
> 

I'm not offended. I just wanted to clarify what was being discussed and the
link was posted to an OpenJDK mailing list. When simply "JDK 8" is used, it's not
obvious which is being discussed.

> >                                                 and a lack of reference
> > to at least one feature that I believe is (the PPC/AIX port).
> 
> The PPC/AIX port is not in JDK 8.
> 

Oh, ok, I was under the impression, when we were merging it into IcedTea7, that it was
already upstream in 8. In that case, we're going to need to merge the PPC port
into IcedTea8 so our users don't regress to Zero.

> - Mark
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From stuart.marks at oracle.com  Thu Mar 20 02:20:46 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 19 Mar 2014 19:20:46 -0700
Subject: Fwd: [JBS] {Deleted} (JDK-8036469) Provide debugging information
	for programs
In-Reply-To: <397016661.2098565.1395269306961.JavaMail.zimbra@redhat.com>
References: <JIRA.4716473.1393876232000@aojmv0001.oracle.com>	<JIRA.4716473.1393876232000.129245.1395268511313@aojmv0001.oracle.com>
	<397016661.2098565.1395269306961.JavaMail.zimbra@redhat.com>
Message-ID: <532A507E.6080908@oracle.com>

On 3/19/14 3:48 PM, Andrew Hughes wrote:
> ----- Forwarded Message -----
>> 		
>> Jennifer Godinez deleted JDK-8036469
>> Provide debugging information for programs
>>
>> 	This message is automatically generated by JIRA.
>> If you think it was sent incorrectly, please contact your JIRA administrators
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>
> Can someone explain what's going on here? I just got this message for
> several of the fixes I've pushed.

I was startled by these deletion messages as well. I was unaware that it was 
possible to delete bug reports.

The deletion notifications I received were deletions of backport records that 
were presumably created erroneously. The main bug records are still there.

In this case I suspect that JDK-8036469 was a backport of the following bug,

https://bugs.openjdk.java.net/browse/JDK-8015087

which still exists and is in the Resolved state.

s'marks



From joe.darcy at oracle.com  Thu Mar 20 07:05:33 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 20 Mar 2014 00:05:33 -0700
Subject: Fwd: [JBS] {Deleted} (JDK-8036469) Provide debugging information
	for programs
In-Reply-To: <532A507E.6080908@oracle.com>
References: <JIRA.4716473.1393876232000@aojmv0001.oracle.com>	<JIRA.4716473.1393876232000.129245.1395268511313@aojmv0001.oracle.com>	<397016661.2098565.1395269306961.JavaMail.zimbra@redhat.com>
	<532A507E.6080908@oracle.com>
Message-ID: <532A933D.3000103@oracle.com>

Hello,

On 3/19/2014 7:20 PM, Stuart Marks wrote:
> On 3/19/14 3:48 PM, Andrew Hughes wrote:
>> ----- Forwarded Message -----
>>>
>>> Jennifer Godinez deleted JDK-8036469
>>> Provide debugging information for programs
>>>
>>>     This message is automatically generated by JIRA.
>>> If you think it was sent incorrectly, please contact your JIRA 
>>> administrators
>>> For more information on JIRA, see: 
>>> http://www.atlassian.com/software/jira
>>>
>>
>> Can someone explain what's going on here? I just got this message for
>> several of the fixes I've pushed.
>
> I was startled by these deletion messages as well. I was unaware that 
> it was possible to delete bug reports.

It is only possible for those for administrative privileges in JBS.

>
> The deletion notifications I received were deletions of backport 
> records that were presumably created erroneously. The main bug records 
> are still there.
>
> In this case I suspect that JDK-8036469 was a backport of the 
> following bug,
>
> https://bugs.openjdk.java.net/browse/JDK-8015087
>
> which still exists and is in the Resolved state.
>

Due to an errant script mis-creating a repo, several hundred erroneous 
backport were created. The script has been fixed and given the scope of 
the bad information, we thought it was best to remove the bad backports 
so they wouldn't cause confusion in the long run.

-Joe




From volker.simonis at gmail.com  Thu Mar 20 08:19:07 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 20 Mar 2014 09:19:07 +0100
Subject: JDK 8: General Availability
In-Reply-To: <1122525822.2109424.1395272941846.JavaMail.zimbra@redhat.com>
References: <20140318115518.102088@eggemoggin.niobe.net>
	<1866731418.2098075.1395269260493.JavaMail.zimbra@redhat.com>
	<20140319161147.343739@eggemoggin.niobe.net>
	<1122525822.2109424.1395272941846.JavaMail.zimbra@redhat.com>
Message-ID: <CA+3eh12Rthghz5=Vuqxrz_+vkYfafNz1h65gEtCRZKnv+98vnQ@mail.gmail.com>

On Thu, Mar 20, 2014 at 12:49 AM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
> ----- Original Message -----
>> 2014/3/19 8:47 -0700, Andrew Hughes <gnu.andrew at redhat.com>:
>> > Given the link to the binaries in the blog, I assume you're referring
>> > to the proprietary Oracle release and not OpenJDK?
>>
>> I am referring to both the JDK 8 Project here in OpenJDK and to Oracle's
>> related binary products.
>
> Ok.
>
>>
>> >                                                     There also seems to
>> > be a reference to at least one feature I believe isn't part of OpenJDK
>> > (Java Mission Control and Java Flight Recorder)
>>
>> Correct.  My blog is not hosted on OpenJDK infrastructure, so I consider
>> myself free to mention proprietary features.  If that offends you, then
>> don't read my blog.
>>
>
> I'm not offended. I just wanted to clarify what was being discussed and the
> link was posted to an OpenJDK mailing list. When simply "JDK 8" is used, it's not
> obvious which is being discussed.
>
>> >                                                 and a lack of reference
>> > to at least one feature that I believe is (the PPC/AIX port).
>>
>> The PPC/AIX port is not in JDK 8.
>>
>
> Oh, ok, I was under the impression, when we were merging it into IcedTea7, that it was
> already upstream in 8. In that case, we're going to need to merge the PPC port
> into IcedTea8 so our users don't regress to Zero.
>

The PPC/AIX port is currently in JDK9 and is planned for integration
into 8u-dev for the end of this week right in time for the 8u20 time
frame. So if you can wait a week or so, you should be able to merge it
from 8u-dev which should be simpler than taking it from the 9
repositories.

Regards,
Volker

>> - Mark
>>
>
> --
> Andrew :)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: 248BDC07 (https://keys.indymedia.org/)
> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07
>


From nathan.bryant at plusgrade.com  Fri Mar 21 15:37:44 2014
From: nathan.bryant at plusgrade.com (Nathan Bryant)
Date: Fri, 21 Mar 2014 11:37:44 -0400
Subject: Probable JDK6 regression: SSLSocketImpl leak
Message-ID: <CAN+t7Sjt-ZwWLiRz_hfe8osqUFs+_Tp7FMxcyZfW-QmWJ-6W4Q@mail.gmail.com>

Hi,

Looking for some advice on how to debug an issue that's hitting our
production stack.

We have a grails app that's using apache httpclient 4.3.3 for transport to
our backend tier over SSL. This worked fine for a long time but started to
leak after our latest push.

Symptoms: heap dump shows a large number of SSLSocketImpl instances (and
associated byte[] and SocksSocketImpl) that can not be reclaimed. Clicking
through everything in jmap, I can not find a path to the rootset (the paths
to rootset query times out). There are references from finalizers, but I am
consistently seeing "Number of objects pending for finalization: 0" via
jhat and via jmap -finalizerinfo and other heap analysis tools. Thus, these
are objects that "should" be reclaimed by GC.

The finalizer thread itself appears to be idle:

"Finalizer" daemon prio=10 tid=0x0000000001dcc000 nid=0x2437 in
> Object.wait() [0x00007f3b8f5f4000]
>    java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x0000000180014918> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:133)
> - locked <0x0000000180014918> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:149)
> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)


The app works on:

$ java -version
> java version "1.6.0_27"
> OpenJDK Runtime Environment (IcedTea6 1.12.6)
> (6b27-1.12.6-1ubuntu0.10.04.4)
> OpenJDK Client VM (build 20.0-b12, mixed mode, sharing)
>


But fails on:


$ java -version
> java version "1.6.0_30"
> OpenJDK Runtime Environment (IcedTea6 1.13.1) (6b30-1.13.1-1ubuntu2~0.12.04.1)
> OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)


It also fails on the client/32-bit version of 1.6.0_30.

If these objects are pinned by references from native code, I am
assuming this doesn't show up in the heap dump?


From jaroslav.bachorik at oracle.com  Fri Mar 21 15:43:30 2014
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Fri, 21 Mar 2014 16:43:30 +0100
Subject: Probable JDK6 regression: SSLSocketImpl leak
In-Reply-To: <CAN+t7Sjt-ZwWLiRz_hfe8osqUFs+_Tp7FMxcyZfW-QmWJ-6W4Q@mail.gmail.com>
References: <CAN+t7Sjt-ZwWLiRz_hfe8osqUFs+_Tp7FMxcyZfW-QmWJ-6W4Q@mail.gmail.com>
Message-ID: <532C5E22.4020001@oracle.com>

Hi Nathan,

On 21.3.2014 16:37, Nathan Bryant wrote:
> Hi,
>
> Looking for some advice on how to debug an issue that's hitting our
> production stack.
>
> We have a grails app that's using apache httpclient 4.3.3 for transport to
> our backend tier over SSL. This worked fine for a long time but started to
> leak after our latest push.
>
> Symptoms: heap dump shows a large number of SSLSocketImpl instances (and
> associated byte[] and SocksSocketImpl) that can not be reclaimed. Clicking
> through everything in jmap, I can not find a path to the rootset (the paths
> to rootset query times out). There are references from finalizers, but I am

Would it be possible to use more production-ready tools to analyze the 
heap? Like MAT or VisualVM? You should be able to get more meaningful 
information out of them.

Cheers,

-JB-

> consistently seeing "Number of objects pending for finalization: 0" via
> jhat and via jmap -finalizerinfo and other heap analysis tools. Thus, these
> are objects that "should" be reclaimed by GC.
>
> The finalizer thread itself appears to be idle:
>
> "Finalizer" daemon prio=10 tid=0x0000000001dcc000 nid=0x2437 in
>> Object.wait() [0x00007f3b8f5f4000]
>>     java.lang.Thread.State: WAITING (on object monitor)
>> at java.lang.Object.wait(Native Method)
>> - waiting on <0x0000000180014918> (a java.lang.ref.ReferenceQueue$Lock)
>> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:133)
>> - locked <0x0000000180014918> (a java.lang.ref.ReferenceQueue$Lock)
>> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:149)
>> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)
>
>
> The app works on:
>
> $ java -version
>> java version "1.6.0_27"
>> OpenJDK Runtime Environment (IcedTea6 1.12.6)
>> (6b27-1.12.6-1ubuntu0.10.04.4)
>> OpenJDK Client VM (build 20.0-b12, mixed mode, sharing)
>>
>
>
> But fails on:
>
>
> $ java -version
>> java version "1.6.0_30"
>> OpenJDK Runtime Environment (IcedTea6 1.13.1) (6b30-1.13.1-1ubuntu2~0.12.04.1)
>> OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)
>
>
> It also fails on the client/32-bit version of 1.6.0_30.
>
> If these objects are pinned by references from native code, I am
> assuming this doesn't show up in the heap dump?
>



From nathan.bryant at plusgrade.com  Fri Mar 21 15:45:26 2014
From: nathan.bryant at plusgrade.com (Nathan Bryant)
Date: Fri, 21 Mar 2014 11:45:26 -0400
Subject: Probable JDK6 regression: SSLSocketImpl leak
In-Reply-To: <532C5E22.4020001@oracle.com>
References: <CAN+t7Sjt-ZwWLiRz_hfe8osqUFs+_Tp7FMxcyZfW-QmWJ-6W4Q@mail.gmail.com>
	<532C5E22.4020001@oracle.com>
Message-ID: <CAN+t7ShEwJPwpSFSEMvRoUU15t4YLkwRyuu7pdEAAyONJHrTbw@mail.gmail.com>

Hi,

I did do a little poking with MAT/VisualVM. I will try again


On Fri, Mar 21, 2014 at 11:43 AM, Jaroslav Bachorik <
jaroslav.bachorik at oracle.com> wrote:

> Hi Nathan,
>
>
> On 21.3.2014 16:37, Nathan Bryant wrote:
>
>> Hi,
>>
>> Looking for some advice on how to debug an issue that's hitting our
>> production stack.
>>
>> We have a grails app that's using apache httpclient 4.3.3 for transport to
>> our backend tier over SSL. This worked fine for a long time but started to
>> leak after our latest push.
>>
>> Symptoms: heap dump shows a large number of SSLSocketImpl instances (and
>> associated byte[] and SocksSocketImpl) that can not be reclaimed. Clicking
>> through everything in jmap, I can not find a path to the rootset (the
>> paths
>> to rootset query times out). There are references from finalizers, but I
>> am
>>
>
> Would it be possible to use more production-ready tools to analyze the
> heap? Like MAT or VisualVM? You should be able to get more meaningful
> information out of them.
>
> Cheers,
>
> -JB-
>
>
>  consistently seeing "Number of objects pending for finalization: 0" via
>> jhat and via jmap -finalizerinfo and other heap analysis tools. Thus,
>> these
>> are objects that "should" be reclaimed by GC.
>>
>> The finalizer thread itself appears to be idle:
>>
>> "Finalizer" daemon prio=10 tid=0x0000000001dcc000 nid=0x2437 in
>>
>>> Object.wait() [0x00007f3b8f5f4000]
>>>     java.lang.Thread.State: WAITING (on object monitor)
>>> at java.lang.Object.wait(Native Method)
>>> - waiting on <0x0000000180014918> (a java.lang.ref.ReferenceQueue$Lock)
>>> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:133)
>>> - locked <0x0000000180014918> (a java.lang.ref.ReferenceQueue$Lock)
>>> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:149)
>>> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)
>>>
>>
>>
>> The app works on:
>>
>> $ java -version
>>
>>> java version "1.6.0_27"
>>> OpenJDK Runtime Environment (IcedTea6 1.12.6)
>>> (6b27-1.12.6-1ubuntu0.10.04.4)
>>> OpenJDK Client VM (build 20.0-b12, mixed mode, sharing)
>>>
>>>
>>
>> But fails on:
>>
>>
>> $ java -version
>>
>>> java version "1.6.0_30"
>>> OpenJDK Runtime Environment (IcedTea6 1.13.1)
>>> (6b30-1.13.1-1ubuntu2~0.12.04.1)
>>> OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)
>>>
>>
>>
>> It also fails on the client/32-bit version of 1.6.0_30.
>>
>> If these objects are pinned by references from native code, I am
>> assuming this doesn't show up in the heap dump?
>>
>>
>


From aph at redhat.com  Fri Mar 21 16:31:53 2014
From: aph at redhat.com (Andrew Haley)
Date: Fri, 21 Mar 2014 16:31:53 +0000
Subject: Probable JDK6 regression: SSLSocketImpl leak
In-Reply-To: <CAN+t7Sjt-ZwWLiRz_hfe8osqUFs+_Tp7FMxcyZfW-QmWJ-6W4Q@mail.gmail.com>
References: <CAN+t7Sjt-ZwWLiRz_hfe8osqUFs+_Tp7FMxcyZfW-QmWJ-6W4Q@mail.gmail.com>
Message-ID: <532C6979.20101@redhat.com>

On 03/21/2014 03:37 PM, Nathan Bryant wrote:

> Looking for some advice on how to debug an issue that's hitting our
> production stack.
> 
> We have a grails app that's using apache httpclient 4.3.3 for transport to
> our backend tier over SSL. This worked fine for a long time but started to
> leak after our latest push.
> 
> Symptoms: heap dump shows a large number of SSLSocketImpl instances (and
> associated byte[] and SocksSocketImpl) that can not be reclaimed. Clicking
> through everything in jmap, I can not find a path to the rootset (the paths
> to rootset query times out). There are references from finalizers, but I am
> consistently seeing "Number of objects pending for finalization: 0" via
> jhat and via jmap -finalizerinfo and other heap analysis tools. Thus, these
> are objects that "should" be reclaimed by GC.

We know what this is.  It was fixed by this patch:


# HG changeset patch
# User aph
# Date 1393513709 0
# Node ID 04e4c3ec6516727f01f91a9ce8cb72586a3bc502
# Parent  942d4ba93be74b1c401d6532f116da80f5466303
OPENJDK6-29: JDK fails to zero jdk_version_info correctly
Reviewed-by: andrew

diff -r 942d4ba93be7 -r 04e4c3ec6516 src/share/native/common/jdk_util.c
--- a/src/share/native/common/jdk_util.c	Wed Feb 26 18:06:02 2014 +0000
+++ b/src/share/native/common/jdk_util.c	Thu Feb 27 15:08:29 2014 +0000
@@ -76,7 +76,7 @@
     }


-    memset(info, 0, sizeof(info_size));
+    memset(info, 0, info_size);
     info->jdk_version = ((jdk_major_version & 0xFF) << 24) |
                         ((jdk_minor_version & 0xFF) << 16) |
                         ((jdk_micro_version & 0xFF) << 8)  |


Andrew.



From gnu.andrew at redhat.com  Fri Mar 21 17:18:29 2014
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 21 Mar 2014 13:18:29 -0400 (EDT)
Subject: JDK 8: General Availability
In-Reply-To: <CA+3eh12Rthghz5=Vuqxrz_+vkYfafNz1h65gEtCRZKnv+98vnQ@mail.gmail.com>
References: <20140318115518.102088@eggemoggin.niobe.net>
	<1866731418.2098075.1395269260493.JavaMail.zimbra@redhat.com>
	<20140319161147.343739@eggemoggin.niobe.net>
	<1122525822.2109424.1395272941846.JavaMail.zimbra@redhat.com>
	<CA+3eh12Rthghz5=Vuqxrz_+vkYfafNz1h65gEtCRZKnv+98vnQ@mail.gmail.com>
Message-ID: <2098538588.977100.1395422309265.JavaMail.zimbra@redhat.com>



----- Original Message -----
> On Thu, Mar 20, 2014 at 12:49 AM, Andrew Hughes <gnu.andrew at redhat.com>
> wrote:
> > ----- Original Message -----
> >> 2014/3/19 8:47 -0700, Andrew Hughes <gnu.andrew at redhat.com>:
> >> > Given the link to the binaries in the blog, I assume you're referring
> >> > to the proprietary Oracle release and not OpenJDK?
> >>
> >> I am referring to both the JDK 8 Project here in OpenJDK and to Oracle's
> >> related binary products.
> >
> > Ok.
> >
> >>
> >> >                                                     There also seems to
> >> > be a reference to at least one feature I believe isn't part of OpenJDK
> >> > (Java Mission Control and Java Flight Recorder)
> >>
> >> Correct.  My blog is not hosted on OpenJDK infrastructure, so I consider
> >> myself free to mention proprietary features.  If that offends you, then
> >> don't read my blog.
> >>
> >
> > I'm not offended. I just wanted to clarify what was being discussed and the
> > link was posted to an OpenJDK mailing list. When simply "JDK 8" is used,
> > it's not
> > obvious which is being discussed.
> >
> >> >                                                 and a lack of reference
> >> > to at least one feature that I believe is (the PPC/AIX port).
> >>
> >> The PPC/AIX port is not in JDK 8.
> >>
> >
> > Oh, ok, I was under the impression, when we were merging it into IcedTea7,
> > that it was
> > already upstream in 8. In that case, we're going to need to merge the PPC
> > port
> > into IcedTea8 so our users don't regress to Zero.
> >
> 
> The PPC/AIX port is currently in JDK9 and is planned for integration
> into 8u-dev for the end of this week right in time for the 8u20 time
> frame. So if you can wait a week or so, you should be able to merge it
> from 8u-dev which should be simpler than taking it from the 9
> repositories.
> 

No rush here and I plan to work from 8u anyway. So sounds like it will all
work out fine :)

> Regards,
> Volker
> 
> >> - Mark
> >>
> >
> > --
> > Andrew :)
> >
> > Free Java Software Engineer
> > Red Hat, Inc. (http://www.redhat.com)
> >
> > PGP Key: 248BDC07 (https://keys.indymedia.org/)
> > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07
> >
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From nathan.bryant at plusgrade.com  Fri Mar 21 18:13:38 2014
From: nathan.bryant at plusgrade.com (Nathan Bryant)
Date: Fri, 21 Mar 2014 14:13:38 -0400
Subject: Probable JDK6 regression: SSLSocketImpl leak
In-Reply-To: <532C6979.20101@redhat.com>
References: <CAN+t7Sjt-ZwWLiRz_hfe8osqUFs+_Tp7FMxcyZfW-QmWJ-6W4Q@mail.gmail.com>
	<532C6979.20101@redhat.com>
Message-ID: <CAN+t7SgtpLQredC9n4iapfn-B0DHqT7PKn3Efss3J5JMw5rpxw@mail.gmail.com>

Thanks, Andrew.


On Fri, Mar 21, 2014 at 12:31 PM, Andrew Haley <aph at redhat.com> wrote:

> On 03/21/2014 03:37 PM, Nathan Bryant wrote:
>
> > Looking for some advice on how to debug an issue that's hitting our
> > production stack.
> >
> > We have a grails app that's using apache httpclient 4.3.3 for transport
> to
> > our backend tier over SSL. This worked fine for a long time but started
> to
> > leak after our latest push.
> >
> > Symptoms: heap dump shows a large number of SSLSocketImpl instances (and
> > associated byte[] and SocksSocketImpl) that can not be reclaimed.
> Clicking
> > through everything in jmap, I can not find a path to the rootset (the
> paths
> > to rootset query times out). There are references from finalizers, but I
> am
> > consistently seeing "Number of objects pending for finalization: 0" via
> > jhat and via jmap -finalizerinfo and other heap analysis tools. Thus,
> these
> > are objects that "should" be reclaimed by GC.
>
> We know what this is.  It was fixed by this patch:
>
>
> # HG changeset patch
> # User aph
> # Date 1393513709 0
> # Node ID 04e4c3ec6516727f01f91a9ce8cb72586a3bc502
> # Parent  942d4ba93be74b1c401d6532f116da80f5466303
> OPENJDK6-29: JDK fails to zero jdk_version_info correctly
> Reviewed-by: andrew
>
> diff -r 942d4ba93be7 -r 04e4c3ec6516 src/share/native/common/jdk_util.c
> --- a/src/share/native/common/jdk_util.c        Wed Feb 26 18:06:02 2014
> +0000
> +++ b/src/share/native/common/jdk_util.c        Thu Feb 27 15:08:29 2014
> +0000
> @@ -76,7 +76,7 @@
>      }
>
>
> -    memset(info, 0, sizeof(info_size));
> +    memset(info, 0, info_size);
>      info->jdk_version = ((jdk_major_version & 0xFF) << 24) |
>                          ((jdk_minor_version & 0xFF) << 16) |
>                          ((jdk_micro_version & 0xFF) << 8)  |
>
>
> Andrew.
>
>


From fweimer at redhat.com  Thu Mar 27 13:55:57 2014
From: fweimer at redhat.com (Florian Weimer)
Date: Thu, 27 Mar 2014 14:55:57 +0100
Subject: Windows XP support in OpenJDK 9
Message-ID: <53342DED.7040502@redhat.com>

Has it been decided yet if OpenJDK 9 will still support Windows XP?  Or 
can we start removing backward compatibility kludges?

-- 
Florian Weimer / Red Hat Product Security Team


From Alan.Bateman at oracle.com  Thu Mar 27 14:02:27 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 27 Mar 2014 14:02:27 +0000
Subject: Windows XP support in OpenJDK 9
In-Reply-To: <53342DED.7040502@redhat.com>
References: <53342DED.7040502@redhat.com>
Message-ID: <53342F73.7060202@oracle.com>

On 27/03/2014 13:55, Florian Weimer wrote:
> Has it been decided yet if OpenJDK 9 will still support Windows XP?  
> Or can we start removing backward compatibility kludges?
>
Here's another a thread on this topic:

http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-February/000385.html




From richardfearn at gmail.com  Mon Mar 31 13:54:28 2014
From: richardfearn at gmail.com (Richard Fearn)
Date: Mon, 31 Mar 2014 14:54:28 +0100
Subject: OpenJDK repo list
Message-ID: <CAA-kXAGaF_65Wn2QAcVaO93+kRbv4uTX8BXO=aWr54e4uXLfPw@mail.gmail.com>

Hi

I believe this:

  http://hg.openjdk.java.net/

is meant to show a list of OpenJDK repositories, but I get a 503 error.
That URL is given on error pages, like this one:

  http://hg.openjdk.java.net/jdk8/bad

Is this a known problem?

Regards,

Rich

-- 
Richard Fearn
richardfearn at gmail.com


From chris.hegarty at oracle.com  Mon Mar 31 14:05:06 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 31 Mar 2014 15:05:06 +0100
Subject: OpenJDK repo list
In-Reply-To: <CAA-kXAGaF_65Wn2QAcVaO93+kRbv4uTX8BXO=aWr54e4uXLfPw@mail.gmail.com>
References: <CAA-kXAGaF_65Wn2QAcVaO93+kRbv4uTX8BXO=aWr54e4uXLfPw@mail.gmail.com>
Message-ID: <53397612.7070004@oracle.com>

Already reported to the openjdk infrastructure group.

   http://mail.openjdk.java.net/pipermail/web-discuss/2014-March/000445.html

-Chris.

On 31/03/14 14:54, Richard Fearn wrote:
> Hi
>
> I believe this:
>
>    http://hg.openjdk.java.net/
>
> is meant to show a list of OpenJDK repositories, but I get a 503 error.
> That URL is given on error pages, like this one:
>
>    http://hg.openjdk.java.net/jdk8/bad
>
> Is this a known problem?
>
> Regards,
>
> Rich
>


From richardfearn at gmail.com  Mon Mar 31 14:17:07 2014
From: richardfearn at gmail.com (Richard Fearn)
Date: Mon, 31 Mar 2014 15:17:07 +0100
Subject: OpenJDK repo list
In-Reply-To: <53397612.7070004@oracle.com>
References: <CAA-kXAGaF_65Wn2QAcVaO93+kRbv4uTX8BXO=aWr54e4uXLfPw@mail.gmail.com>
	<53397612.7070004@oracle.com>
Message-ID: <CAA-kXAE4=qfLZVXVGN7HSCH=Kgoo8yy+CBn+mmO-WDspROn5dQ@mail.gmail.com>

> Already reported to the openjdk infrastructure group.
>
>   http://mail.openjdk.java.net/pipermail/web-discuss/2014-March/000445.html

Thanks!

Rich

-- 
Richard Fearn
richardfearn at gmail.com