From fcassia at gmail.com  Sat Mar  2 21:45:19 2013
From: fcassia at gmail.com (Fernando Cassia)
Date: Sat, 2 Mar 2013 18:45:19 -0300
Subject: J7u15 blocked by FF19 - OpenJDK too?
Message-ID: <CACGw4H6HQdvzViuB7=-vFgHzLJpbwzojaCFKwQ=e=3GqvmMLiw@mail.gmail.com>

Any idea why FF19 insists on blocking Java 7 update 15 saying "this
plugin has security issues"?.

I thought all the major high-risk holes had been plugged in this last CPU ?

Could someone confirm if firefox 19, as downloaded from Mozilla (not
repos) also includes blocking the latest greatest OpenJDK/Icedtea by
default?

I?m asking here as I don?t have currently access to my Linux box, and
want to decipher if this is something general against the Java plugin,
or targets only the proprietary plugin from Oracle.

TIA,
FC


From donald.smith at oracle.com  Sun Mar  3 19:27:40 2013
From: donald.smith at oracle.com (Donald Smith)
Date: Sun, 03 Mar 2013 14:27:40 -0500
Subject: J7u15 blocked by FF19 - OpenJDK too?
In-Reply-To: <CACGw4H6HQdvzViuB7=-vFgHzLJpbwzojaCFKwQ=e=3GqvmMLiw@mail.gmail.com>
References: <CACGw4H6HQdvzViuB7=-vFgHzLJpbwzojaCFKwQ=e=3GqvmMLiw@mail.gmail.com>
Message-ID: <5133A42C.1050701@oracle.com>

I'll comment re: Oracle JRE.  Hopefully someone who maintains or uses 
some of the other JRE's you mention can comment.

See:
https://bugzilla.mozilla.org/show_bug.cgi?id=843373

Some notes:
  - Mozilla will be eventually enabling "Click to Play" (CtP) for all 
plugins (not just Java) within the next few months
  - The UI for CtP in FF is not quite ready yet, so some of the warnings 
are admittedly out of context  (see comment 7)
  - If you follow the bug, you can see they decided to CtP Java early 
anyways (see comments)

That being said, I'm hoping that the next update, whenever that happens 
to be, won't have the CtP set in FF until the FF CtP UI work is 
completed and the warnings are a bit clearer.

  - Don

On 02/03/2013 4:45 PM, Fernando Cassia wrote:
> Any idea why FF19 insists on blocking Java 7 update 15 saying "this
> plugin has security issues"?.



From fweimer at redhat.com  Sun Mar  3 19:51:13 2013
From: fweimer at redhat.com (Florian Weimer)
Date: Sun, 03 Mar 2013 20:51:13 +0100
Subject: J7u15 blocked by FF19 - OpenJDK too?
In-Reply-To: <CACGw4H6HQdvzViuB7=-vFgHzLJpbwzojaCFKwQ=e=3GqvmMLiw@mail.gmail.com>
References: <CACGw4H6HQdvzViuB7=-vFgHzLJpbwzojaCFKwQ=e=3GqvmMLiw@mail.gmail.com>
Message-ID: <5133A9B1.9030803@redhat.com>

On 03/02/2013 10:45 PM, Fernando Cassia wrote:
> Any idea why FF19 insists on blocking Java 7 update 15 saying "this
> plugin has security issues"?.

You should ask Mozilla about their actions, but this could be in 
response to attacks reportedly in the wild which successfully exploit a 
memory-safety vulnerability in 7u15.

-- 
Florian Weimer / Red Hat Product Security Team


From fcassia at gmail.com  Sun Mar  3 22:29:37 2013
From: fcassia at gmail.com (Fernando Cassia)
Date: Sun, 3 Mar 2013 19:29:37 -0300
Subject: J7u15 blocked by FF19 - OpenJDK too?
In-Reply-To: <5133A9B1.9030803@redhat.com>
References: <CACGw4H6HQdvzViuB7=-vFgHzLJpbwzojaCFKwQ=e=3GqvmMLiw@mail.gmail.com>
	<5133A9B1.9030803@redhat.com>
Message-ID: <CACGw4H59V2m5Xp84qrdGJHoKeEyP-Oa1OJFsUkajDHcvmfee-g@mail.gmail.com>

On Sun, Mar 3, 2013 at 4:51 PM, Florian Weimer <fweimer at redhat.com> wrote:
> On 03/02/2013 10:45 PM, Fernando Cassia wrote:
>>
>> Any idea why FF19 insists on blocking Java 7 update 15 saying "this
>> plugin has security issues"?.
>
>
> You should ask Mozilla about their actions, but this could be in response to
> attacks reportedly in the wild which successfully exploit a memory-safety
> vulnerability in 7u15.

Thanks Florian and everybody else who replied.

FC


From danilo.ansaloni at usi.ch  Mon Mar  4 19:54:31 2013
From: danilo.ansaloni at usi.ch (danilo.ansaloni at usi.ch)
Date: Mon, 4 Mar 2013 19:54:31 +0000
Subject: PPPJ'13 - Call for Papers
Message-ID: <BDEFD397B0F1C4499B0C9E42A876A51D453EE655@usimbox02.usilu.net>

                           CALL FOR PAPERS

                               PPPJ'13

      2013 International Conference on Principles and Practices
                 of Programming on the Java platform:
                virtual machines, languages, and tools

                        September 11-13, 2013
                          Stuttgart, Germany

                       http://pppj2013.dhbw.de/

            In cooperation with ACM SIGPLAN and ACM SIGAPP
                       Sponsored by Oracle Labs


The Java platform is multi-faceted, covering a rich diversity of
systems, languages, tools, frameworks, and techniques. PPPJ'13 - the
10th conference in the PPPJ series - provides a forum for researchers,
practitioners, and educators to present and discuss novel results on
all aspects of programming on the Java platform including virtual
machines, languages, tools, methods, frameworks, libraries, case
studies, and experience reports.


TOPICS 

Virtual machines for Java and Java-like language support:
  - JVM and similar VMs
  - VM design and optimization
  - VMs for mobile and embedded devices
  - Real-time VMs
  - Isolation and resource control

Languages on the Java platform:
  - JVM languages (Clojure, Groovy, Java, JRuby, Kotlin, Scala, ...)
  - Domain-specific languages
  - Language design and calculi
  - Compilers
  - Language interoperability
  - Parallelism and concurrency
  - Modular and aspect-oriented programming
  - Model-driven development
  - Frameworks and applications
  - Teaching

Techniques and tools for the Java platform:
  - Static and dynamic program analysis 
  - Testing 
  - Verification
  - Security and information flow 
  - Workload characterization 

Do not hesitate to contact the PC Chair <walter.binder at usi.ch> to
clarify whether a particular topic is in the scope of PPPJ'13 or not.


DATES

  May  27: Abstracts due   (23:59 anywhere on earth)
  May  31: Submissions due (23:59 anywhere on earth)
  June 28: Author notification
  July 12: Camera-ready papers due
  Sept. 11-13: Conference


SUBMISSION GUIDELINES

PPPJ'13 submissions must conform to both the ACM Policy on Prior 
Publication and Simultaneous Submissions and to the SIGPLAN 
Republication Policy.

  http://www.acm.org/publications/policies/sim_submissions/
  http://www.sigplan.org/Resources/Policies/Republication

Papers will be evaluated according to their significance, originality, 
technical content, style, and relevance to the conference.

Three types of paper submissions are accepted: 

Full research paper : up to 12 pages
Short research paper: up to 6 pages
Tool paper: up to 4 pages

Clearly indicate in the paper whether it is to be evaluated as a full
research paper, short research paper, or tool paper. Papers that do
not meet the formatting requirements or are too long for the
respective paper type will be rejected without review.

All papers must conform to the ACM SIGPLAN style 'sigplanconf.cls' 
with a font size of 9 point (option '9pt').

  http://www.sigplan.org/authorInformation.htm

Submission page:

  http://www.easychair.org/conferences/?conf=pppj13

The conference proceedings will be published as part of the ACM
International Proceedings Series and will be disseminated through the
ACM Digital Library. At least one author of each accepted paper is
required to attend the conference and present the paper. The authors
of the best papers presented at PPPJ'13 will be invited to submit
extended versions of their papers to a journal special issue.


ORGANIZATION

General Chair: 
  Martin Pl?micke, Duale Hochschule Baden-W?rttemberg, Germany
 
Program Chair: 
  Walter Binder, University of Lugano, Switzerland

Publicity Chair: 
  Danilo Ansaloni, University of Lugano, Switzerland

Program Committee:
  Judith Bishop, Microsoft Research, USA
  Steve Blackburn, Australian National University, Australia
  Christoph Bockisch, University of Twente, The Netherlands
  Eric Bodden, European Center for Security and Privacy by Design, Germany
  Shigeru Chiba, University of Tokyo, Japan
  Ferruccio Damiani, University of Torino, Italy
  Erik Ernst, Aarhus University, Denmark
  Michael Franz, University of California Irvine, USA
  Nicolas Geoffray, Google Inc., Denmark
  Samuel Z. Guyer, Tufts University, USA
  Michael Haupt, Oracle Labs, Germany
  Nigel Horspool, University of Victoria, Canada
  Einar Broch Johnsen, University of Oslo, Norway
  Stephen Kell, University of Lugano, Switzerland
  Andreas Krall, Vienna University of Technology, Austria
  Doug Lea, State University of New York at Oswego, USA
  Hanspeter M?ssenb?ck, Johannes Kepler University of Linz, Austria
  Nathaniel Nystrom, University of Lugano, Switzerland
  Rei Odaira, IBM Research Tokyo, Japan
  Jens Palsberg, University of California Los Angeles, USA
  Jennifer Sartor, Ghent University, Belgium
  Ina Schaefer, Technische Universit?t Braunschweig, Germany
  Martin Schoeberl, Technical University of Denmark, Denmark
  Bernhard Scholz, University of Sydney, Australia
  Andreas Sewe, Technische Universit?t Darmstadt, Germany
  Niranjan Suri, Florida Institute for Human & Machine Cognition, USA
  Eli Tilevich, Virginia Tech, USA
  Petr Tuma, Charles University, Czech Republic
  Alex Villaz?n, Universidad Privada Boliviana, Bolivia
  Christian Wimmer, Oracle Labs, USA
  Jianjun Zhao, Shanghai Jiao Tong University, China

Steering committee:
  Markus Aleksy, ABB Corporate Research, Germany
  Vasco Amaral, Universidade Nova de Lisboa, Portugal
  Conrad Cunningham, University of Mississippi, USA
  Ralf Gitzel, ABB Corporate Research, Germany
  Christian Probst, Technical University of Denmark, Denmark


From ogierke at vmware.com  Wed Mar  6 10:28:12 2013
From: ogierke at vmware.com (Oliver Gierke)
Date: Wed, 6 Mar 2013 11:28:12 +0100
Subject: Cannot install JDK7 update on machine with JDK8 EA installed
Message-ID: <A0A0C21B-E9CE-417A-B48D-D24D6AACA157@vmware.com>

Hi all,

I am unable to install the latest JDK7 update on a Mac (Mountain Lion). The installer immediately quits with "Higher version already installed!". Trying to report this as bug through the bug tracker I was directed to a page saying "If you have encountered a bug in a JRE not released by Oracle, please contact the specific vendor about your bug." This is probably not really up to date anymore as well.

Cheers,
Ollie

-- 
/**
 * @author Oliver Gierke - Senior Member Technical Staff
 *
 * @param email ogierke at vmware.com
 * @param phone +49-151-50465477
 * @param fax   +49-351-418898439
 * @param skype einsdreizehn
 * @see http://www.olivergierke.de
 */


From benjamin.john.evans at gmail.com  Wed Mar  6 10:43:16 2013
From: benjamin.john.evans at gmail.com (Ben Evans)
Date: Wed, 6 Mar 2013 10:43:16 +0000
Subject: Cannot install JDK7 update on machine with JDK8 EA installed
In-Reply-To: <A0A0C21B-E9CE-417A-B48D-D24D6AACA157@vmware.com>
References: <A0A0C21B-E9CE-417A-B48D-D24D6AACA157@vmware.com>
Message-ID: <CABKW8RgOZZQBmTVCBF1P_ms26FKG8yMAdR1MGky+b==w6_Bu9w@mail.gmail.com>

Oliver,

Can you post the exact versions and natures of each build?

I can confirm that on Lion, I have multiple 8's - both ORCL & OpenJDK
/ Lambda as well as latest 7.

Thanks,

Ben

On Wed, Mar 6, 2013 at 10:28 AM, Oliver Gierke <ogierke at vmware.com> wrote:
> Hi all,
>
> I am unable to install the latest JDK7 update on a Mac (Mountain Lion). The installer immediately quits with "Higher version already installed!". Trying to report this as bug through the bug tracker I was directed to a page saying "If you have encountered a bug in a JRE not released by Oracle, please contact the specific vendor about your bug." This is probably not really up to date anymore as well.
>
> Cheers,
> Ollie
>
> --
> /**
>  * @author Oliver Gierke - Senior Member Technical Staff
>  *
>  * @param email ogierke at vmware.com
>  * @param phone +49-151-50465477
>  * @param fax   +49-351-418898439
>  * @param skype einsdreizehn
>  * @see http://www.olivergierke.de
>  */


From ogierke at vmware.com  Wed Mar  6 11:07:10 2013
From: ogierke at vmware.com (Oliver Gierke)
Date: Wed, 6 Mar 2013 12:07:10 +0100
Subject: Cannot install JDK7 update on machine with JDK8 EA installed
In-Reply-To: <CABKW8RgOZZQBmTVCBF1P_ms26FKG8yMAdR1MGky+b==w6_Bu9w@mail.gmail.com>
References: <A0A0C21B-E9CE-417A-B48D-D24D6AACA157@vmware.com>
	<CABKW8RgOZZQBmTVCBF1P_ms26FKG8yMAdR1MGky+b==w6_Bu9w@mail.gmail.com>
Message-ID: <D904AF28-B0A8-49B0-A0D5-7D1E9FD927F0@vmware.com>

Of course:

$ java -version
openjdk version "1.8.0-ea"
OpenJDK Runtime Environment (build 1.8.0-ea-lambda-nightly-h3207-20130205-b76-b00)
OpenJDK 64-Bit Server VM (build 25.0-b15, mixed mode)

$ java -version
java version "1.7.0_15"
Java(TM) SE Runtime Environment (build 1.7.0_15-b03)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)

To be precise: I installed Java 8 *after* I had Java 7 of course. It seems that the updater now checks for the most recent version and assumes I don't want to use 7 if I already have 8, which is a bit of a stretch. 

It generally seems that Oracle is trying to push installations into a "single Java version only" (by explicitly removing Java 6). This is a quite unbearable situation especially for developers that *have* to build with older versions of a JDK.

Cheers,
Ollie

Am 06.03.2013 um 11:43 schrieb Ben Evans <benjamin.john.evans at gmail.com>:

> Oliver,
> 
> Can you post the exact versions and natures of each build?
> 
> I can confirm that on Lion, I have multiple 8's - both ORCL & OpenJDK
> / Lambda as well as latest 7.
> 
> Thanks,
> 
> Ben
> 
> On Wed, Mar 6, 2013 at 10:28 AM, Oliver Gierke <ogierke at vmware.com> wrote:
>> Hi all,
>> 
>> I am unable to install the latest JDK7 update on a Mac (Mountain Lion). The installer immediately quits with "Higher version already installed!". Trying to report this as bug through the bug tracker I was directed to a page saying "If you have encountered a bug in a JRE not released by Oracle, please contact the specific vendor about your bug." This is probably not really up to date anymore as well.
>> 
>> Cheers,
>> Ollie
>> 
>> --
>> /**
>> * @author Oliver Gierke - Senior Member Technical Staff
>> *
>> * @param email ogierke at vmware.com
>> * @param phone +49-151-50465477
>> * @param fax   +49-351-418898439
>> * @param skype einsdreizehn
>> * @see http://www.olivergierke.de
>> */

-- 
/**
 * @author Oliver Gierke - Senior Member Technical Staff
 *
 * @param email ogierke at vmware.com
 * @param phone +49-151-50465477
 * @param fax   +49-351-418898439
 * @param skype einsdreizehn
 * @see http://www.olivergierke.de
 */


From martijnverburg at gmail.com  Wed Mar  6 15:16:17 2013
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 6 Mar 2013 15:16:17 +0000
Subject: Cannot install JDK7 update on machine with JDK8 EA installed
In-Reply-To: <D904AF28-B0A8-49B0-A0D5-7D1E9FD927F0@vmware.com>
References: <A0A0C21B-E9CE-417A-B48D-D24D6AACA157@vmware.com>
	<CABKW8RgOZZQBmTVCBF1P_ms26FKG8yMAdR1MGky+b==w6_Bu9w@mail.gmail.com>
	<D904AF28-B0A8-49B0-A0D5-7D1E9FD927F0@vmware.com>
Message-ID: <CAP7YuASNC=oe8itChwyZo0V6O-A9drfaNc-897B-9Hsq7Yd0Lw@mail.gmail.com>

Hi Oliver,

Yes this has been discussed in the past.  For us power users I believe that
downloading and installing the tar archives works fine.  Can't remember
what the official line was regarding supporting multiple versions.

Cheers,
Martijn


On 6 March 2013 11:07, Oliver Gierke <ogierke at vmware.com> wrote:

> Of course:
>
> $ java -version
> openjdk version "1.8.0-ea"
> OpenJDK Runtime Environment (build
> 1.8.0-ea-lambda-nightly-h3207-20130205-b76-b00)
> OpenJDK 64-Bit Server VM (build 25.0-b15, mixed mode)
>
> $ java -version
> java version "1.7.0_15"
> Java(TM) SE Runtime Environment (build 1.7.0_15-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
>
> To be precise: I installed Java 8 *after* I had Java 7 of course. It seems
> that the updater now checks for the most recent version and assumes I don't
> want to use 7 if I already have 8, which is a bit of a stretch.
>
> It generally seems that Oracle is trying to push installations into a
> "single Java version only" (by explicitly removing Java 6). This is a quite
> unbearable situation especially for developers that *have* to build with
> older versions of a JDK.
>
> Cheers,
> Ollie
>
> Am 06.03.2013 um 11:43 schrieb Ben Evans <benjamin.john.evans at gmail.com>:
>
> > Oliver,
> >
> > Can you post the exact versions and natures of each build?
> >
> > I can confirm that on Lion, I have multiple 8's - both ORCL & OpenJDK
> > / Lambda as well as latest 7.
> >
> > Thanks,
> >
> > Ben
> >
> > On Wed, Mar 6, 2013 at 10:28 AM, Oliver Gierke <ogierke at vmware.com>
> wrote:
> >> Hi all,
> >>
> >> I am unable to install the latest JDK7 update on a Mac (Mountain Lion).
> The installer immediately quits with "Higher version already installed!".
> Trying to report this as bug through the bug tracker I was directed to a
> page saying "If you have encountered a bug in a JRE not released by Oracle,
> please contact the specific vendor about your bug." This is probably not
> really up to date anymore as well.
> >>
> >> Cheers,
> >> Ollie
> >>
> >> --
> >> /**
> >> * @author Oliver Gierke - Senior Member Technical Staff
> >> *
> >> * @param email ogierke at vmware.com
> >> * @param phone +49-151-50465477
> >> * @param fax   +49-351-418898439
> >> * @param skype einsdreizehn
> >> * @see http://www.olivergierke.de
> >> */
>
> --
> /**
>  * @author Oliver Gierke - Senior Member Technical Staff
>  *
>  * @param email ogierke at vmware.com
>  * @param phone +49-151-50465477
>  * @param fax   +49-351-418898439
>  * @param skype einsdreizehn
>  * @see http://www.olivergierke.de
>  */
>


From ogierke at vmware.com  Thu Mar  7 18:06:02 2013
From: ogierke at vmware.com (Oliver Gierke)
Date: Thu, 7 Mar 2013 19:06:02 +0100
Subject: Cannot install JDK7 update on machine with JDK8 EA installed
In-Reply-To: <CAP7YuASNC=oe8itChwyZo0V6O-A9drfaNc-897B-9Hsq7Yd0Lw@mail.gmail.com>
References: <A0A0C21B-E9CE-417A-B48D-D24D6AACA157@vmware.com>
	<CABKW8RgOZZQBmTVCBF1P_ms26FKG8yMAdR1MGky+b==w6_Bu9w@mail.gmail.com>
	<D904AF28-B0A8-49B0-A0D5-7D1E9FD927F0@vmware.com>
	<CAP7YuASNC=oe8itChwyZo0V6O-A9drfaNc-897B-9Hsq7Yd0Lw@mail.gmail.com>
Message-ID: <7E9CBC0C-43C4-48F0-813D-CE91C6697656@vmware.com>

Tar files for Mac OS? Currently the download page [0] only lists the DMG containing the installer that refuses the install.

Cheers,
Ollie

[0] http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html

Am 06.03.2013 um 16:16 schrieb Martijn Verburg <martijnverburg at gmail.com>:

> Hi Oliver,
> 
> Yes this has been discussed in the past.  For us power users I believe that downloading and installing the tar archives works fine.  Can't remember what the official line was regarding supporting multiple versions.
> 
> Cheers,
> Martijn
> 
> 
> On 6 March 2013 11:07, Oliver Gierke <ogierke at vmware.com> wrote:
> Of course:
> 
> $ java -version
> openjdk version "1.8.0-ea"
> OpenJDK Runtime Environment (build 1.8.0-ea-lambda-nightly-h3207-20130205-b76-b00)
> OpenJDK 64-Bit Server VM (build 25.0-b15, mixed mode)
> 
> $ java -version
> java version "1.7.0_15"
> Java(TM) SE Runtime Environment (build 1.7.0_15-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
> 
> To be precise: I installed Java 8 *after* I had Java 7 of course. It seems that the updater now checks for the most recent version and assumes I don't want to use 7 if I already have 8, which is a bit of a stretch.
> 
> It generally seems that Oracle is trying to push installations into a "single Java version only" (by explicitly removing Java 6). This is a quite unbearable situation especially for developers that *have* to build with older versions of a JDK.
> 
> Cheers,
> Ollie
> 
> Am 06.03.2013 um 11:43 schrieb Ben Evans <benjamin.john.evans at gmail.com>:
> 
> > Oliver,
> >
> > Can you post the exact versions and natures of each build?
> >
> > I can confirm that on Lion, I have multiple 8's - both ORCL & OpenJDK
> > / Lambda as well as latest 7.
> >
> > Thanks,
> >
> > Ben
> >
> > On Wed, Mar 6, 2013 at 10:28 AM, Oliver Gierke <ogierke at vmware.com> wrote:
> >> Hi all,
> >>
> >> I am unable to install the latest JDK7 update on a Mac (Mountain Lion). The installer immediately quits with "Higher version already installed!". Trying to report this as bug through the bug tracker I was directed to a page saying "If you have encountered a bug in a JRE not released by Oracle, please contact the specific vendor about your bug." This is probably not really up to date anymore as well.
> >>
> >> Cheers,
> >> Ollie
> >>
> >> --
> >> /**
> >> * @author Oliver Gierke - Senior Member Technical Staff
> >> *
> >> * @param email ogierke at vmware.com
> >> * @param phone +49-151-50465477
> >> * @param fax   +49-351-418898439
> >> * @param skype einsdreizehn
> >> * @see http://www.olivergierke.de
> >> */
> 
> --
> /**
>  * @author Oliver Gierke - Senior Member Technical Staff
>  *
>  * @param email ogierke at vmware.com
>  * @param phone +49-151-50465477
>  * @param fax   +49-351-418898439
>  * @param skype einsdreizehn
>  * @see http://www.olivergierke.de
>  */
> 

-- 
/**
 * @author Oliver Gierke - Senior Member Technical Staff
 *
 * @param email ogierke at vmware.com
 * @param phone +49-151-50465477
 * @param fax   +49-351-418898439
 * @param skype einsdreizehn
 * @see http://www.olivergierke.de
 */


From martijnverburg at gmail.com  Thu Mar  7 18:56:49 2013
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Thu, 7 Mar 2013 18:56:49 +0000
Subject: Cannot install JDK7 update on machine with JDK8 EA installed
In-Reply-To: <7E9CBC0C-43C4-48F0-813D-CE91C6697656@vmware.com>
References: <A0A0C21B-E9CE-417A-B48D-D24D6AACA157@vmware.com>
	<CABKW8RgOZZQBmTVCBF1P_ms26FKG8yMAdR1MGky+b==w6_Bu9w@mail.gmail.com>
	<D904AF28-B0A8-49B0-A0D5-7D1E9FD927F0@vmware.com>
	<CAP7YuASNC=oe8itChwyZo0V6O-A9drfaNc-897B-9Hsq7Yd0Lw@mail.gmail.com>
	<7E9CBC0C-43C4-48F0-813D-CE91C6697656@vmware.com>
Message-ID: <CAP7YuASiUqjdvvFPY662WtwXXSfZbPR1xZo6LUuqxn-LTHC0rg@mail.gmail.com>

Hmm, you're right, not sure what you can do in that case.  My Java 8 builds
are from source so I haven't run across your use case :-(

Cheers,
Martijn


On 7 March 2013 18:06, Oliver Gierke <ogierke at vmware.com> wrote:

> Tar files for Mac OS? Currently the download page [0] only lists the DMG
> containing the installer that refuses the install.
>
> Cheers,
> Ollie
>
> [0]
> http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html
>
> Am 06.03.2013 um 16:16 schrieb Martijn Verburg <martijnverburg at gmail.com>:
>
> > Hi Oliver,
> >
> > Yes this has been discussed in the past.  For us power users I believe
> that downloading and installing the tar archives works fine.  Can't
> remember what the official line was regarding supporting multiple versions.
> >
> > Cheers,
> > Martijn
> >
> >
> > On 6 March 2013 11:07, Oliver Gierke <ogierke at vmware.com> wrote:
> > Of course:
> >
> > $ java -version
> > openjdk version "1.8.0-ea"
> > OpenJDK Runtime Environment (build
> 1.8.0-ea-lambda-nightly-h3207-20130205-b76-b00)
> > OpenJDK 64-Bit Server VM (build 25.0-b15, mixed mode)
> >
> > $ java -version
> > java version "1.7.0_15"
> > Java(TM) SE Runtime Environment (build 1.7.0_15-b03)
> > Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
> >
> > To be precise: I installed Java 8 *after* I had Java 7 of course. It
> seems that the updater now checks for the most recent version and assumes I
> don't want to use 7 if I already have 8, which is a bit of a stretch.
> >
> > It generally seems that Oracle is trying to push installations into a
> "single Java version only" (by explicitly removing Java 6). This is a quite
> unbearable situation especially for developers that *have* to build with
> older versions of a JDK.
> >
> > Cheers,
> > Ollie
> >
> > Am 06.03.2013 um 11:43 schrieb Ben Evans <benjamin.john.evans at gmail.com
> >:
> >
> > > Oliver,
> > >
> > > Can you post the exact versions and natures of each build?
> > >
> > > I can confirm that on Lion, I have multiple 8's - both ORCL & OpenJDK
> > > / Lambda as well as latest 7.
> > >
> > > Thanks,
> > >
> > > Ben
> > >
> > > On Wed, Mar 6, 2013 at 10:28 AM, Oliver Gierke <ogierke at vmware.com>
> wrote:
> > >> Hi all,
> > >>
> > >> I am unable to install the latest JDK7 update on a Mac (Mountain
> Lion). The installer immediately quits with "Higher version already
> installed!". Trying to report this as bug through the bug tracker I was
> directed to a page saying "If you have encountered a bug in a JRE not
> released by Oracle, please contact the specific vendor about your bug."
> This is probably not really up to date anymore as well.
> > >>
> > >> Cheers,
> > >> Ollie
> > >>
> > >> --
> > >> /**
> > >> * @author Oliver Gierke - Senior Member Technical Staff
> > >> *
> > >> * @param email ogierke at vmware.com
> > >> * @param phone +49-151-50465477
> > >> * @param fax   +49-351-418898439
> > >> * @param skype einsdreizehn
> > >> * @see http://www.olivergierke.de
> > >> */
> >
> > --
> > /**
> >  * @author Oliver Gierke - Senior Member Technical Staff
> >  *
> >  * @param email ogierke at vmware.com
> >  * @param phone +49-151-50465477
> >  * @param fax   +49-351-418898439
> >  * @param skype einsdreizehn
> >  * @see http://www.olivergierke.de
> >  */
> >
>
> --
> /**
>  * @author Oliver Gierke - Senior Member Technical Staff
>  *
>  * @param email ogierke at vmware.com
>  * @param phone +49-151-50465477
>  * @param fax   +49-351-418898439
>  * @param skype einsdreizehn
>  * @see http://www.olivergierke.de
>  */
>


From dalibor.topic at oracle.com  Fri Mar  8 11:12:31 2013
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Fri, 08 Mar 2013 12:12:31 +0100
Subject: Cannot install JDK7 update on machine with JDK8 EA installed
In-Reply-To: <7E9CBC0C-43C4-48F0-813D-CE91C6697656@vmware.com>
References: <A0A0C21B-E9CE-417A-B48D-D24D6AACA157@vmware.com>
	<CABKW8RgOZZQBmTVCBF1P_ms26FKG8yMAdR1MGky+b==w6_Bu9w@mail.gmail.com>
	<D904AF28-B0A8-49B0-A0D5-7D1E9FD927F0@vmware.com>
	<CAP7YuASNC=oe8itChwyZo0V6O-A9drfaNc-897B-9Hsq7Yd0Lw@mail.gmail.com>
	<7E9CBC0C-43C4-48F0-813D-CE91C6697656@vmware.com>
Message-ID: <5139C79F.1040906@oracle.com>

On 3/7/13 7:06 PM, Oliver Gierke wrote:
> Tar files for Mac OS? Currently the download page [0] only lists the DMG containing the installer that refuses the install.

The Java? Platform, Standard Edition 8 Early Access with Lambda Support download for OS X is a tarball: http://jdk8.java.net/lambda/ 

Is that the one you installed?

cheers,
dalibor topic

> 
> Cheers,
> Ollie
> 
> [0] http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html
> 
> Am 06.03.2013 um 16:16 schrieb Martijn Verburg <martijnverburg at gmail.com>:
> 
>> Hi Oliver,
>>
>> Yes this has been discussed in the past.  For us power users I believe that downloading and installing the tar archives works fine.  Can't remember what the official line was regarding supporting multiple versions.
>>
>> Cheers,
>> Martijn
>>
>>
>> On 6 March 2013 11:07, Oliver Gierke <ogierke at vmware.com> wrote:
>> Of course:
>>
>> $ java -version
>> openjdk version "1.8.0-ea"
>> OpenJDK Runtime Environment (build 1.8.0-ea-lambda-nightly-h3207-20130205-b76-b00)
>> OpenJDK 64-Bit Server VM (build 25.0-b15, mixed mode)
>>
>> $ java -version
>> java version "1.7.0_15"
>> Java(TM) SE Runtime Environment (build 1.7.0_15-b03)
>> Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
>>
>> To be precise: I installed Java 8 *after* I had Java 7 of course. It seems that the updater now checks for the most recent version and assumes I don't want to use 7 if I already have 8, which is a bit of a stretch.
>>
>> It generally seems that Oracle is trying to push installations into a "single Java version only" (by explicitly removing Java 6). This is a quite unbearable situation especially for developers that *have* to build with older versions of a JDK.
>>
>> Cheers,
>> Ollie
>>
>> Am 06.03.2013 um 11:43 schrieb Ben Evans <benjamin.john.evans at gmail.com>:
>>
>>> Oliver,
>>>
>>> Can you post the exact versions and natures of each build?
>>>
>>> I can confirm that on Lion, I have multiple 8's - both ORCL & OpenJDK
>>> / Lambda as well as latest 7.
>>>
>>> Thanks,
>>>
>>> Ben
>>>
>>> On Wed, Mar 6, 2013 at 10:28 AM, Oliver Gierke <ogierke at vmware.com> wrote:
>>>> Hi all,
>>>>
>>>> I am unable to install the latest JDK7 update on a Mac (Mountain Lion). The installer immediately quits with "Higher version already installed!". Trying to report this as bug through the bug tracker I was directed to a page saying "If you have encountered a bug in a JRE not released by Oracle, please contact the specific vendor about your bug." This is probably not really up to date anymore as well.
>>>>
>>>> Cheers,
>>>> Ollie
>>>>
>>>> --
>>>> /**
>>>> * @author Oliver Gierke - Senior Member Technical Staff
>>>> *
>>>> * @param email ogierke at vmware.com
>>>> * @param phone +49-151-50465477
>>>> * @param fax   +49-351-418898439
>>>> * @param skype einsdreizehn
>>>> * @see http://www.olivergierke.de
>>>> */
>>
>> --
>> /**
>>  * @author Oliver Gierke - Senior Member Technical Staff
>>  *
>>  * @param email ogierke at vmware.com
>>  * @param phone +49-151-50465477
>>  * @param fax   +49-351-418898439
>>  * @param skype einsdreizehn
>>  * @see http://www.olivergierke.de
>>  */
>>
> 



-- 
Oracle <http://www.oracle.com>
Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961 <tel:+491737185961>
Oracle Java Platform Group

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Gesch?ftsf?hrer: J?rgen Kunz

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment


From dalibor.topic at oracle.com  Fri Mar  8 11:36:14 2013
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Fri, 08 Mar 2013 12:36:14 +0100
Subject: Cannot install JDK7 update on machine with JDK8 EA installed
In-Reply-To: <5139C79F.1040906@oracle.com>
References: <A0A0C21B-E9CE-417A-B48D-D24D6AACA157@vmware.com>
	<CABKW8RgOZZQBmTVCBF1P_ms26FKG8yMAdR1MGky+b==w6_Bu9w@mail.gmail.com>
	<D904AF28-B0A8-49B0-A0D5-7D1E9FD927F0@vmware.com>
	<CAP7YuASNC=oe8itChwyZo0V6O-A9drfaNc-897B-9Hsq7Yd0Lw@mail.gmail.com>
	<7E9CBC0C-43C4-48F0-813D-CE91C6697656@vmware.com>
	<5139C79F.1040906@oracle.com>
Message-ID: <5139CD2E.7040805@oracle.com>

On 3/8/13 12:12 PM, Dalibor Topic wrote:
> On 3/7/13 7:06 PM, Oliver Gierke wrote:
>> Tar files for Mac OS? Currently the download page [0] only lists the DMG containing the installer that refuses the install.
> 
> The Java? Platform, Standard Edition 8 Early Access with Lambda Support download for OS X is a tarball: http://jdk8.java.net/lambda/ 
> 
> Is that the one you installed?

I've tried reproducing this using the JDK (rather then JRE) downloads for 7u15, 8ea-b79, and 7u17 and couldn't - the JDKs all installed fine into /Library/Java/JavaVirtualMachines/jdk1* on 10.7. 

Can you provide a step-by-step guide to trigger the issue with URLs, describing whether you installed JRE or JDK on each step?

cheers,
dalibor topic


-- 
Oracle <http://www.oracle.com>
Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961 <tel:+491737185961>
Oracle Java Platform Group

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Gesch?ftsf?hrer: J?rgen Kunz

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment


From ogierke at vmware.com  Fri Mar  8 20:33:06 2013
From: ogierke at vmware.com (Oliver Gierke)
Date: Fri, 8 Mar 2013 21:33:06 +0100
Subject: Cannot install JDK7 update on machine with JDK8 EA 	installed
In-Reply-To: <mailman.29.1362772802.2036.discuss@openjdk.java.net>
References: <mailman.29.1362772802.2036.discuss@openjdk.java.net>
Message-ID: <2E7D945F-9719-4BE4-99F8-39D48C7CDF02@vmware.com>

I installed JDK8 preview installer (Build 76) from this location: http://jdk8.java.net/download.html (actual links hidden behind some JavaScript, the current version is B80). I then realized that build 76 != lambda build 76, grabbed the lambda TAR ball (also B76) and replaced the contents at the location the default B76 installer had put Java 8.

Here are a few other things that keep me puzzled:

This page (http://www.oracle.com/technetwork/java/javase/downloads/java-se-jdk-7-download-432154.html) points me to a different page (http://jdk7.java.net/macportpreview/) for a JDK 7 download. This page in turn only lists 7u12. Neither a 7u15 nor 7u17 you mentioned. Where did you get those from?

Cheers,
Ollie

Am 08.03.2013 um 21:00 schrieb discuss-request at openjdk.java.net:

> Date: Fri, 08 Mar 2013 12:36:14 +0100
> From: Dalibor Topic <dalibor.topic at oracle.com>
> Subject: Re: Cannot install JDK7 update on machine with JDK8 EA
> 	installed
> To: discuss at openjdk.java.net
> Message-ID: <5139CD2E.7040805 at oracle.com>
> Content-Type: text/plain; charset=windows-1252
> 
> On 3/8/13 12:12 PM, Dalibor Topic wrote:
>> On 3/7/13 7:06 PM, Oliver Gierke wrote:
>>> Tar files for Mac OS? Currently the download page [0] only lists the DMG containing the installer that refuses the install.
>> 
>> The Java? Platform, Standard Edition 8 Early Access with Lambda Support download for OS X is a tarball: http://jdk8.java.net/lambda/ 
>> 
>> Is that the one you installed?
> 
> I've tried reproducing this using the JDK (rather then JRE) downloads for 7u15, 8ea-b79, and 7u17 and couldn't - the JDKs all installed fine into /Library/Java/JavaVirtualMachines/jdk1* on 10.7. 
> 
> Can you provide a step-by-step guide to trigger the issue with URLs, describing whether you installed JRE or JDK on each step?
> 
> cheers,
> dalibor topic

-- 
/**
 * @author Oliver Gierke - Senior Member Technical Staff
 *
 * @param email ogierke at vmware.com
 * @param phone +49-151-50465477
 * @param fax   +49-351-418898439
 * @param skype einsdreizehn
 * @see http://www.olivergierke.de
 */


From dalibor.topic at oracle.com  Fri Mar  8 20:44:26 2013
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Fri, 08 Mar 2013 21:44:26 +0100
Subject: Cannot install JDK7 update on machine with JDK8 EA 	installed
In-Reply-To: <2E7D945F-9719-4BE4-99F8-39D48C7CDF02@vmware.com>
References: <mailman.29.1362772802.2036.discuss@openjdk.java.net>
	<2E7D945F-9719-4BE4-99F8-39D48C7CDF02@vmware.com>
Message-ID: <513A4DAA.9060206@oracle.com>

On 3/8/13 9:33 PM, Oliver Gierke wrote:
> I installed JDK8 preview installer (Build 76) from this location: http://jdk8.java.net/download.html (actual links hidden behind some JavaScript, the current version is B80). I then realized that build 76 != lambda build 76, grabbed the lambda TAR ball (also B76) and replaced the contents at the location the default B76 installer had put Java 8.
> 
> Here are a few other things that keep me puzzled:
> 
> This page (http://www.oracle.com/technetwork/java/javase/downloads/java-se-jdk-7-download-432154.html) points me to a different page (http://jdk7.java.net/macportpreview/) for a JDK 7 download. This page in turn only lists 7u12. Neither a 7u15 nor 7u17 you mentioned. Where did you get those from?

Thanks, I'll look into that. 

Meanwhile - You can download JDK 7u17 from http://www.oracle.com/technetwork/java/javase/downloads/index.html
and if you still have to, find JDK 7u15 in the archive at http://www.oracle.com/technetwork/java/javase/archive-139210.html

cheers,
dalibor topic

-- 
Oracle <http://www.oracle.com>
Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961 <tel:+491737185961>
Oracle Java Platform Group

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Gesch?ftsf?hrer: J?rgen Kunz

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment


From frans at meruvian.org  Sat Mar  9 13:37:33 2013
From: frans at meruvian.org (Frans Thamura)
Date: Sat, 9 Mar 2013 20:37:33 +0700
Subject: Openjdk 6 future by redhat
Message-ID: <CAOeeQyoYWJQaPhk39H83ZwetGsvYX1JVQajPc7dKp2wU+zqwRg@mail.gmail.com>

Anyone read this?

How the ecosystem between openjdk.java.net and redhat's commitment..

http://m.infoworld.com/t/java-programming/red-hats-java-leadership-grows-oracles-wanes-214137?mm_ref=http%3A%2F%2Fm.facebook.com%2Fl.php%3Fu%3Dhttp%253A%252F%252Fwww.infoworld.com%252Ft%252Fjava-programming%252Fred-hats-java-leadership-grows-oracles-wanes-214137%26h%3DMAQFIs7pQOJQXn0qMAAA%26s%3D1

Frans Thamura
Meruvian
Integrated Hypermedia Solution Provider


From martijnverburg at gmail.com  Sat Mar  9 15:31:37 2013
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sat, 9 Mar 2013 15:31:37 +0000
Subject: [jc-user] Openjdk 6 future by redhat
In-Reply-To: <CAOeeQyoYWJQaPhk39H83ZwetGsvYX1JVQajPc7dKp2wU+zqwRg@mail.gmail.com>
References: <CAOeeQyoYWJQaPhk39H83ZwetGsvYX1JVQajPc7dKp2wU+zqwRg@mail.gmail.com>
Message-ID: <CAP7YuASio=aQj_1p-amB9EO7Yv=FSDE=ETFrVMQzR71N0sdYzA@mail.gmail.com>

Yep was sort of in officially announced at FOSDEM iirc - nothing wrong with
it <shrug>

On Saturday, 9 March 2013, Frans Thamura wrote:

> Anyone read this?
>
> How the ecosystem between openjdk.java.net and redhat's commitment..
>
>
> http://m.infoworld.com/t/java-programming/red-hats-java-leadership-grows-oracles-wanes-214137?mm_ref=http%3A%2F%2Fm.facebook.com%2Fl.php%3Fu%3Dhttp%253A%252F%252Fwww.infoworld.com%252Ft%252Fjava-programming%252Fred-hats-java-leadership-grows-oracles-wanes-214137%26h%3DMAQFIs7pQOJQXn0qMAAA%26s%3D1
>
> Frans Thamura
> Meruvian
> Integrated Hypermedia Solution Provider
>


-- 
Cheers,
Martijn


From frans at meruvian.org  Sat Mar  9 15:47:54 2013
From: frans at meruvian.org (Frans Thamura)
Date: Sat, 9 Mar 2013 22:47:54 +0700
Subject: [jc-user] Re: Openjdk 6 future by redhat
In-Reply-To: <CAP7YuASio=aQj_1p-amB9EO7Yv=FSDE=ETFrVMQzR71N0sdYzA@mail.gmail.com>
References: <CAOeeQyoYWJQaPhk39H83ZwetGsvYX1JVQajPc7dKp2wU+zqwRg@mail.gmail.com>
	<CAP7YuASio=aQj_1p-amB9EO7Yv=FSDE=ETFrVMQzR71N0sdYzA@mail.gmail.com>
Message-ID: <CAOeeQyoBbAi1gj9+wQU_zgeMB1TGX6X8Apgn7qUjfuS2e=1H-g@mail.gmail.com>

hi martjin

wanna to know more about how the patch managed in the
openjdk.java.net, will we use the same repository, or we will use
another svn or github outside openjdk

what will oracle response for this?

On Sat, Mar 9, 2013 at 10:31 PM, Martijn Verburg
<martijnverburg at gmail.com> wrote:
> Yep was sort of in officially announced at FOSDEM iirc - nothing wrong with
> it <shrug>
>
>
> On Saturday, 9 March 2013, Frans Thamura wrote:
>>
>> Anyone read this?
>>
>> How the ecosystem between openjdk.java.net and redhat's commitment..
>>
>>
>> http://m.infoworld.com/t/java-programming/red-hats-java-leadership-grows-oracles-wanes-214137?mm_ref=http%3A%2F%2Fm.facebook.com%2Fl.php%3Fu%3Dhttp%253A%252F%252Fwww.infoworld.com%252Ft%252Fjava-programming%252Fred-hats-java-leadership-grows-oracles-wanes-214137%26h%3DMAQFIs7pQOJQXn0qMAAA%26s%3D1
>>
>> Frans Thamura
>> Meruvian
>> Integrated Hypermedia Solution Provider
>
>
>
> --
> Cheers,
> Martijn


From simon at webmink.com  Sat Mar  9 16:26:02 2013
From: simon at webmink.com (Simon Phipps)
Date: Sat, 9 Mar 2013 16:26:02 +0000
Subject: [jc-user] Openjdk 6 future by redhat
In-Reply-To: <CAP7YuASio=aQj_1p-amB9EO7Yv=FSDE=ETFrVMQzR71N0sdYzA@mail.gmail.com>
References: <CAOeeQyoYWJQaPhk39H83ZwetGsvYX1JVQajPc7dKp2wU+zqwRg@mail.gmail.com>
	<CAP7YuASio=aQj_1p-amB9EO7Yv=FSDE=ETFrVMQzR71N0sdYzA@mail.gmail.com>
Message-ID: <CAA4ffp_sZ41PPBSzNr-LttMYHaA9ooGtx-+9-vm_w-VX7xb2_A@mail.gmail.com>

Indeed, I've been waiting since then to write about it. FWIW the headline &
abstract are written by sub-editors and aren't of my choosing. As a result
they often reflect a nuance I don't actually share.

S.


On Sat, Mar 9, 2013 at 3:31 PM, Martijn Verburg <martijnverburg at gmail.com>wrote:

> Yep was sort of in officially announced at FOSDEM iirc - nothing wrong with
> it <shrug>
>
> On Saturday, 9 March 2013, Frans Thamura wrote:
>
> > Anyone read this?
> >
> > How the ecosystem between openjdk.java.net and redhat's commitment..
> >
> >
> >
> http://m.infoworld.com/t/java-programming/red-hats-java-leadership-grows-oracles-wanes-214137?mm_ref=http%3A%2F%2Fm.facebook.com%2Fl.php%3Fu%3Dhttp%253A%252F%252Fwww.infoworld.com%252Ft%252Fjava-programming%252Fred-hats-java-leadership-grows-oracles-wanes-214137%26h%3DMAQFIs7pQOJQXn0qMAAA%26s%3D1
> >
> > Frans Thamura
> > Meruvian
> > Integrated Hypermedia Solution Provider
> >
>
>
> --
> Cheers,
> Martijn
>



-- 
*Simon Phipps*  http://webmink.com
*Meshed Insights & Knowledge *
*Office:* +1 (415) 683-7660 *or* +44 (238) 098 7027
*Mobile*:  +44 774 776 2816*
*


From martijnverburg at gmail.com  Sat Mar  9 18:12:29 2013
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sat, 9 Mar 2013 18:12:29 +0000
Subject: [jc-user] Re: Openjdk 6 future by redhat
In-Reply-To: <F397C82E-69E0-44D7-86FF-C04D848A0F0A@javaman.com.br>
References: <CAOeeQyoYWJQaPhk39H83ZwetGsvYX1JVQajPc7dKp2wU+zqwRg@mail.gmail.com>
	<CAP7YuASio=aQj_1p-amB9EO7Yv=FSDE=ETFrVMQzR71N0sdYzA@mail.gmail.com>
	<F397C82E-69E0-44D7-86FF-C04D848A0F0A@javaman.com.br>
Message-ID: <CAP7YuATb6fbd-HgCF2WTxp0ehDw3OTo84YnBMM_gznhNk8AF_Q@mail.gmail.com>

+1 - well put Bruno.

Cheers,
Martijn


On 9 March 2013 17:13, Bruno F. Souza <bruno at javaman.com.br> wrote:

>
> On 09/03/2013, at 12:31, Martijn Verburg <martijnverburg at gmail.com> wrote:
>
> Yep was sort of in officially announced at FOSDEM iirc - nothing wrong
> with it <shrug>
>
>
> Even more then that, I think this is a wonderful thing!
> RedHat has been an active participant on the OpenJDK project for a long
> time, and the
> more responsibility other participants get the better off the project is.
>
> I totally agree with RedHat's stance that an open source project is not
> simply abandoned,
> those that feel the need that the project keep going should jump in and
> make sure the
> project is continued. And note that this is not a bash on Oracle: the
> beauty of open
> source is that different people have different goals and objectives. It is
> AMAZING
> that OpenJDK has evolved to the point where this can actually happen.
>
> Recently we saw a similar move with the Play framework, where a group of
> people
> decided that Play 1 was still a worthwhile framework, and basically
> continued the
> development of that version, although most of the developers have moved on
> to
> Play 2. This is how open source is supposed to work!
>
> So, this is open source at it's finest, and I'm extremely excited to see
> this happening
> on OpenJDK. Great sign and congratulations to RedHat for taking this
> responsibility,
> the Java community will be better because of it. And, my thanks go also to
> Oracle
> for creating a real open source project where this kind of thing can
> actually happen!
>
> Bruno.
>
>
> On Saturday, 9 March 2013, Frans Thamura wrote:
>
>> Anyone read this?
>>
>> How the ecosystem between openjdk.java.net and redhat's commitment..
>>
>>
>> http://m.infoworld.com/t/java-programming/red-hats-java-leadership-grows-oracles-wanes-214137?mm_ref=http%3A%2F%2Fm.facebook.com%2Fl.php%3Fu%3Dhttp%253A%252F%252Fwww.infoworld.com%252Ft%252Fjava-programming%252Fred-hats-java-leadership-grows-oracles-wanes-214137%26h%3DMAQFIs7pQOJQXn0qMAAA%26s%3D1
>>
>> Frans Thamura
>> Meruvian
>> Integrated Hypermedia Solution Provider
>>
>
>
> --
> Cheers,
> Martijn
>
>
> Bruno.
> ______________________________________________________________________
> Bruno Peres Ferreira de Souza                         Brazil's JavaMan
> http://www.javaman.com.br                      bruno at javaman.com.br
>         if I fail, if I succeed, at least I live as I believe
>
>
>
>


From donald.smith at oracle.com  Sat Mar  9 18:48:26 2013
From: donald.smith at oracle.com (Donald Smith)
Date: Sat, 09 Mar 2013 13:48:26 -0500
Subject: [jc-user] Re: Openjdk 6 future by redhat
In-Reply-To: <CAP7YuASio=aQj_1p-amB9EO7Yv=FSDE=ETFrVMQzR71N0sdYzA@mail.gmail.com>
References: <CAOeeQyoYWJQaPhk39H83ZwetGsvYX1JVQajPc7dKp2wU+zqwRg@mail.gmail.com>
	<CAP7YuASio=aQj_1p-amB9EO7Yv=FSDE=ETFrVMQzR71N0sdYzA@mail.gmail.com>
Message-ID: <513B83FA.9040209@oracle.com>

To be more precise, it was announced at FOSDEM in /2011/ by Joe Darcy as 
part of a "The State of OpenJDK 6" talk [1].  Anyone reading the 
jdk6-dev mail list would have noticed APH of RH take over leadership of 
the project a couple months ago.

[1] - 
https://blogs.oracle.com/darcy/resource/FOSDEM/FOSDEM-2011-OpenJDK6.pdf
/
  - Don

/
On 09/03/2013 10:31 AM, Martijn Verburg wrote:
> Yep was sort of in officially announced at FOSDEM iirc - nothing wrong 
> with it <shrug>



From donald.smith at oracle.com  Sat Mar  9 18:49:11 2013
From: donald.smith at oracle.com (Donald Smith)
Date: Sat, 09 Mar 2013 13:49:11 -0500
Subject: [jc-user] Re: Openjdk 6 future by redhat
In-Reply-To: <513B83FA.9040209@oracle.com>
References: <CAOeeQyoYWJQaPhk39H83ZwetGsvYX1JVQajPc7dKp2wU+zqwRg@mail.gmail.com>
	<CAP7YuASio=aQj_1p-amB9EO7Yv=FSDE=ETFrVMQzR71N0sdYzA@mail.gmail.com>
	<513B83FA.9040209@oracle.com>
Message-ID: <513B8427.6060303@oracle.com>


On 09/03/2013 1:48 PM, Donald Smith wrote:
> To be more precise, it was announced at FOSDEM in /2011/ by Joe Darcy 
> as part of a "The State of OpenJDK 6" talk [1].  Anyone reading the 
> jdk6-dev mail list would have noticed APH of RH take over leadership 
> of the project a couple months ago.
>
> [1] - 
> https://blogs.oracle.com/darcy/resource/FOSDEM/FOSDEM-2011-OpenJDK6.pdf
> /
>  - Don
>
> /
> On 09/03/2013 10:31 AM, Martijn Verburg wrote:
>> Yep was sort of in officially announced at FOSDEM iirc - nothing 
>> wrong with it <shrug>
>



From fcassia at gmail.com  Sun Mar 10 02:18:33 2013
From: fcassia at gmail.com (Fernando Cassia)
Date: Sat, 9 Mar 2013 23:18:33 -0300
Subject: Openjdk 6 future by redhat
In-Reply-To: <CACGw4H6M-jwS4G1CHeguaxufgOdgDc-giL3M-G27Od6PD2YMVw@mail.gmail.com>
References: <CAOeeQyoYWJQaPhk39H83ZwetGsvYX1JVQajPc7dKp2wU+zqwRg@mail.gmail.com>
	<CACGw4H6M-jwS4G1CHeguaxufgOdgDc-giL3M-G27Od6PD2YMVw@mail.gmail.com>
Message-ID: <CACGw4H5-V9PFaV_YtBYOnRNwavJFc-b4kRgKHL+Ocyn1toFG9Q@mail.gmail.com>

On Sat, Mar 9, 2013 at 3:32 PM, Fernando Cassia <fcassia at gmail.com> wrote:
> Maybe that article will serve a purpose: to be mirrored on all of
> IDG?s pubs and then someone else on ZDNet will copy-paste and write
> some disaster headline about how Oracle is mismanaging Java and how
> someone else or ?the community? is saving it.
>
> Only one problem though, it?s a lie:
> --
>
> Oracle has been good to Java, despite early fears
> http://www.infoworld.com/t/java-programming/oracle-has-been-good-java-despite-early-fears-200200

Well, as I predicted, it has already happened. Here we see
Brian Proffitt, Community Marketing Manager for SUSE, sprouting on twitter

"Since Oracle can't take care of Java, let's see what RHT and IBM can
do with OpenJDK. "

https://twitter.com/TheTechScribe/status/310076245117374464

Oh, the FUD masters, I know them and their ways... let the FUD games begin...
Sheesh...

FC
-- 
During times of Universal Deceit, telling the truth becomes a revolutionary act
- George Orwell


From frans at meruvian.org  Sun Mar 10 02:31:27 2013
From: frans at meruvian.org (Frans Thamura)
Date: Sun, 10 Mar 2013 09:31:27 +0700
Subject: Openjdk 6 future by redhat
In-Reply-To: <CACGw4H5-V9PFaV_YtBYOnRNwavJFc-b4kRgKHL+Ocyn1toFG9Q@mail.gmail.com>
References: <CAOeeQyoYWJQaPhk39H83ZwetGsvYX1JVQajPc7dKp2wU+zqwRg@mail.gmail.com>
	<CACGw4H6M-jwS4G1CHeguaxufgOdgDc-giL3M-G27Od6PD2YMVw@mail.gmail.com>
	<CACGw4H5-V9PFaV_YtBYOnRNwavJFc-b4kRgKHL+Ocyn1toFG9Q@mail.gmail.com>
Message-ID: <CAOeeQypAWg9CzHAunrp+FCqSzNcrUgR=0zg4=Pv6B6u=JvXt-Q@mail.gmail.com>

i believe as part of the ecosystem and this is not FUD, this is great work.

oracle way is one of the model, which oracle design

and i believe this will make a better sustain ecossytem in openjdk

our member in JUG said, the ecosystem will stop in one project, if the
last person that use , stop maintain it.. so oracle cant push to stop
openjdk6, and we will see when will the last openjdk deployment exist
with this ecosystem

but i still want to know, where is this patch team work, in this
mailinglist or outside this mailing list.

F

On Sun, Mar 10, 2013 at 9:18 AM, Fernando Cassia <fcassia at gmail.com> wrote:
> On Sat, Mar 9, 2013 at 3:32 PM, Fernando Cassia <fcassia at gmail.com> wrote:
>> Maybe that article will serve a purpose: to be mirrored on all of
>> IDG?s pubs and then someone else on ZDNet will copy-paste and write
>> some disaster headline about how Oracle is mismanaging Java and how
>> someone else or ?the community? is saving it.
>>
>> Only one problem though, it?s a lie:
>> --
>>
>> Oracle has been good to Java, despite early fears
>> http://www.infoworld.com/t/java-programming/oracle-has-been-good-java-despite-early-fears-200200
>
> Well, as I predicted, it has already happened. Here we see
> Brian Proffitt, Community Marketing Manager for SUSE, sprouting on twitter
>
> "Since Oracle can't take care of Java, let's see what RHT and IBM can
> do with OpenJDK. "
>
> https://twitter.com/TheTechScribe/status/310076245117374464
>
> Oh, the FUD masters, I know them and their ways... let the FUD games begin...
> Sheesh...
>
> FC
> --
> During times of Universal Deceit, telling the truth becomes a revolutionary act
> - George Orwell


From frans at meruvian.org  Sun Mar 10 03:15:59 2013
From: frans at meruvian.org (Frans Thamura)
Date: Sun, 10 Mar 2013 10:15:59 +0700
Subject: [jc-user] Re: Openjdk 6 future by redhat
In-Reply-To: <F397C82E-69E0-44D7-86FF-C04D848A0F0A@javaman.com.br>
References: <CAOeeQyoYWJQaPhk39H83ZwetGsvYX1JVQajPc7dKp2wU+zqwRg@mail.gmail.com>
	<CAP7YuASio=aQj_1p-amB9EO7Yv=FSDE=ETFrVMQzR71N0sdYzA@mail.gmail.com>
	<F397C82E-69E0-44D7-86FF-C04D848A0F0A@javaman.com.br>
Message-ID: <CAOeeQyqbm=ecwy0xyJ55f0nitjCuD4Z3YJGKht2xkak2Fkq2nQ@mail.gmail.com>

+1

so this news will relax several people that still use J6 in their
environment. -> several my clients always asking and "busy" is their
answer to upgrade, and still untrust with j7 for their deployment,
yes, a reflect of IBM salesman here, that said we are testing bla bla
bla...

F


On Sun, Mar 10, 2013 at 12:13 AM, Bruno F. Souza <bruno at javaman.com.br> wrote:
>
> On 09/03/2013, at 12:31, Martijn Verburg <martijnverburg at gmail.com> wrote:
>
> Yep was sort of in officially announced at FOSDEM iirc - nothing wrong with
> it <shrug>
>
>
> Even more then that, I think this is a wonderful thing!
> RedHat has been an active participant on the OpenJDK project for a long
> time, and the
> more responsibility other participants get the better off the project is.
>
> I totally agree with RedHat's stance that an open source project is not
> simply abandoned,
> those that feel the need that the project keep going should jump in and make
> sure the
> project is continued. And note that this is not a bash on Oracle: the beauty
> of open
> source is that different people have different goals and objectives. It is
> AMAZING
> that OpenJDK has evolved to the point where this can actually happen.
>
> Recently we saw a similar move with the Play framework, where a group of
> people
> decided that Play 1 was still a worthwhile framework, and basically
> continued the
> development of that version, although most of the developers have moved on
> to
> Play 2. This is how open source is supposed to work!
>
> So, this is open source at it's finest, and I'm extremely excited to see
> this happening
> on OpenJDK. Great sign and congratulations to RedHat for taking this
> responsibility,
> the Java community will be better because of it. And, my thanks go also to
> Oracle
> for creating a real open source project where this kind of thing can
> actually happen!
>
> Bruno.
>
>
> On Saturday, 9 March 2013, Frans Thamura wrote:
>>
>> Anyone read this?
>>
>> How the ecosystem between openjdk.java.net and redhat's commitment..
>>
>>
>> http://m.infoworld.com/t/java-programming/red-hats-java-leadership-grows-oracles-wanes-214137?mm_ref=http%3A%2F%2Fm.facebook.com%2Fl.php%3Fu%3Dhttp%253A%252F%252Fwww.infoworld.com%252Ft%252Fjava-programming%252Fred-hats-java-leadership-grows-oracles-wanes-214137%26h%3DMAQFIs7pQOJQXn0qMAAA%26s%3D1
>>
>> Frans Thamura
>> Meruvian
>> Integrated Hypermedia Solution Provider
>
>
>
> --
> Cheers,
> Martijn
>
>
> Bruno.
> ______________________________________________________________________
> Bruno Peres Ferreira de Souza                         Brazil's JavaMan
> http://www.javaman.com.br                      bruno at javaman.com.br
>         if I fail, if I succeed, at least I live as I believe
>
>
>


From donald.smith at oracle.com  Sun Mar 10 16:56:23 2013
From: donald.smith at oracle.com (Donald Smith)
Date: Sun, 10 Mar 2013 12:56:23 -0400
Subject: Openjdk 6 future by redhat
In-Reply-To: <CACGw4H5-V9PFaV_YtBYOnRNwavJFc-b4kRgKHL+Ocyn1toFG9Q@mail.gmail.com>
References: <CAOeeQyoYWJQaPhk39H83ZwetGsvYX1JVQajPc7dKp2wU+zqwRg@mail.gmail.com>
	<CACGw4H6M-jwS4G1CHeguaxufgOdgDc-giL3M-G27Od6PD2YMVw@mail.gmail.com>
	<CACGw4H5-V9PFaV_YtBYOnRNwavJFc-b4kRgKHL+Ocyn1toFG9Q@mail.gmail.com>
Message-ID: <513CBB37.8060902@oracle.com>

For what it's worth, the people at SUSE I worked with last year (with 
respect to them getting the TCK for OpenJDK 7) were smart, reasonable 
people.  I wouldn't put too much negative stock towards SUSE on one 
misunderstood tweet.

  - Don


On 09/03/2013 9:18 PM, Fernando Cassia wrote:
> Oh, the FUD masters, I know them and their ways... let the FUD games begin...
> Sheesh...



From dalibor.topic at oracle.com  Mon Mar 11 11:47:30 2013
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Mon, 11 Mar 2013 12:47:30 +0100
Subject: Cannot install JDK7 update on machine with JDK8 EA 	installed
In-Reply-To: <513A4DAA.9060206@oracle.com>
References: <mailman.29.1362772802.2036.discuss@openjdk.java.net>
	<2E7D945F-9719-4BE4-99F8-39D48C7CDF02@vmware.com>
	<513A4DAA.9060206@oracle.com>
Message-ID: <513DC452.4090103@oracle.com>

On 3/8/13 9:44 PM, Dalibor Topic wrote:
> On 3/8/13 9:33 PM, Oliver Gierke wrote:
>> This page (http://www.oracle.com/technetwork/java/javase/downloads/java-se-jdk-7-download-432154.html) 

has been fixed. If you come across other outdated download pages, please send me an e-mail off-list.

cheers,
dalibor topic


-- 
Oracle <http://www.oracle.com>
Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961 <tel:+491737185961>
Oracle Java Platform Group

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Gesch?ftsf?hrer: J?rgen Kunz

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment


From aph at redhat.com  Mon Mar 11 11:56:25 2013
From: aph at redhat.com (Andrew Haley)
Date: Mon, 11 Mar 2013 11:56:25 +0000
Subject: [jc-user] Re: Openjdk 6 future by redhat
In-Reply-To: <CAOeeQyoBbAi1gj9+wQU_zgeMB1TGX6X8Apgn7qUjfuS2e=1H-g@mail.gmail.com>
References: <CAOeeQyoYWJQaPhk39H83ZwetGsvYX1JVQajPc7dKp2wU+zqwRg@mail.gmail.com>
	<CAP7YuASio=aQj_1p-amB9EO7Yv=FSDE=ETFrVMQzR71N0sdYzA@mail.gmail.com>
	<CAOeeQyoBbAi1gj9+wQU_zgeMB1TGX6X8Apgn7qUjfuS2e=1H-g@mail.gmail.com>
Message-ID: <513DC669.1000604@redhat.com>

On 03/09/2013 03:47 PM, Frans Thamura wrote:
> wanna to know more about how the patch managed in the
> openjdk.java.net, will we use the same repository, or we will use
> another svn or github outside openjdk

Nothing is going to change.  The only small difference is that we'll
be setting up a bug tracker at java.net because we can't use the one
at openjdk.java.net from outside Oracle.

Andrew.



From aph at redhat.com  Mon Mar 11 11:59:17 2013
From: aph at redhat.com (Andrew Haley)
Date: Mon, 11 Mar 2013 11:59:17 +0000
Subject: Openjdk 6 future by redhat
In-Reply-To: <CACGw4H5-V9PFaV_YtBYOnRNwavJFc-b4kRgKHL+Ocyn1toFG9Q@mail.gmail.com>
References: <CAOeeQyoYWJQaPhk39H83ZwetGsvYX1JVQajPc7dKp2wU+zqwRg@mail.gmail.com>
	<CACGw4H6M-jwS4G1CHeguaxufgOdgDc-giL3M-G27Od6PD2YMVw@mail.gmail.com>
	<CACGw4H5-V9PFaV_YtBYOnRNwavJFc-b4kRgKHL+Ocyn1toFG9Q@mail.gmail.com>
Message-ID: <513DC715.8040104@redhat.com>

On 03/10/2013 02:18 AM, Fernando Cassia wrote:
> On Sat, Mar 9, 2013 at 3:32 PM, Fernando Cassia <fcassia at gmail.com> wrote:
>> Maybe that article will serve a purpose: to be mirrored on all of
>> IDG?s pubs and then someone else on ZDNet will copy-paste and write
>> some disaster headline about how Oracle is mismanaging Java and how
>> someone else or ?the community? is saving it.
>>
>> Only one problem though, it?s a lie:
>> --
>>
>> Oracle has been good to Java, despite early fears
>> http://www.infoworld.com/t/java-programming/oracle-has-been-good-java-despite-early-fears-200200
> 
> Well, as I predicted, it has already happened. Here we see
> Brian Proffitt, Community Marketing Manager for SUSE, sprouting on twitter
> 
> "Since Oracle can't take care of Java, let's see what RHT and IBM can
> do with OpenJDK. "

Oh, Lord.  What a twonk.

Andrew.



From frans at meruvian.org  Mon Mar 11 12:32:20 2013
From: frans at meruvian.org (Frans Thamura)
Date: Mon, 11 Mar 2013 19:32:20 +0700
Subject: [jc-user] Re: Openjdk 6 future by redhat
In-Reply-To: <513DC669.1000604@redhat.com>
References: <CAOeeQyoYWJQaPhk39H83ZwetGsvYX1JVQajPc7dKp2wU+zqwRg@mail.gmail.com>
	<CAP7YuASio=aQj_1p-amB9EO7Yv=FSDE=ETFrVMQzR71N0sdYzA@mail.gmail.com>
	<CAOeeQyoBbAi1gj9+wQU_zgeMB1TGX6X8Apgn7qUjfuS2e=1H-g@mail.gmail.com>
	<513DC669.1000604@redhat.com>
Message-ID: <CAOeeQyqDXZkdCz0LcWGgEqvhk=9tjkuO-rsorSTsX1EKmMLJpA@mail.gmail.com>

Sad, if openjdk is an open source and dunno wanna to continue , why if
there are someone.wanna to continue, we cant use.it

Anyway, this initiative answer a lot of question , i believe a lot.

We are waiting your team start point.

F
On Mar 11, 2013 6:56 PM, "Andrew Haley" <aph at redhat.com> wrote:

> On 03/09/2013 03:47 PM, Frans Thamura wrote:
> > wanna to know more about how the patch managed in the
> > openjdk.java.net, will we use the same repository, or we will use
> > another svn or github outside openjdk
>
> Nothing is going to change.  The only small difference is that we'll
> be setting up a bug tracker at java.net because we can't use the one
> at openjdk.java.net from outside Oracle.
>
> Andrew.
>
>


From aph at redhat.com  Mon Mar 11 13:52:48 2013
From: aph at redhat.com (Andrew Haley)
Date: Mon, 11 Mar 2013 13:52:48 +0000
Subject: [jc-user] Re: Openjdk 6 future by redhat
In-Reply-To: <513B83FA.9040209@oracle.com>
References: <CAOeeQyoYWJQaPhk39H83ZwetGsvYX1JVQajPc7dKp2wU+zqwRg@mail.gmail.com>
	<CAP7YuASio=aQj_1p-amB9EO7Yv=FSDE=ETFrVMQzR71N0sdYzA@mail.gmail.com>
	<513B83FA.9040209@oracle.com>
Message-ID: <513DE1B0.60500@redhat.com>

On 03/09/2013 06:48 PM, Donald Smith wrote:
> To be more precise, it was announced at FOSDEM in /2011/ by Joe Darcy as 
> part of a "The State of OpenJDK 6" talk [1].

Not exactly: I'm pretty sure than in 2011 no-one had decided to continue
the OpenJDK 6 project.

Andrew.



From aph at redhat.com  Mon Mar 11 13:53:55 2013
From: aph at redhat.com (Andrew Haley)
Date: Mon, 11 Mar 2013 13:53:55 +0000
Subject: [jc-user] Openjdk 6 future by redhat
In-Reply-To: <CAA4ffp_sZ41PPBSzNr-LttMYHaA9ooGtx-+9-vm_w-VX7xb2_A@mail.gmail.com>
References: <CAOeeQyoYWJQaPhk39H83ZwetGsvYX1JVQajPc7dKp2wU+zqwRg@mail.gmail.com>
	<CAP7YuASio=aQj_1p-amB9EO7Yv=FSDE=ETFrVMQzR71N0sdYzA@mail.gmail.com>
	<CAA4ffp_sZ41PPBSzNr-LttMYHaA9ooGtx-+9-vm_w-VX7xb2_A@mail.gmail.com>
Message-ID: <513DE1F3.1090002@redhat.com>

On 03/09/2013 04:26 PM, Simon Phipps wrote:
> Indeed, I've been waiting since then to write about it. FWIW the headline &
> abstract are written by sub-editors and aren't of my choosing. As a result
> they often reflect a nuance I don't actually share.

Ah, that explains a great deal.  I did wonder why such a carefully
nuanced piece had an inflammatory headline

Thanks,
Andrew.



From johnyeary at gmail.com  Mon Mar 11 15:45:04 2013
From: johnyeary at gmail.com (John Yeary)
Date: Mon, 11 Mar 2013 11:45:04 -0400
Subject: [jc-user] Openjdk 6 future by redhat
In-Reply-To: <513DE1F3.1090002@redhat.com>
References: <CAOeeQyoYWJQaPhk39H83ZwetGsvYX1JVQajPc7dKp2wU+zqwRg@mail.gmail.com>
	<CAP7YuASio=aQj_1p-amB9EO7Yv=FSDE=ETFrVMQzR71N0sdYzA@mail.gmail.com>
	<CAA4ffp_sZ41PPBSzNr-LttMYHaA9ooGtx-+9-vm_w-VX7xb2_A@mail.gmail.com>
	<513DE1F3.1090002@redhat.com>
Message-ID: <CAOzQtikKMYnRB1K5YcFyHjbhgh45CwjaNvgzXPaDeOiLQWv0iQ@mail.gmail.com>

I am glad that Redhat has decided to support OpenJDK 6. They firmly felt
that it was in their intrest to continue to support it. I imagine at some
point the support for OpenJDK 6 will wane too. The later OpenJDK and JDK
platforms will offer functionality that 6 does not, and a natural
progression will occur.

Oracle has announced EOL for a long time for JDK 6, and this is no
surprise. Oracle has a strategic interest in advancing the JDK 7 and 8
platforms.

I see both of these objectives as not mutually exclusive. Any major
security issues will be addressed, and OpenJDK 6 will continue to thrive
until eventual obsolesce from the community itself, I imagine that when
OpenJDK 8/9 are released that this pattern will continue.

There is no conspiracy, and as Simon pointed out, the title for the article
was no of his choosing. A good summary article too.

I think it is a testament to the OpenJDK community that the project as a
whole is thriving, and that support is available for the continuation of
the OpenJDK 6 branch.

Thanks to everyone involved and good luck.

John

____________________________

John Yeary
____________________________
*NetBeans Dream Team*
*President Greenville Java Users Group
Java Users Groups Community Leader
Java Enterprise Community Leader*

____________________________

<http://javaevangelist.blogspot.com/>  <https://twitter.com/jyeary>
<http://www.youtube.com/johnyeary>
  <http://www.linkedin.com/in/jyeary>
<https://plus.google.com/112146428878473069965>
  <http://www.facebook.com/jyeary>
<http://feeds.feedburner.com/JavaEvangelistJohnYearysBlog>
  <http://netbeans.org/people/84414-jyeary>

"Far better it is to dare mighty things, to win glorious triumphs, even
though checkered by failure, than to take rank with those poor spirits who
neither enjoy much nor suffer much, because they live in the gray twilight
that knows not victory nor defeat."
-- Theodore Roosevelt


On Mon, Mar 11, 2013 at 9:53 AM, Andrew Haley <aph at redhat.com> wrote:

> On 03/09/2013 04:26 PM, Simon Phipps wrote:
> > Indeed, I've been waiting since then to write about it. FWIW the
> headline &
> > abstract are written by sub-editors and aren't of my choosing. As a
> result
> > they often reflect a nuance I don't actually share.
>
> Ah, that explains a great deal.  I did wonder why such a carefully
> nuanced piece had an inflammatory headline
>
> Thanks,
> Andrew.
>
>


From neugens at redhat.com  Wed Mar 13 15:45:18 2013
From: neugens at redhat.com (Mario Torre)
Date: Wed, 13 Mar 2013 16:45:18 +0100
Subject: Membership renovation
Message-ID: <1363189518.3303.124.camel@pegasus>

Hi all,


According to the bylaws:

"""
Every OpenJDK Membership is subject to automatic Expiration after one
year, but will be renewed upon request
"""

It doesn't say the address to ask for this. Also, I believe a number of
members didn't really realise this rule, and it's not clear if we will
receive a mail asking us to take action or we will just have our members
superpowers silently dropped :) [1]

Can somebody please clarify what we need to do or if this will have any
effect on the new GB election?

Cheers,
Mario

[1] "An OpenJDK Member whose Membership has expired and not yet been
renewed may not exercise the privileges of Membership, except that roles
requiring OpenJDK Membership may be retained", so dropped in the sense
we can't exercise them but it's not clear if we need another election or
we can just request after the fact and be reintegrated.




From mark.reinhold at oracle.com  Wed Mar 13 16:16:18 2013
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 13 Mar 2013 09:16:18 -0700
Subject: Membership renovation
In-Reply-To: <1363189518.3303.124.camel@pegasus>
References: <1363189518.3303.124.camel@pegasus>
Message-ID: <20130313091618.625254@eggemoggin.niobe.net>

2013/3/13 1:45 -0700, Mario Torre <neugens at redhat.com>:
> According to the bylaws:
> 
> """
> Every OpenJDK Membership is subject to automatic Expiration after one
> year, but will be renewed upon request
> """
> 
> It doesn't say the address to ask for this. Also, I believe a number of
> members didn't really realise this rule, and it's not clear if we will
> receive a mail asking us to take action or we will just have our members
> superpowers silently dropped :) [1]
> 
> Can somebody please clarify what we need to do or if this will have any
> effect on the new GB election?

You don't need to do anything.  This will not affect the GB election.

We haven't yet implemented the expiration rule.  When we do, Members
will be notified in advance.  Nobody's superpowers will be dropped
without advance warning.

- Mark


From aph at redhat.com  Wed Mar 13 16:26:23 2013
From: aph at redhat.com (Andrew Haley)
Date: Wed, 13 Mar 2013 16:26:23 +0000
Subject: Membership renovation
In-Reply-To: <1363189518.3303.124.camel@pegasus>
References: <1363189518.3303.124.camel@pegasus>
Message-ID: <5140A8AF.8090307@redhat.com>

On 03/13/2013 03:45 PM, Mario Torre wrote:
> Hi all,
> 
> 
> According to the bylaws:
> 
> """
> Every OpenJDK Membership is subject to automatic Expiration after one
> year, but will be renewed upon request
> """
> 
> It doesn't say the address to ask for this. Also, I believe a number of
> members didn't really realise this rule, and it's not clear if we will
> receive a mail asking us to take action or we will just have our members
> superpowers silently dropped :) [1]
> 
> Can somebody please clarify what we need to do or if this will have any
> effect on the new GB election?

Oh, no.  These rules are insanely bureaucratic.

Andrew.




From neugens at redhat.com  Wed Mar 13 17:28:33 2013
From: neugens at redhat.com (Mario Torre)
Date: Wed, 13 Mar 2013 18:28:33 +0100
Subject: Membership renovation
In-Reply-To: <20130313091618.625254@eggemoggin.niobe.net>
References: <1363189518.3303.124.camel@pegasus>
	<20130313091618.625254@eggemoggin.niobe.net>
Message-ID: <1363195713.3303.130.camel@pegasus>

Il giorno mer, 13/03/2013 alle 09.16 -0700, mark.reinhold at oracle.com ha
scritto:
> 2013/3/13 1:45 -0700, Mario Torre <neugens at redhat.com>:
> > According to the bylaws:
> > 
> > """
> > Every OpenJDK Membership is subject to automatic Expiration after one
> > year, but will be renewed upon request
> > """
> > 
> > It doesn't say the address to ask for this. Also, I believe a number of
> > members didn't really realise this rule, and it's not clear if we will
> > receive a mail asking us to take action or we will just have our members
> > superpowers silently dropped :) [1]
> > 
> > Can somebody please clarify what we need to do or if this will have any
> > effect on the new GB election?
> 
> You don't need to do anything.  This will not affect the GB election.
> 
> We haven't yet implemented the expiration rule.  When we do, Members
> will be notified in advance.  Nobody's superpowers will be dropped
> without advance warning.
> 
> - Mark

Hi Mark,

Thanks for the explanation.

Cheers,
Mario




From iana-ports at iana.org  Wed Mar 13 18:52:22 2013
From: iana-ports at iana.org (Pearl Liang via RT)
Date: Wed, 13 Mar 2013 18:52:22 +0000
Subject: [IANA #656816] Application for a Port Number and/or Service Name
	"jdp-disc" (Completed)
In-Reply-To: <201302071153.r17BrM2g024731@smtp1.lax.icann.org>
References: <RT-Ticket-656816@icann.org>
	<201302071153.r17BrM2g024731@smtp1.lax.icann.org>
Message-ID: <rt-4.0.8-11204-1363200742-1756.656816-6-0@icann.org>

Dear OpenJDK and Florian_Weimer:

Your request has been processed.  We have assigned the following 
UDP port to OpenJDK with you as the point of contact:

jdp-disc           7095        udp    Java Discovery Protocol      
[OpenJDK] mailto:discuss&openjdk.java.net 
[Florian_Weimer]  mailto:fweimer&redhat.com   
2013-03-12 
 
The expert review for this request was completed by: Martin Stiemerling

See: 
http://www.iana.org/assignments/service-names-port-numbers

NOTE: Please make sure a contact behind discuss at openjdk.java.net
can email responses/confirmations from that email address when
there is a need to update the registration record.

Please notify IANA if there is any change in contact information by 
completing the following template:

http://www.iana.org/cgi-bin/mod_portno.pl

This ticket [IANA #656816] is now resolved.

Regards,

Pearl Liang
IANA 

***************************************************************
Internet Assigned Numbers Authority (IANA)
4676 Admiralty Way, Suite 330
Marina del Rey, California 90292

Voice: (310) 823-9358
FAX:   (310) 823-8649
email: iana-ports at iana.org
***************************************************************



From gnu.andrew at redhat.com  Wed Mar 13 19:47:13 2013
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 13 Mar 2013 15:47:13 -0400 (EDT)
Subject: The future of OpenJDK6
In-Reply-To: <5140B125.5030605@redhat.com>
Message-ID: <625773140.18194888.1363204033966.JavaMail.root@redhat.com>

----- Original Message -----
> Oracle ended public updates of JDK6 at the end of last month.  Many
> people seem to have concluded that the OpenJDK6 project will
> therefore
> end at the same time.  This is incorrect: OpenJDK6 will continue, but
> will be maintained by the community outside Oracle.
> 
> This will require some infrastructure changes.  In particular,
> because
> we are to maintain OpenJDK6 outside Oracle we need a bug database to
> which we have full access.  At present, only people inside Oracle can
> create and update bug reports.  Oracle intend to rectify this
> situation sometime in the summer, but in the meantime we need
> something we can use.  I therefore propose to create an OpenJDK 6
> project on java.net and use a JIRA bug database there.  Once Oracle
> has a fully-open bug database we can transfer bugs to it.  While I'm
> aware that this is not ideal, I believe it is the only way that we
> can
> run this project independently of Oracle.
> 
> A few questions I've been asked:
> 
> * What will be the policy for future changes?
> 
> OpenJDK 6 is a legacy project.  People only use it because they want
> long-term stability and compatibility.  Therefore, only changes that
> fix significant bugs should be made.  This is not a policy change
> from
> that discussed on http://openjdk.java.net/projects/jdk6/
> 
> * What about security updates?
> 
> We'll back-port them as they arrive and commit them to OpenJDK 6.
> However, there may be some delay because of the effort and testing
> that back-porting requires.  Therefore, if you want the most secure
> and up-to-date version of OpenJDK, you should update to OpenJDK 7.
> We'll also fix any security bugs that are found in OpenJDK 6 alone,
> but again there may be some delay.
> 
> * What about Windows/Mac/etc builds?
> 
> I really don't know.  If the Windows/Mac/etc community want to get
> involved, then there will be updates for those platforms.  If not,
> there won't be.  It's up to them.
> 
> * How long will this project continue for?
> 
> The duration of support for OpenJDK 6 depends on how active its
> developers remain as part of the OpenJDK community.  As things stand
> today, Red Hat (my current employer) is taking the lead in supporting
> the OpenJDK 6 project.  It is conceivable that this project will be
> maintained beyond the duration of Red Hat's commitment.  That
> ultimately depends on the community.
> 
> Finally, this is a significant moment for OpenJDK.  We look forward
> to
> working with the wider community of OpenJDK 6 users and developers on
> this project.
> 
> Andrew.
> 

A couple of questions:

1.  Oracle had three main roles in relation to OpenJDK 6; acting as
gatekeeper over which patches were accepted into the repository, providing
security updates and making releases.  The third of these doesn't seem to
be addressed above.  Will new releases of OpenJDK 6 be made?  IcedTea for
OpenJDK 6 uses release tarballs as a base so, unless there are further releases,
none of the changes made upstream in OpenJDK 6 will be consumed by IcedTea
downstream.  I believe we are already overdue a new release as there
is no release of OpenJDK 6 containing the last three sets of security
updates.

2.  What many people actually see as OpenJDK 6 at present, in the form of their
GNU/Linux distribution package, is actually IcedTea for OpenJDK 6.  Unlike 7,
where the changes in IcedTea are just to make it "distro-ready" (using system
libraries, etc.), there are now so many backports and other fixes local to
IcedTea 6 that it is effectively a different beast altogether.  Will OpenJDK 6
be open to accepting some of these fixes, many of which were added to the
proprietary version of JDK 6 maintained by Oracle a long time ago, so the
two can eventually be in sync?

3.  The largest contributions to OpenJDK 6 from Red Hat have been the merges of
new versions of HotSpot, upgrading it from 11 through 14, 16 and 19, to its
current version of 20.  Given appropriate testing, is moving to a newer version
of HotSpot a possibility?  We've already started testing HotSpot 23 in IcedTea:

http://blog.fuseyism.com/index.php/2013/03/13/hotspot-23-in-icedtea-for-openjdk-6/

and this shows promise, though we would probably want to go with a later version
in OpenJDK 6 which again has a working Zero assembler port.

4.  Finally, this is just a thought, and I realise it may run contrary to your
promise of long-term stability and compatibility, but I've been giving some thought
to the long running issues we've had with javac in OpenJDK 6.  For those who are
unaware, the javac in OpenJDK 6 is not the same as in Oracle's proprietary JDK 6,
but rather an early development version of the one used in OpenJDK 7.  I've been
wondering if the best way of supporting this long-term would be to use the tools
from 7 in OpenJDK 6, with appropriate reversions to make it compatible with 6
(defaulting to 6 source/target, having builds pass the 6 TCK), rather than continuing
to maintain the hybrid we have now.  This would also mean we'd be able to benefit
more directly from any bug fixes or security updates directed at the langtools
present in 7.

In closing, I'd like to welcome this new chapter in the life of OpenJDK 6 and I hope
it is successful in continuing existing community involvement, and hopefully taking
things even further.

Thanks,
-- 
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 jonathan.gibbons at oracle.com  Wed Mar 13 20:47:24 2013
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 13 Mar 2013 13:47:24 -0700
Subject: The future of OpenJDK6
In-Reply-To: <625773140.18194888.1363204033966.JavaMail.root@redhat.com>
References: <625773140.18194888.1363204033966.JavaMail.root@redhat.com>
Message-ID: <5140E5DC.5060100@oracle.com>

On 03/13/2013 12:47 PM, Andrew Hughes wrote:
> 4.  Finally, this is just a thought, and I realise it may run contrary to your
> promise of long-term stability and compatibility, but I've been giving some thought
> to the long running issues we've had with javac in OpenJDK 6.  For those who are
> unaware, the javac in OpenJDK 6 is not the same as in Oracle's proprietary JDK 6,
> but rather an early development version of the one used in OpenJDK 7.  I've been
> wondering if the best way of supporting this long-term would be to use the tools
> from 7 in OpenJDK 6, with appropriate reversions to make it compatible with 6
> (defaulting to 6 source/target, having builds pass the 6 TCK), rather than continuing
> to maintain the hybrid we have now.  This would also mean we'd be able to benefit
> more directly from any bug fixes or security updates directed at the langtools
> present in 7.

You might want to bring this up on compiler-dev.

-- Jon


From joe.darcy at oracle.com  Wed Mar 13 20:52:27 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 13 Mar 2013 13:52:27 -0700
Subject: The future of OpenJDK6
In-Reply-To: <625773140.18194888.1363204033966.JavaMail.root@redhat.com>
References: <625773140.18194888.1363204033966.JavaMail.root@redhat.com>
Message-ID: <5140E70B.6070204@oracle.com>

Responding to one point below,

On 3/13/2013 12:47 PM, Andrew Hughes wrote:
> ----- Original Message -----

[snip]

> 4. Finally, this is just a thought, and I realise it may run contrary 
> to your promise of long-term stability and compatibility, but I've 
> been giving some thought to the long running issues we've had with 
> javac in OpenJDK 6.


What concrete issues with OpenJDK 6 javac are you referring to? Are 
there bugs for them?

> For those who are unaware, the javac in OpenJDK 6 is not the same as 
> in Oracle's proprietary JDK 6, but rather an early development version 
> of the one used in OpenJDK 7.

The above is an incorrect categorization of the javac in OpenJDK 6 and 
more broadly the langtools repository in OpenJDK 6.

All of OpenJDK 6 initially branched off of (Open)JDK 7 build 20 or so. 
There were fixes in javac and more broadly langtools at that time 
compared to JDK 6 GA. Those fixes were largely appropriate to a Java SE 
6 comiler and therefore kept in; inappropriate changes were backed out. 
At least during the 3+ year tenure when I was release manager of OpenJDK 
6, the langtools team made sure that all javac fixes that went into the 
Sun/Oracle proprietary JDK 6 also went into OpenJDK 6. Therefore, the 
OpenJDK 6 javac has had a strict superset of the fixes in Sun/Oracle JDK 
6. The compilers in both OpenJDK 6 and JDK 6 pass the relevant JCK tests.

The OpenJDK 6 javac and JDK 6 javac are different, but I would argue the 
OpenJDK 6 javac was and is better.

The differences between the OpenJDK 6 and JDK 6 versions of other 
components vary by repository and area. As you noted, for some time 
RedHat has kept the hotspot repo of OpenJDK 6 generally in sync with the 
stabilized HotSpot express releases. At least times in the past, the 
jaxp, jaxws, and cobra OpenJDK 6 repos have been functionally identical 
to their JDK 6 counterparts. Some of this is detailed in an old blog post:

     "OpenJDK 6: Logistics of Partial Merge with 6u10"
https://blogs.oracle.com/darcy/entry/openjdk_6_logistics_of_partial

That leaves the "jdk" repo where most of the core libraries live 
(java.lang, java.util, java.awt, etc.). There has never been an 
analagous grand merge between what would logically be the jdk repo of 
the JDK 6 train and the jdk repo of OpenJDK 6. However, this has not 
seemed to be too much of an impediment to usability or to backporting 
security patches and other fixes as needed.

> I've been wondering if the best way of supporting this long-term would 
> be to use the tools from 7 in OpenJDK 6, with appropriate reversions 
> to make it compatible with 6 (defaulting to 6 source/target, having 
> builds pass the 6 TCK), rather than continuing to maintain the hybrid 
> we have now. This would also mean we'd be able to benefit more 
> directly from any bug fixes or security updates directed at the 
> langtools present in 7. In closing, I'd like to welcome this new 
> chapter in the life of OpenJDK 6 and I hope it is successful in 
> continuing existing community involvement, and hopefully taking things 
> even further. Thanks, 

The code in the (Open)JDK 7 uses the Java SE 7 versions of the 
javax.lang.model.* API, which differ from the Java SE 6 versions. It 
would be a "small matter of programming" to adjust the rest of the javac 
sources accordingly. Note that some portions of the langtools repo in 
OpenJDK 7 outside of parts involved in bootstrapping may rely on Java SE 
7 APIs.

Whether or not undertaking this exercise would lead to lower long-term 
maintenance costs I cannot say, but it is not clear to me that it would.

-Joe


From gnu.andrew at redhat.com  Wed Mar 13 21:42:36 2013
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 13 Mar 2013 17:42:36 -0400 (EDT)
Subject: The future of OpenJDK6
In-Reply-To: <5140E70B.6070204@oracle.com>
Message-ID: <1760028389.18232510.1363210956231.JavaMail.root@redhat.com>

----- Original Message -----
> Responding to one point below,
> 
> On 3/13/2013 12:47 PM, Andrew Hughes wrote:
> > ----- Original Message -----
> 
> [snip]
> 
> > 4. Finally, this is just a thought, and I realise it may run
> > contrary
> > to your promise of long-term stability and compatibility, but I've
> > been giving some thought to the long running issues we've had with
> > javac in OpenJDK 6.
> 
> 
> What concrete issues with OpenJDK 6 javac are you referring to? Are
> there bugs for them?
> 

We tend to come across inferencing issues which don't appear on either
the proprietary JDK 6 compiler or the OpenJDK 7 one e.g.

http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-September/002008.html

> > For those who are unaware, the javac in OpenJDK 6 is not the same
> > as
> > in Oracle's proprietary JDK 6, but rather an early development
> > version
> > of the one used in OpenJDK 7.
> 
> The above is an incorrect categorization of the javac in OpenJDK 6
> and
> more broadly the langtools repository in OpenJDK 6.
> 
> All of OpenJDK 6 initially branched off of (Open)JDK 7 build 20 or
> so.
> There were fixes in javac and more broadly langtools at that time
> compared to JDK 6 GA. Those fixes were largely appropriate to a Java
> SE
> 6 comiler and therefore kept in; inappropriate changes were backed
> out.
> At least during the 3+ year tenure when I was release manager of
> OpenJDK
> 6, the langtools team made sure that all javac fixes that went into
> the
> Sun/Oracle proprietary JDK 6 also went into OpenJDK 6. Therefore, the
> OpenJDK 6 javac has had a strict superset of the fixes in Sun/Oracle
> JDK
> 6. The compilers in both OpenJDK 6 and JDK 6 pass the relevant JCK
> tests.
> 
> The OpenJDK 6 javac and JDK 6 javac are different, but I would argue
> the
> OpenJDK 6 javac was and is better.
> 

I apologise.  I should have clarified that with 'was originally based on
an early development version'. I'm aware it's had work since.  Backports
even caused TCK6 failures for us at least once :)

What I do know is that there are issues that only appear on *that* javac.
It also has been maintained in that way of late.  The last non-tag commit is:

changeset:   126:6fa1f24a215a
tag:         jdk6-b25
user:        jjg
date:        Fri Sep 16 16:18:46 2011 -0700
summary:     7091528: javadoc attempts to parse .class files

about 18 months ago.

> The differences between the OpenJDK 6 and JDK 6 versions of other
> components vary by repository and area. As you noted, for some time
> Red Hat has kept the hotspot repo of OpenJDK 6 generally in sync with
> the
> stabilized HotSpot express releases. At least times in the past, the
> jaxp, jaxws, and cobra OpenJDK 6 repos have been functionally
> identical
> to their JDK 6 counterparts. Some of this is detailed in an old blog
> post:
> 
>      "OpenJDK 6: Logistics of Partial Merge with 6u10"
> https://blogs.oracle.com/darcy/entry/openjdk_6_logistics_of_partial
> 
> That leaves the "jdk" repo where most of the core libraries live
> (java.lang, java.util, java.awt, etc.). There has never been an
> analagous grand merge between what would logically be the jdk repo of
> the JDK 6 train and the jdk repo of OpenJDK 6. However, this has not
> seemed to be too much of an impediment to usability or to backporting
> security patches and other fixes as needed.

I can't really comment on the proprietary JDK 6 codebase any more than
what I can infer as I obviously can't see the code.  I know we've backported
quite a few changes from 7 to 6 (nearly all JDK) which were ported to 7 from
the proprietary 6 codebase by Sun/Oracle before that.  However, there's been
no structure to this.  It's just been a case of seeing a commit to 7 which
references coming from the proprietary 6 tree, or finding a bug that indicates
the fix was committed there.  I have no idea how complete things are.

> 
> > I've been wondering if the best way of supporting this long-term
> > would
> > be to use the tools from 7 in OpenJDK 6, with appropriate
> > reversions
> > to make it compatible with 6 (defaulting to 6 source/target, having
> > builds pass the 6 TCK), rather than continuing to maintain the
> > hybrid
> > we have now. This would also mean we'd be able to benefit more
> > directly from any bug fixes or security updates directed at the
> > langtools present in 7. In closing, I'd like to welcome this new
> > chapter in the life of OpenJDK 6 and I hope it is successful in
> > continuing existing community involvement, and hopefully taking
> > things
> > even further. Thanks,
> 
> The code in the (Open)JDK 7 uses the Java SE 7 versions of the
> javax.lang.model.* API, which differ from the Java SE 6 versions. It
> would be a "small matter of programming" to adjust the rest of the
> javac
> sources accordingly. Note that some portions of the langtools repo in
> OpenJDK 7 outside of parts involved in bootstrapping may rely on Java
> SE
> 7 APIs.
> 

Yes, these are the reversions I was referring to i.e. enough to get it
building and passing the 6 TCK.  My naive thought is that this would be
a more stable process than attempting to backport random changesets from 7,
as it's already been applied once to create the original 6 javac.

> Whether or not undertaking this exercise would lead to lower
> long-term
> maintenance costs I cannot say, but it is not clear to me that it
> would.
> 

As I say, I was just musing on the idea rather than committing to it.
We'd have to investigate it in more detail first.  I was just throwing
the thought out there and your feedback has been very helpful.

>From what you've said, it sounds like the javac is closer to the one in
7 than I'd imagined.

> -Joe
> 

-- 
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 martinrb at google.com  Thu Mar 14 03:25:07 2013
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 13 Mar 2013 20:25:07 -0700
Subject: The future of OpenJDK6
In-Reply-To: <5140E5DC.5060100@oracle.com>
References: <625773140.18194888.1363204033966.JavaMail.root@redhat.com>
	<5140E5DC.5060100@oracle.com>
Message-ID: <CA+kOe0_vmpFxot2QADQLDBsUBHPLafoOPF79tx2Spg-Z1m9v8A@mail.gmail.com>

Our experience at Google has been that javac7 is a stricter compiler than
javac6.  It is a significant effort migrating from javac6 to javac7 with a
large code base.  Since openjdk6 is all about stability, I would resist
updating the javac in openjdk6.  Some of the "bugs" in javac6 allow user
code to compile successfully!


On Wed, Mar 13, 2013 at 1:47 PM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> On 03/13/2013 12:47 PM, Andrew Hughes wrote:
>
>> 4.  Finally, this is just a thought, and I realise it may run contrary to
>> your
>> promise of long-term stability and compatibility, but I've been giving
>> some thought
>> to the long running issues we've had with javac in OpenJDK 6.  For those
>> who are
>> unaware, the javac in OpenJDK 6 is not the same as in Oracle's
>> proprietary JDK 6,
>> but rather an early development version of the one used in OpenJDK 7.
>>  I've been
>> wondering if the best way of supporting this long-term would be to use
>> the tools
>> from 7 in OpenJDK 6, with appropriate reversions to make it compatible
>> with 6
>> (defaulting to 6 source/target, having builds pass the 6 TCK), rather
>> than continuing
>> to maintain the hybrid we have now.  This would also mean we'd be able to
>> benefit
>> more directly from any bug fixes or security updates directed at the
>> langtools
>> present in 7.
>>
>
> You might want to bring this up on compiler-dev.
>
> -- Jon
>


From aph at redhat.com  Thu Mar 14 09:27:33 2013
From: aph at redhat.com (Andrew Haley)
Date: Thu, 14 Mar 2013 09:27:33 +0000
Subject: The future of OpenJDK6
In-Reply-To: <625773140.18194888.1363204033966.JavaMail.root@redhat.com>
References: <625773140.18194888.1363204033966.JavaMail.root@redhat.com>
Message-ID: <51419805.90704@redhat.com>

On 03/13/2013 07:47 PM, Andrew Hughes wrote:
> ----- Original Message -----
>> Oracle ended public updates of JDK6 at the end of last month.  Many
>> people seem to have concluded that the OpenJDK6 project will
>> therefore
>> end at the same time.  This is incorrect: OpenJDK6 will continue, but
>> will be maintained by the community outside Oracle.
> 
> 1.  Oracle had three main roles in relation to OpenJDK 6; acting as
> gatekeeper over which patches were accepted into the repository,
> providing security updates and making releases.  The third of these
> doesn't seem to be addressed above.  Will new releases of OpenJDK 6
> be made?  IcedTea for OpenJDK 6 uses release tarballs as a base so,
> unless there are further releases, none of the changes made upstream
> in OpenJDK 6 will be consumed by IcedTea downstream.  I believe we
> are already overdue a new release as there is no release of OpenJDK
> 6 containing the last three sets of security updates.

Indeed, we need to make a new release of OpenJDK 6 with the security
patches.  There may be infrastructure issues here as we don't AFAIK
have access to Oracle servers on which to place release tarballs.  Or
do we?

> 2.  What many people actually see as OpenJDK 6 at present, in the
> form of their GNU/Linux distribution package, is actually IcedTea
> for OpenJDK 6.  Unlike 7, where the changes in IcedTea are just to
> make it "distro-ready" (using system libraries, etc.), there are now
> so many backports and other fixes local to IcedTea 6 that it is
> effectively a different beast altogether.  Will OpenJDK 6 be open to
> accepting some of these fixes, many of which were added to the
> proprietary version of JDK 6 maintained by Oracle a long time ago,
> so the two can eventually be in sync?

That would, in my view, be a huge waste of effort.  It also risks
breaking things for no net gain.

> 3.  The largest contributions to OpenJDK 6 from Red Hat have been
> the merges of new versions of HotSpot, upgrading it from 11 through
> 14, 16 and 19, to its current version of 20.  Given appropriate
> testing, is moving to a newer version of HotSpot a possibility?

Yes.  I believe that it is necessary to make some small changes to
HotSpot to make it fully Java SE 6 compatible, but we should do this.

> 4.  Finally, this is just a thought, and I realise it may run
> contrary to your promise of long-term stability and compatibility,
> but I've been giving some thought to the long running issues we've
> had with javac in OpenJDK 6.  For those who are unaware, the javac
> in OpenJDK 6 is not the same as in Oracle's proprietary JDK 6, but
> rather an early development version of the one used in OpenJDK 7.
> I've been wondering if the best way of supporting this long-term
> would be to use the tools from 7 in OpenJDK 6, with appropriate
> reversions to make it compatible with 6 (defaulting to 6
> source/target, having builds pass the 6 TCK), rather than continuing
> to maintain the hybrid we have now.

No.  As explained by the Javac team, javac 7 does not accept precisely
the same language, even in "Java 6" mode, and such a change would risk
breaking builds all over the place.  This is exactly the kind of
change that I wish to prevent.

> In closing, I'd like to welcome this new chapter in the life of
> OpenJDK 6 and I hope it is successful in continuing existing
> community involvement, and hopefully taking things even further.

I hope so too.

Andrew.


From jammycc at gmail.com  Thu Mar 14 15:35:00 2013
From: jammycc at gmail.com (Jammy Chen)
Date: Thu, 14 Mar 2013 23:35:00 +0800
Subject: JDK8 will support 64-bit (unsigned int)?
Message-ID: <CAOSazk3QWc7n+Qc0J8Y_Cin31e0tb_2L4fTaOKBqYW3H_Kc84w@mail.gmail.com>

Hello guys,

I just heard that JDK8 will support 64-bit (unsigned int), is it true? if
so, What about unsigned literals? Will the following compile on JDK 8?
int i = 30000000000;


Kurma


From Alan.Bateman at oracle.com  Thu Mar 14 15:53:49 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 14 Mar 2013 15:53:49 +0000
Subject: JDK8 will support 64-bit (unsigned int)?
In-Reply-To: <CAOSazk3QWc7n+Qc0J8Y_Cin31e0tb_2L4fTaOKBqYW3H_Kc84w@mail.gmail.com>
References: <CAOSazk3QWc7n+Qc0J8Y_Cin31e0tb_2L4fTaOKBqYW3H_Kc84w@mail.gmail.com>
Message-ID: <5141F28D.9070907@oracle.com>

On 14/03/2013 15:35, Jammy Chen wrote:
> Hello guys,
>
> I just heard that JDK8 will support 64-bit (unsigned int), is it true? if
> so, What about unsigned literals? Will the following compile on JDK 8?
> int i = 30000000000;
>
>
> Kurma
There are API additions in jdk8 to support unsigned arithmetic. Check 
out the toUnsigned* and other *Unsigned methods on Byte, Short, Long and 
Integer.

-Alan.


From bourges.laurent at gmail.com  Tue Mar 26 11:00:26 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Tue, 26 Mar 2013 12:00:26 +0100
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: <51508139.9000507@oracle.com>
References: <CAKjRUT67vJk7Tso=PnaFow+mfHZyTKXe-2R6CdLLT9yq87x1Eg@mail.gmail.com>
	<CAKjRUT4nqtT8t0-WwpT+dEw_19=fzaYN=511u5cB8N8Wt7U2sw@mail.gmail.com>
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
Message-ID: <CAKjRUT7SmKKSQDkUJiFMW6=_TYmqCLiUoo_3Ur6Ui7HxsND5QQ@mail.gmail.com>

Dear all,

First I joined recently the openJDK contributors, and I plan to fix java2D
pisces code in my spare time.

I have a full time job on Aspro2: http://www.jmmc.fr/aspro; it is an
application to prepare astronomical observations at VLTI / CHARA and is
very used in our community (200 users): it provides scientific computations
(observability, model images using complex numbers ...) and zoomable plots
thanks to jFreeChart.

Aspro2 is known to be very efficient (computation parallelization) and I am
often doing profiling using netbeans profiler or visualVM.

To fix huge memory usages by java2d.pisces, I started implementing an
efficient ArrayCache (int[] and float[]) (in thread local to concurrency
problems):
- arrays in sizes between 10 and 10000 (more small arrays used than big
ones)
- resizing support (Arrays.copyOf) without wasting arrays
- reentrance i.e. many arrays are used at the same time (java2D Pisces
stroke / dash creates many segments to render)
- GC / Heap friendly ie support cache eviction and avoid consuming too much
memory

I know object pooling is known to be not efficient with recent VM (GC is
better) but I think it is counter productive to create so many int[] arrays
in java2d.pisces and let the GC remove such wasted memory.

Does someone have implemented such (open source) array cache (core-libs) ?
Opinions are welcome (but avoid "trolls").

Moreover, sun.java2d.pisces.Helpers.widenArray() performs a lot of array
resizing / copy (Arrays.copyOf) that I want to avoid mostly:
    // These use a hardcoded factor of 2 for increasing sizes. Perhaps this
    // should be provided as an argument.
    static float[] widenArray(float[] in, final int cursize, final int
numToAdd) {
        if (in.length >= cursize + numToAdd) {
            return in;
        }
        return Arrays.copyOf(in, 2 * (cursize + numToAdd));
    }

    static int[] widenArray(int[] in, final int cursize, final int
numToAdd) {
        if (in.length >= cursize + numToAdd) {
            return in;
        }
        return Arrays.copyOf(in, 2 * (cursize + numToAdd));
    }

Thanks to Peter Levart, I use its microbench tool (
https://github.com/plevart/micro-bench/tree/v2) to benchmark ArrayCache
operations... and J2DBench to test java2d performances

What is the fastest way to clear an array (part) ie fill by 0:
- public static void fill(int[] a, int fromIndex, int toIndex, int val)
- public static native void arraycopy(Object src,  int  srcPos, Object
dest, int destPos, int length);
- unsafe.setMemory(array, Unsafe.ARRAY_INT_BASE_OFFSET, 512 * SIZEOF_INT,
(byte) 0)

Apparently, Arrays.fill is always faster (size in 10 ... 10 000) !
I suspect hotspot to optimize its code and use native functions, isn't it
???

Benchmarks results:
>> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
Testing arrays: int[1]...
#
# ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           1 threads, Tavg =      4,47 ns/op (? =   0,00 ns/op) [     4,47]
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           1 threads, Tavg =      4,40 ns/op (? =   0,00 ns/op) [     4,40]
# Measure:
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           1 threads, Tavg =      4,43 ns/op (? =   0,00 ns/op) [     4,43]
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           2 threads, Tavg =      5,55 ns/op (? =   0,16 ns/op) [
5,40,      5,72]

#
# FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =      6,47 ns/op (? =   0,00 ns/op) [     6,47]
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =      6,21 ns/op (? =   0,00 ns/op) [     6,21]
# Measure:
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =      6,19 ns/op (? =   0,00 ns/op) [     6,19]
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           2 threads, Tavg =      7,80 ns/op (? =   0,10 ns/op) [
7,90,      7,71]

#
# FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     26,82 ns/op (? =   0,00 ns/op) [    26,82]
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     23,48 ns/op (? =   0,00 ns/op) [    23,48]
# Measure:
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     22,42 ns/op (? =   0,00 ns/op) [    22,42]
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           2 threads, Tavg =     28,21 ns/op (? =   0,88 ns/op) [
29,11,     27,36]

Testing arrays: int[100]...
#
# ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     16,49 ns/op (? =   0,00 ns/op) [    16,49]
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     15,97 ns/op (? =   0,00 ns/op) [    15,97]
# Measure:
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     16,03 ns/op (? =   0,00 ns/op) [    16,03]
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           2 threads, Tavg =     19,32 ns/op (? =   0,46 ns/op) [
18,87,     19,80]

#
# FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     14,51 ns/op (? =   0,00 ns/op) [    14,51]
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     14,17 ns/op (? =   0,00 ns/op) [    14,17]
# Measure:
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     14,09 ns/op (? =   0,00 ns/op) [    14,09]
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           2 threads, Tavg =     31,15 ns/op (? =   4,04 ns/op) [
27,65,     35,67]

#
# FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     52,32 ns/op (? =   0,00 ns/op) [    52,32]
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     52,82 ns/op (? =   0,00 ns/op) [    52,82]
# Measure:
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =     52,19 ns/op (? =   0,00 ns/op) [    52,19]
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           2 threads, Tavg =     70,87 ns/op (? =   0,71 ns/op) [
70,17,     71,59]

Testing arrays: int[10000]...
#
# ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           1 threads, Tavg =  1 208,64 ns/op (? =   0,00 ns/op) [ 1 208,64]
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           1 threads, Tavg =  1 238,01 ns/op (? =   0,00 ns/op) [ 1 238,01]
# Measure:
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           1 threads, Tavg =  1 235,81 ns/op (? =   0,00 ns/op) [ 1 235,81]
runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal [OpenJDK
64-Bit Server VM 25.0-b22]
           2 threads, Tavg =  1 325,11 ns/op (? =   7,01 ns/op) [
1 332,16,  1 318,14]

#
# FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =  1 930,93 ns/op (? =   0,00 ns/op) [ 1 930,93]
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =  2 060,80 ns/op (? =   0,00 ns/op) [ 2 060,80]
# Measure:
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =  2 105,21 ns/op (? =   0,00 ns/op) [ 2 105,21]
runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM:
1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
           2 threads, Tavg =  2 160,33 ns/op (? =  13,74 ns/op) [
2 146,68,  2 174,15]

#
# FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
#
# Warm up:
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =  3 099,50 ns/op (? =   0,00 ns/op) [ 3 099,50]
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =  3 041,81 ns/op (? =   0,00 ns/op) [ 3 041,81]
# Measure:
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           1 threads, Tavg =  3 068,34 ns/op (? =   0,00 ns/op) [ 3 068,34]
runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 1.8.0-internal
[OpenJDK 64-Bit Server VM 25.0-b22]
           2 threads, Tavg =  3 296,13 ns/op (? =  34,97 ns/op) [
3 331,47,  3 261,53]


PS: java.awt.geom.Path2D has also memory allocation issues:
        void needRoom(boolean needMove, int newCoords) {
            if (needMove && numTypes == 0) {
                throw new IllegalPathStateException("missing initial moveto
"+
                                                    "in path definition");
            }
            int size = pointTypes.length;
            if (numTypes >= size) {
                int grow = size;
                if (grow > EXPAND_MAX) {
                    grow = EXPAND_MAX;
                }
                pointTypes = Arrays.copyOf(pointTypes, size+grow);
            }
            size = floatCoords.length;
            if (numCoords + newCoords > size) {
                int grow = size;
                if (grow > EXPAND_MAX * 2) {
                    grow = EXPAND_MAX * 2;
                }
                if (grow < newCoords) {
                    grow = newCoords;
                }
                floatCoords = Arrays.copyOf(floatCoords, size+grow);
            }
        }

Best regards,
Laurent


From volker.simonis at gmail.com  Wed Mar 27 09:21:41 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 27 Mar 2013 10:21:41 +0100
Subject: 'hg push' hangs if used trough a ssh-tunnel
Message-ID: <CA+3eh11xqZY2NBd_bti4qfWCjeR00+ENq261m+HrNEM6i-x_RA@mail.gmail.com>

Hi,

when pushing to our port repository
http://hg.openjdk.java.net/ppc-aix-port/jdk7u/ I sometimes encounter
strange hangs.

Because I am behind a corporate firewall, I have to use an SSH-tunnel to
access the repository. I'm doing the following:

hg push ssh://simonis@
<internel_tunnel_host>:<tunnel_port>/ppc-aix-port/jdk8/jdk
pushing to ssh://simonis@
<internel_tunnel_host>:<tunnel_port>/ppc-aix-port/jdk8/jdk
Enter passphrase for key '<home_dir>/.ssh/id_rsa':
searching for changes

After this message nothing more happens (for hours...). However if I
interrupt the command with <Ctrl>-C I get the following:

^Cinterrupted!
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 166 changesets with 654 changes to 470 files
remote: snapshot taken

Notice that I don't get the final line "remote: notifying
ppc-aix-port-dev at openjdk.java.net" which is usually printed after every
successfull push but the mailing list is notified nevertheless (i.e. the
push is complete and the corresponding notification mail is send to the
list after I typed <Ctrl>-C). So actually the push succeeds but I'm
nevertheless a little bit confused how long I have to wait until I can
safely interrupt the hanging push:)

I suppose that the problem is caused by the SSH-tunnel which I have to use
but I'm not sure. It only happens on the 'jdk' repository if I push many
(i.e. several hundred) changesets.

Has anybody else encountered such problems and/or does anybody knows any
workarounds?

I'm using Mercurial 2.0.2 on Ubuntu 12.04.
The tunnel host uses:

debug1: Remote protocol version 1.99, remote software version OpenSSH_4.2
debug1: match: OpenSSH_4.2 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1

Thank you and best regards,
Volker


From volker.simonis at gmail.com  Wed Mar 27 17:14:02 2013
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 27 Mar 2013 18:14:02 +0100
Subject: 'hg push' hangs if used trough a ssh-tunnel
In-Reply-To: <226860859.227191.1364403824924.JavaMail.root@redhat.com>
References: <CA+3eh11xqZY2NBd_bti4qfWCjeR00+ENq261m+HrNEM6i-x_RA@mail.gmail.com>
	<226860859.227191.1364403824924.JavaMail.root@redhat.com>
Message-ID: <CA+3eh11X_jxxhQ0KOYWyTrOUnOeNzcKfTz-gEuBqxTB8g=Uy2g@mail.gmail.com>

I read that in a few blogs but was unsure because it usually says
something like "may be faster on slow connections but may also lead to
a considerably slowdown on fast connections". I'll give it a try the
next time I do a big push.

Thanks,
Volker


On Wed, Mar 27, 2013 at 6:03 PM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
>
> ----- Original Message -----
> > Hi,
> >
> > when pushing to our port repository
> > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/ I sometimes encounter
> > strange hangs.
> >
> > Because I am behind a corporate firewall, I have to use an SSH-tunnel
> > to
> > access the repository. I'm doing the following:
> >
> > hg push ssh://simonis@
> > <internel_tunnel_host>:<tunnel_port>/ppc-aix-port/jdk8/jdk
> > pushing to ssh://simonis@
> > <internel_tunnel_host>:<tunnel_port>/ppc-aix-port/jdk8/jdk
> > Enter passphrase for key '<home_dir>/.ssh/id_rsa':
> > searching for changes
> >
> > After this message nothing more happens (for hours...). However if I
> > interrupt the command with <Ctrl>-C I get the following:
> >
> > ^Cinterrupted!
> > remote: adding changesets
> > remote: adding manifests
> > remote: adding file changes
> > remote: added 166 changesets with 654 changes to 470 files
> > remote: snapshot taken
> >
> > Notice that I don't get the final line "remote: notifying
> > ppc-aix-port-dev at openjdk.java.net" which is usually printed after
> > every
> > successfull push but the mailing list is notified nevertheless (i.e.
> > the
> > push is complete and the corresponding notification mail is send to
> > the
> > list after I typed <Ctrl>-C). So actually the push succeeds but I'm
> > nevertheless a little bit confused how long I have to wait until I
> > can
> > safely interrupt the hanging push:)
> >
> > I suppose that the problem is caused by the SSH-tunnel which I have
> > to use
> > but I'm not sure. It only happens on the 'jdk' repository if I push
> > many
> > (i.e. several hundred) changesets.
> >
> > Has anybody else encountered such problems and/or does anybody knows
> > any
> > workarounds?
> >
> > I'm using Mercurial 2.0.2 on Ubuntu 12.04.
> > The tunnel host uses:
> >
> > debug1: Remote protocol version 1.99, remote software version
> > OpenSSH_4.2
> > debug1: match: OpenSSH_4.2 pat OpenSSH_4*
> > debug1: Enabling compatibility mode for protocol 2.0
> > debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
> >
> > Thank you and best regards,
> > Volker
> >
>
> I do know that the OpenJDK servers can be quite slow at pushing, because
> they make ZFS snapshots, though it's a lot better than it used to be.
>
> Do you have "ssh = ssh -C" in $HOME/.hgrc?  Having ssh at least use
> compression might help a bit.
> --
> 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 27 17:03:44 2013
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 27 Mar 2013 13:03:44 -0400 (EDT)
Subject: 'hg push' hangs if used trough a ssh-tunnel
In-Reply-To: <CA+3eh11xqZY2NBd_bti4qfWCjeR00+ENq261m+HrNEM6i-x_RA@mail.gmail.com>
Message-ID: <226860859.227191.1364403824924.JavaMail.root@redhat.com>

----- Original Message -----
> Hi,
> 
> when pushing to our port repository
> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/ I sometimes encounter
> strange hangs.
> 
> Because I am behind a corporate firewall, I have to use an SSH-tunnel
> to
> access the repository. I'm doing the following:
> 
> hg push ssh://simonis@
> <internel_tunnel_host>:<tunnel_port>/ppc-aix-port/jdk8/jdk
> pushing to ssh://simonis@
> <internel_tunnel_host>:<tunnel_port>/ppc-aix-port/jdk8/jdk
> Enter passphrase for key '<home_dir>/.ssh/id_rsa':
> searching for changes
> 
> After this message nothing more happens (for hours...). However if I
> interrupt the command with <Ctrl>-C I get the following:
> 
> ^Cinterrupted!
> remote: adding changesets
> remote: adding manifests
> remote: adding file changes
> remote: added 166 changesets with 654 changes to 470 files
> remote: snapshot taken
> 
> Notice that I don't get the final line "remote: notifying
> ppc-aix-port-dev at openjdk.java.net" which is usually printed after
> every
> successfull push but the mailing list is notified nevertheless (i.e.
> the
> push is complete and the corresponding notification mail is send to
> the
> list after I typed <Ctrl>-C). So actually the push succeeds but I'm
> nevertheless a little bit confused how long I have to wait until I
> can
> safely interrupt the hanging push:)
> 
> I suppose that the problem is caused by the SSH-tunnel which I have
> to use
> but I'm not sure. It only happens on the 'jdk' repository if I push
> many
> (i.e. several hundred) changesets.
> 
> Has anybody else encountered such problems and/or does anybody knows
> any
> workarounds?
> 
> I'm using Mercurial 2.0.2 on Ubuntu 12.04.
> The tunnel host uses:
> 
> debug1: Remote protocol version 1.99, remote software version
> OpenSSH_4.2
> debug1: match: OpenSSH_4.2 pat OpenSSH_4*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
> 
> Thank you and best regards,
> Volker
> 

I do know that the OpenJDK servers can be quite slow at pushing, because
they make ZFS snapshots, though it's a lot better than it used to be.

Do you have "ssh = ssh -C" in $HOME/.hgrc?  Having ssh at least use
compression might help a bit.
-- 
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 27 20:40:08 2013
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 27 Mar 2013 16:40:08 -0400 (EDT)
Subject: 'hg push' hangs if used trough a ssh-tunnel
In-Reply-To: <CA+3eh11X_jxxhQ0KOYWyTrOUnOeNzcKfTz-gEuBqxTB8g=Uy2g@mail.gmail.com>
Message-ID: <555182430.320241.1364416808405.JavaMail.root@redhat.com>

----- Original Message -----
> I read that in a few blogs but was unsure because it usually says
> something like "may be faster on slow connections but may also lead
> to
> a considerably slowdown on fast connections". I'll give it a try the
> next time I do a big push.
> 

I think it was Mark Reinhold who suggested it to me when I was having
issues.  It sounds a little like something is timing out somewhere
with the big jdk pushes.

Maybe jdk can one day be split up a bit? :-D

> Thanks,
> Volker
> 
> 
> On Wed, Mar 27, 2013 at 6:03 PM, Andrew Hughes
> <gnu.andrew at redhat.com> wrote:
> >
> > ----- Original Message -----
> > > Hi,
> > >
> > > when pushing to our port repository
> > > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/ I sometimes
> > > encounter
> > > strange hangs.
> > >
> > > Because I am behind a corporate firewall, I have to use an
> > > SSH-tunnel
> > > to
> > > access the repository. I'm doing the following:
> > >
> > > hg push ssh://simonis@
> > > <internel_tunnel_host>:<tunnel_port>/ppc-aix-port/jdk8/jdk
> > > pushing to ssh://simonis@
> > > <internel_tunnel_host>:<tunnel_port>/ppc-aix-port/jdk8/jdk
> > > Enter passphrase for key '<home_dir>/.ssh/id_rsa':
> > > searching for changes
> > >
> > > After this message nothing more happens (for hours...). However
> > > if I
> > > interrupt the command with <Ctrl>-C I get the following:
> > >
> > > ^Cinterrupted!
> > > remote: adding changesets
> > > remote: adding manifests
> > > remote: adding file changes
> > > remote: added 166 changesets with 654 changes to 470 files
> > > remote: snapshot taken
> > >
> > > Notice that I don't get the final line "remote: notifying
> > > ppc-aix-port-dev at openjdk.java.net" which is usually printed after
> > > every
> > > successfull push but the mailing list is notified nevertheless
> > > (i.e.
> > > the
> > > push is complete and the corresponding notification mail is send
> > > to
> > > the
> > > list after I typed <Ctrl>-C). So actually the push succeeds but
> > > I'm
> > > nevertheless a little bit confused how long I have to wait until
> > > I
> > > can
> > > safely interrupt the hanging push:)
> > >
> > > I suppose that the problem is caused by the SSH-tunnel which I
> > > have
> > > to use
> > > but I'm not sure. It only happens on the 'jdk' repository if I
> > > push
> > > many
> > > (i.e. several hundred) changesets.
> > >
> > > Has anybody else encountered such problems and/or does anybody
> > > knows
> > > any
> > > workarounds?
> > >
> > > I'm using Mercurial 2.0.2 on Ubuntu 12.04.
> > > The tunnel host uses:
> > >
> > > debug1: Remote protocol version 1.99, remote software version
> > > OpenSSH_4.2
> > > debug1: match: OpenSSH_4.2 pat OpenSSH_4*
> > > debug1: Enabling compatibility mode for protocol 2.0
> > > debug1: Local version string SSH-2.0-OpenSSH_5.9p1
> > > Debian-5ubuntu1
> > >
> > > Thank you and best regards,
> > > Volker
> > >
> >
> > I do know that the OpenJDK servers can be quite slow at pushing,
> > because
> > they make ZFS snapshots, though it's a lot better than it used to
> > be.
> >
> > Do you have "ssh = ssh -C" in $HOME/.hgrc?  Having ssh at least use
> > compression might help a bit.
> > --
> > 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 neugens at redhat.com  Thu Mar 28 15:48:40 2013
From: neugens at redhat.com (Mario Torre)
Date: Thu, 28 Mar 2013 16:48:40 +0100
Subject: GNU Classpath ideas for GSoC 2013
Message-ID: <1364485720.24471.50.camel@galactica.localdomain>

Hi all!

Is there any chance we can propose OpenJDK as a mentoring Organisation
for the Summer of Code 2013?

I'm about to register IcedTea, but I think it would be better to have
OpenJDK itself.

Cheers,
Mario





From donald.smith at oracle.com  Thu Mar 28 16:20:47 2013
From: donald.smith at oracle.com (Donald Smith)
Date: Thu, 28 Mar 2013 12:20:47 -0400
Subject: GNU Classpath ideas for GSoC 2013
In-Reply-To: <1364485720.24471.50.camel@galactica.localdomain>
References: <1364485720.24471.50.camel@galactica.localdomain>
Message-ID: <51546DDF.4040908@oracle.com>

At some point perhaps, but it won't be possible this year.

  - Don

On 28/03/2013 11:48 AM, Mario Torre wrote:
> Hi all!
>
> Is there any chance we can propose OpenJDK as a mentoring Organisation
> for the Summer of Code 2013?
>
> I'm about to register IcedTea, but I think it would be better to have
> OpenJDK itself.
>
> Cheers,
> Mario
>
>
>



From philip.race at oracle.com  Thu Mar 28 19:38:39 2013
From: philip.race at oracle.com (Phil Race)
Date: Thu, 28 Mar 2013 12:38:39 -0700
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: <CAKjRUT7SmKKSQDkUJiFMW6=_TYmqCLiUoo_3Ur6Ui7HxsND5QQ@mail.gmail.com>
References: <CAKjRUT67vJk7Tso=PnaFow+mfHZyTKXe-2R6CdLLT9yq87x1Eg@mail.gmail.com>
	<CAKjRUT4nqtT8t0-WwpT+dEw_19=fzaYN=511u5cB8N8Wt7U2sw@mail.gmail.com>
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	<CAKjRUT7SmKKSQDkUJiFMW6=_TYmqCLiUoo_3Ur6Ui7HxsND5QQ@mail.gmail.com>
Message-ID: <51549C3F.1020301@oracle.com>

Maintaining a pool of objects might be an appropriate thing for an 
applications,
but its a lot trickier for the platform as the application's usage 
pattern or intent
is largely unknown. Weak references or soft references might be of use but
weak references usually go away even at the next incremental GC and soft
references tend to not go away at all until you run out of heap.

You may well be right that always doubling the array size may be too 
simplistic,
but it would need some analysis of the code and its usage to see how much
better we can do.

 >Apparently, Arrays.fill is always faster (size in 10 ... 10 000) !
 > I suspect hotspot to optimize its code and use native functions, 
isn't it ???

I suppose there is some hotspot magic involved to recognise and 
intrinsify this
method, since the source code looks like a plain old for loop.

-phil.


On 3/26/2013 4:00 AM, Laurent Bourg?s wrote:
> Dear all,
>
> First I joined recently the openJDK contributors, and I plan to fix 
> java2D pisces code in my spare time.
>
> I have a full time job on Aspro2: http://www.jmmc.fr/aspro; it is an 
> application to prepare astronomical observations at VLTI / CHARA and 
> is very used in our community (200 users): it provides scientific 
> computations (observability, model images using complex numbers ...) 
> and zoomable plots thanks to jFreeChart.
>
> Aspro2 is known to be very efficient (computation parallelization) and 
> I am often doing profiling using netbeans profiler or visualVM.
>
> To fix huge memory usages by java2d.pisces, I started implementing an 
> efficient ArrayCache (int[] and float[]) (in thread local to 
> concurrency problems):
> - arrays in sizes between 10 and 10000 (more small arrays used than 
> big ones)
> - resizing support (Arrays.copyOf) without wasting arrays
> - reentrance i.e. many arrays are used at the same time (java2D Pisces 
> stroke / dash creates many segments to render)
> - GC / Heap friendly ie support cache eviction and avoid consuming too 
> much memory
>
> I know object pooling is known to be not efficient with recent VM (GC 
> is better) but I think it is counter productive to create so many 
> int[] arrays in java2d.pisces and let the GC remove such wasted memory.
>
> Does someone have implemented such (open source) array cache 
> (core-libs) ?
> Opinions are welcome (but avoid "trolls").
>
> Moreover, sun.java2d.pisces.Helpers.widenArray() performs a lot of 
> array resizing / copy (Arrays.copyOf) that I want to avoid mostly:
>     // These use a hardcoded factor of 2 for increasing sizes. Perhaps 
> this
>     // should be provided as an argument.
>     static float[] widenArray(float[] in, final int cursize, final int 
> numToAdd) {
>         if (in.length >= cursize + numToAdd) {
>             return in;
>         }
>         return Arrays.copyOf(in, 2 * (cursize + numToAdd));
>     }
>
>     static int[] widenArray(int[] in, final int cursize, final int 
> numToAdd) {
>         if (in.length >= cursize + numToAdd) {
>             return in;
>         }
>         return Arrays.copyOf(in, 2 * (cursize + numToAdd));
>     }
>
> Thanks to Peter Levart, I use its microbench tool 
> (https://github.com/plevart/micro-bench/tree/v2) to benchmark 
> ArrayCache operations... and J2DBench to test java2d performances
>
> What is the fastest way to clear an array (part) ie fill by 0:
> - public static void fill(int[] a, int fromIndex, int toIndex, int val)
> - public static native void arraycopy(Object src,  int  srcPos, Object 
> dest, int destPos, int length);
> - unsafe.setMemory(array, Unsafe.ARRAY_INT_BASE_OFFSET, 512 * 
> SIZEOF_INT, (byte) 0)
>
> Apparently, Arrays.fill is always faster (size in 10 ... 10 000) !
> I suspect hotspot to optimize its code and use native functions, isn't 
> it ???
>
> Benchmarks results:
> >> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
> Testing arrays: int[1]...
> #
> # ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
> #
> # Warm up:
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =      4,47 ns/op (? =   0,00 ns/op) [     
> 4,47]
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =      4,40 ns/op (? =   0,00 ns/op) [     
> 4,40]
> # Measure:
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =      4,43 ns/op (? =   0,00 ns/op) [     
> 4,43]
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            2 threads, Tavg =      5,55 ns/op (? =   0,16 ns/op) [     
> 5,40,      5,72]
>
> #
> # FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
> #
> # Warm up:
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =      6,47 ns/op (? =   0,00 ns/op) [     
> 6,47]
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =      6,21 ns/op (? =   0,00 ns/op) [     
> 6,21]
> # Measure:
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =      6,19 ns/op (? =   0,00 ns/op) [     
> 6,19]
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            2 threads, Tavg =      7,80 ns/op (? =   0,10 ns/op) [     
> 7,90,      7,71]
>
> #
> # FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
> #
> # Warm up:
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     26,82 ns/op (? =   0,00 ns/op) [    
> 26,82]
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     23,48 ns/op (? =   0,00 ns/op) [    
> 23,48]
> # Measure:
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     22,42 ns/op (? =   0,00 ns/op) [    
> 22,42]
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            2 threads, Tavg =     28,21 ns/op (? =   0,88 ns/op) [    
> 29,11,     27,36]
>
> Testing arrays: int[100]...
> #
> # ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
> #
> # Warm up:
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     16,49 ns/op (? =   0,00 ns/op) [    
> 16,49]
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     15,97 ns/op (? =   0,00 ns/op) [    
> 15,97]
> # Measure:
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     16,03 ns/op (? =   0,00 ns/op) [    
> 16,03]
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            2 threads, Tavg =     19,32 ns/op (? =   0,46 ns/op) [    
> 18,87,     19,80]
>
> #
> # FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
> #
> # Warm up:
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     14,51 ns/op (? =   0,00 ns/op) [    
> 14,51]
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     14,17 ns/op (? =   0,00 ns/op) [    
> 14,17]
> # Measure:
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     14,09 ns/op (? =   0,00 ns/op) [    
> 14,09]
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            2 threads, Tavg =     31,15 ns/op (? =   4,04 ns/op) [    
> 27,65,     35,67]
>
> #
> # FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
> #
> # Warm up:
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     52,32 ns/op (? =   0,00 ns/op) [    
> 52,32]
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     52,82 ns/op (? =   0,00 ns/op) [    
> 52,82]
> # Measure:
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =     52,19 ns/op (? =   0,00 ns/op) [    
> 52,19]
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            2 threads, Tavg =     70,87 ns/op (? =   0,71 ns/op) [    
> 70,17,     71,59]
>
> Testing arrays: int[10000]...
> #
> # ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
> #
> # Warm up:
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =  1 208,64 ns/op (? =   0,00 ns/op) [ 
> 1 208,64]
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =  1 238,01 ns/op (? =   0,00 ns/op) [ 
> 1 238,01]
> # Measure:
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =  1 235,81 ns/op (? =   0,00 ns/op) [ 
> 1 235,81]
> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal 
> [OpenJDK 64-Bit Server VM 25.0-b22]
>            2 threads, Tavg =  1 325,11 ns/op (? =   7,01 ns/op) [ 
> 1 332,16,  1 318,14]
>
> #
> # FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
> #
> # Warm up:
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =  1 930,93 ns/op (? =   0,00 ns/op) [ 
> 1 930,93]
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =  2 060,80 ns/op (? =   0,00 ns/op) [ 
> 2 060,80]
> # Measure:
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =  2 105,21 ns/op (? =   0,00 ns/op) [ 
> 2 105,21]
> runTest[class ArrayCacheBenchmark$FillArraySystemCopy] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            2 threads, Tavg =  2 160,33 ns/op (? =  13,74 ns/op) [ 
> 2 146,68,  2 174,15]
>
> #
> # FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
> #
> # Warm up:
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =  3 099,50 ns/op (? =   0,00 ns/op) [ 
> 3 099,50]
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =  3 041,81 ns/op (? =   0,00 ns/op) [ 
> 3 041,81]
> # Measure:
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            1 threads, Tavg =  3 068,34 ns/op (? =   0,00 ns/op) [ 
> 3 068,34]
> runTest[class ArrayCacheBenchmark$FillArrayUnsafe] on JVM: 
> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>            2 threads, Tavg =  3 296,13 ns/op (? =  34,97 ns/op) [ 
> 3 331,47,  3 261,53]
>
>
> PS: java.awt.geom.Path2D has also memory allocation issues:
>         void needRoom(boolean needMove, int newCoords) {
>             if (needMove && numTypes == 0) {
> throw new IllegalPathStateException("missing initial moveto "+
> "in path definition");
>             }
>             int size = pointTypes.length;
>             if (numTypes >= size) {
> int grow = size;
>                 if (grow > EXPAND_MAX) {
> grow = EXPAND_MAX;
>                 }
> pointTypes = Arrays.copyOf(pointTypes, size+grow);
>             }
>             size = floatCoords.length;
>             if (numCoords + newCoords > size) {
> int grow = size;
>                 if (grow > EXPAND_MAX * 2) {
> grow = EXPAND_MAX * 2;
>                 }
>                 if (grow < newCoords) {
> grow = newCoords;
>                 }
> floatCoords = Arrays.copyOf(floatCoords, size+grow);
>             }
>         }
>
> Best regards,
> Laurent



From bourges.laurent at gmail.com  Fri Mar 29 13:53:09 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Fri, 29 Mar 2013 14:53:09 +0100
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: <51549C3F.1020301@oracle.com>
References: <CAKjRUT67vJk7Tso=PnaFow+mfHZyTKXe-2R6CdLLT9yq87x1Eg@mail.gmail.com>
	<CAKjRUT4nqtT8t0-WwpT+dEw_19=fzaYN=511u5cB8N8Wt7U2sw@mail.gmail.com>
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	<CAKjRUT7SmKKSQDkUJiFMW6=_TYmqCLiUoo_3Ur6Ui7HxsND5QQ@mail.gmail.com>
	<51549C3F.1020301@oracle.com>
Message-ID: <CAKjRUT5JWQFLmbTh1+dmXPO56BprYCuMibiejdypL50GRqVHPw@mail.gmail.com>

Phil,

I agree it is a complex issue to improve memory usage while maintaining
performance at the JDK level: applications can use java2d pisces in very
different contexts: Swing app (client with only EDT thread), server-side
application (multi thread headless) ...

For the moment, I spent a lot of my time understanding the different
classes in java2d.pisces and analyzing memory usage / performance ... using
J2DBench (all graphics tests).

In my Swing application, pisces produces a lot of waste (GC) but on server
side, the GC overhead can be more important if several threads use pisces.

Pisces uses memory differently:
- fixed arrays (dasher, stroker)
- dynamic arrays (edges ...) rowAARLE (very big one for big shapes)

For the moment I am trying to avoid memory waste (pooling or kept
reference) without any memory constraint (no eviction) but I agree it is an
important aspect for server-side applications.

To avoid concurrency issues, I use a ThreadLocal context named
RendererContext to keep few temporary arrays (float6 and a BIG rowAARLE
instance) but there is also dynamic IntArrayCache et FloatArrayCache which
have several pools divided in buckets (256, 1024, 4096, 16384, 32768)
containing only few instances.

To have best performance, I studied pisces code to clear only the used
array parts when recycling or using dirty arrays (only clear
rowAARLE[...][1]).

I think Andrea's proposal is interesting to maybe put some system
properties to give hints (low memory footprint, use cache or not ...).

2013/3/28 Phil Race <philip.race at oracle.com>

> Maintaining a pool of objects might be an appropriate thing for an
> applications,
> but its a lot trickier for the platform as the application's usage pattern
> or intent
> is largely unknown. Weak references or soft references might be of use but
> weak references usually go away even at the next incremental GC and soft
> references tend to not go away at all until you run out of heap.
>

Agreed; for the moment, pool eviction policy is not implemented but kept in
mind.
FYI: each RendererContext (per thread) has its own array pools (not shared)
that could have different caching policies:
For instance, AWT / EDT (repaint) could use a large cache although other
threads do not use array caching at all.


> You may well be right that always doubling the array size may be too
> simplistic,
> but it would need some analysis of the code and its usage to see how much
> better we can do.


There is two part:
- initial array size for dynamic arrays: difficult to estimate but for now
set to very low capacity (8 / 50 ...) to avoid memory waste for rectangle /
line shapes. In my patch, I have defined MIN_ARRAY_SIZE = 128 (array pool)
to avoid too much resizing as I am doing array recycling.
- grow: I use x4 instead of x2 to avoid array copies.

Laurent



2013/3/28 Phil Race <philip.race at oracle.com>

> Maintaining a pool of objects might be an appropriate thing for an
> applications,
> but its a lot trickier for the platform as the application's usage pattern
> or intent
> is largely unknown. Weak references or soft references might be of use but
> weak references usually go away even at the next incremental GC and soft
> references tend to not go away at all until you run out of heap.
>
> You may well be right that always doubling the array size may be too
> simplistic,
> but it would need some analysis of the code and its usage to see how much
> better we can do.
>
>
> >Apparently, Arrays.fill is always faster (size in 10 ... 10 000) !
> > I suspect hotspot to optimize its code and use native functions, isn't
> it ???
>
> I suppose there is some hotspot magic involved to recognise and intrinsify
> this
> method, since the source code looks like a plain old for loop.
>
> -phil.
>
>
>
> On 3/26/2013 4:00 AM, Laurent Bourg?s wrote:
>
>> Dear all,
>>
>> First I joined recently the openJDK contributors, and I plan to fix
>> java2D pisces code in my spare time.
>>
>> I have a full time job on Aspro2: http://www.jmmc.fr/aspro; it is an
>> application to prepare astronomical observations at VLTI / CHARA and is
>> very used in our community (200 users): it provides scientific computations
>> (observability, model images using complex numbers ...) and zoomable plots
>> thanks to jFreeChart.
>>
>> Aspro2 is known to be very efficient (computation parallelization) and I
>> am often doing profiling using netbeans profiler or visualVM.
>>
>> To fix huge memory usages by java2d.pisces, I started implementing an
>> efficient ArrayCache (int[] and float[]) (in thread local to concurrency
>> problems):
>> - arrays in sizes between 10 and 10000 (more small arrays used than big
>> ones)
>> - resizing support (Arrays.copyOf) without wasting arrays
>> - reentrance i.e. many arrays are used at the same time (java2D Pisces
>> stroke / dash creates many segments to render)
>> - GC / Heap friendly ie support cache eviction and avoid consuming too
>> much memory
>>
>> I know object pooling is known to be not efficient with recent VM (GC is
>> better) but I think it is counter productive to create so many int[] arrays
>> in java2d.pisces and let the GC remove such wasted memory.
>>
>> Does someone have implemented such (open source) array cache (core-libs) ?
>> Opinions are welcome (but avoid "trolls").
>>
>> Moreover, sun.java2d.pisces.Helpers.**widenArray() performs a lot of
>> array resizing / copy (Arrays.copyOf) that I want to avoid mostly:
>>     // These use a hardcoded factor of 2 for increasing sizes. Perhaps
>> this
>>     // should be provided as an argument.
>>     static float[] widenArray(float[] in, final int cursize, final int
>> numToAdd) {
>>         if (in.length >= cursize + numToAdd) {
>>             return in;
>>         }
>>         return Arrays.copyOf(in, 2 * (cursize + numToAdd));
>>     }
>>
>>     static int[] widenArray(int[] in, final int cursize, final int
>> numToAdd) {
>>         if (in.length >= cursize + numToAdd) {
>>             return in;
>>         }
>>         return Arrays.copyOf(in, 2 * (cursize + numToAdd));
>>     }
>>
>> Thanks to Peter Levart, I use its microbench tool (
>> https://github.com/plevart/**micro-bench/tree/v2<https://github.com/plevart/micro-bench/tree/v2>)
>> to benchmark ArrayCache operations... and J2DBench to test java2d
>> performances
>>
>> What is the fastest way to clear an array (part) ie fill by 0:
>> - public static void fill(int[] a, int fromIndex, int toIndex, int val)
>> - public static native void arraycopy(Object src,  int  srcPos, Object
>> dest, int destPos, int length);
>> - unsafe.setMemory(array, Unsafe.ARRAY_INT_BASE_OFFSET, 512 * SIZEOF_INT,
>> (byte) 0)
>>
>> Apparently, Arrays.fill is always faster (size in 10 ... 10 000) !
>> I suspect hotspot to optimize its code and use native functions, isn't it
>> ???
>>
>> Benchmarks results:
>> >> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>> Testing arrays: int[1]...
>> #
>> # ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
>> #
>> # Warm up:
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =      4,47 ns/op (? =   0,00 ns/op) [
>> 4,47]
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =      4,40 ns/op (? =   0,00 ns/op) [
>> 4,40]
>> # Measure:
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =      4,43 ns/op (? =   0,00 ns/op) [
>> 4,43]
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            2 threads, Tavg =      5,55 ns/op (? =   0,16 ns/op) [
>> 5,40,      5,72]
>>
>> #
>> # FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
>> #
>> # Warm up:
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =      6,47 ns/op (? =   0,00 ns/op) [
>> 6,47]
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =      6,21 ns/op (? =   0,00 ns/op) [
>> 6,21]
>> # Measure:
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =      6,19 ns/op (? =   0,00 ns/op) [
>> 6,19]
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            2 threads, Tavg =      7,80 ns/op (? =   0,10 ns/op) [
>> 7,90,      7,71]
>>
>> #
>> # FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
>> #
>> # Warm up:
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     26,82 ns/op (? =   0,00 ns/op) [
>>  26,82]
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     23,48 ns/op (? =   0,00 ns/op) [
>>  23,48]
>> # Measure:
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     22,42 ns/op (? =   0,00 ns/op) [
>>  22,42]
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            2 threads, Tavg =     28,21 ns/op (? =   0,88 ns/op) [
>>  29,11,     27,36]
>>
>> Testing arrays: int[100]...
>> #
>> # ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
>> #
>> # Warm up:
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     16,49 ns/op (? =   0,00 ns/op) [
>>  16,49]
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     15,97 ns/op (? =   0,00 ns/op) [
>>  15,97]
>> # Measure:
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     16,03 ns/op (? =   0,00 ns/op) [
>>  16,03]
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            2 threads, Tavg =     19,32 ns/op (? =   0,46 ns/op) [
>>  18,87,     19,80]
>>
>> #
>> # FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
>> #
>> # Warm up:
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     14,51 ns/op (? =   0,00 ns/op) [
>>  14,51]
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     14,17 ns/op (? =   0,00 ns/op) [
>>  14,17]
>> # Measure:
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     14,09 ns/op (? =   0,00 ns/op) [
>>  14,09]
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            2 threads, Tavg =     31,15 ns/op (? =   4,04 ns/op) [
>>  27,65,     35,67]
>>
>> #
>> # FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
>> #
>> # Warm up:
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     52,32 ns/op (? =   0,00 ns/op) [
>>  52,32]
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     52,82 ns/op (? =   0,00 ns/op) [
>>  52,82]
>> # Measure:
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =     52,19 ns/op (? =   0,00 ns/op) [
>>  52,19]
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            2 threads, Tavg =     70,87 ns/op (? =   0,71 ns/op) [
>>  70,17,     71,59]
>>
>> Testing arrays: int[10000]...
>> #
>> # ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
>> #
>> # Warm up:
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =  1 208,64 ns/op (? =   0,00 ns/op) [ 1
>> 208,64]
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =  1 238,01 ns/op (? =   0,00 ns/op) [ 1
>> 238,01]
>> # Measure:
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =  1 235,81 ns/op (? =   0,00 ns/op) [ 1
>> 235,81]
>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>            2 threads, Tavg =  1 325,11 ns/op (? =   7,01 ns/op) [ 1
>> 332,16,  1 318,14]
>>
>> #
>> # FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
>> #
>> # Warm up:
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =  1 930,93 ns/op (? =   0,00 ns/op) [ 1
>> 930,93]
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =  2 060,80 ns/op (? =   0,00 ns/op) [ 2
>> 060,80]
>> # Measure:
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =  2 105,21 ns/op (? =   0,00 ns/op) [ 2
>> 105,21]
>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            2 threads, Tavg =  2 160,33 ns/op (? =  13,74 ns/op) [ 2
>> 146,68,  2 174,15]
>>
>> #
>> # FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
>> #
>> # Warm up:
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =  3 099,50 ns/op (? =   0,00 ns/op) [ 3
>> 099,50]
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =  3 041,81 ns/op (? =   0,00 ns/op) [ 3
>> 041,81]
>> # Measure:
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            1 threads, Tavg =  3 068,34 ns/op (? =   0,00 ns/op) [ 3
>> 068,34]
>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>            2 threads, Tavg =  3 296,13 ns/op (? =  34,97 ns/op) [ 3
>> 331,47,  3 261,53]
>>
>>
>> PS: java.awt.geom.Path2D has also memory allocation issues:
>>         void needRoom(boolean needMove, int newCoords) {
>>             if (needMove && numTypes == 0) {
>> throw new IllegalPathStateException("**missing initial moveto "+
>> "in path definition");
>>             }
>>             int size = pointTypes.length;
>>             if (numTypes >= size) {
>> int grow = size;
>>                 if (grow > EXPAND_MAX) {
>> grow = EXPAND_MAX;
>>                 }
>> pointTypes = Arrays.copyOf(pointTypes, size+grow);
>>             }
>>             size = floatCoords.length;
>>             if (numCoords + newCoords > size) {
>> int grow = size;
>>                 if (grow > EXPAND_MAX * 2) {
>> grow = EXPAND_MAX * 2;
>>                 }
>>                 if (grow < newCoords) {
>> grow = newCoords;
>>                 }
>> floatCoords = Arrays.copyOf(floatCoords, size+grow);
>>             }
>>         }
>>
>> Best regards,
>> Laurent
>>
>
>


From james.graham at oracle.com  Sat Mar 30 00:39:03 2013
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 29 Mar 2013 17:39:03 -0700
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: <CAKjRUT5JWQFLmbTh1+dmXPO56BprYCuMibiejdypL50GRqVHPw@mail.gmail.com>
References: <CAKjRUT67vJk7Tso=PnaFow+mfHZyTKXe-2R6CdLLT9yq87x1Eg@mail.gmail.com>
	<CAKjRUT4nqtT8t0-WwpT+dEw_19=fzaYN=511u5cB8N8Wt7U2sw@mail.gmail.com>
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	<CAKjRUT7SmKKSQDkUJiFMW6=_TYmqCLiUoo_3Ur6Ui7HxsND5QQ@mail.gmail.com>
	<51549C3F.1020301@oracle.com>
	<CAKjRUT5JWQFLmbTh1+dmXPO56BprYCuMibiejdypL50GRqVHPw@mail.gmail.com>
Message-ID: <51563427.1030206@oracle.com>

Other thoughts - using chained buckets of edges instead of one single long list.  It would be easier to keep a pool of buckets (each holding, say, 256 edges?) than a "one-size-fits-all" pool of arrays.  Then all you have to do is keep high water marks on the number of simultaneously used buckets in order to tune the cache for a given application.

It would make the code that manages "pointers" to edges a little more complicated, though...

			...jim

On 3/29/2013 6:53 AM, Laurent Bourg?s wrote:
> Phil,
>
> I agree it is a complex issue to improve memory usage while maintaining
> performance at the JDK level: applications can use java2d pisces in very
> different contexts: Swing app (client with only EDT thread), server-side
> application (multi thread headless) ...
>
> For the moment, I spent a lot of my time understanding the different
> classes in java2d.pisces and analyzing memory usage / performance ... using
> J2DBench (all graphics tests).
>
> In my Swing application, pisces produces a lot of waste (GC) but on server
> side, the GC overhead can be more important if several threads use pisces.
>
> Pisces uses memory differently:
> - fixed arrays (dasher, stroker)
> - dynamic arrays (edges ...) rowAARLE (very big one for big shapes)
>
> For the moment I am trying to avoid memory waste (pooling or kept
> reference) without any memory constraint (no eviction) but I agree it is an
> important aspect for server-side applications.
>
> To avoid concurrency issues, I use a ThreadLocal context named
> RendererContext to keep few temporary arrays (float6 and a BIG rowAARLE
> instance) but there is also dynamic IntArrayCache et FloatArrayCache which
> have several pools divided in buckets (256, 1024, 4096, 16384, 32768)
> containing only few instances.
>
> To have best performance, I studied pisces code to clear only the used
> array parts when recycling or using dirty arrays (only clear
> rowAARLE[...][1]).
>
> I think Andrea's proposal is interesting to maybe put some system
> properties to give hints (low memory footprint, use cache or not ...).
>
> 2013/3/28 Phil Race <philip.race at oracle.com>
>
>> Maintaining a pool of objects might be an appropriate thing for an
>> applications,
>> but its a lot trickier for the platform as the application's usage pattern
>> or intent
>> is largely unknown. Weak references or soft references might be of use but
>> weak references usually go away even at the next incremental GC and soft
>> references tend to not go away at all until you run out of heap.
>>
>
> Agreed; for the moment, pool eviction policy is not implemented but kept in
> mind.
> FYI: each RendererContext (per thread) has its own array pools (not shared)
> that could have different caching policies:
> For instance, AWT / EDT (repaint) could use a large cache although other
> threads do not use array caching at all.
>
>
>> You may well be right that always doubling the array size may be too
>> simplistic,
>> but it would need some analysis of the code and its usage to see how much
>> better we can do.
>
>
> There is two part:
> - initial array size for dynamic arrays: difficult to estimate but for now
> set to very low capacity (8 / 50 ...) to avoid memory waste for rectangle /
> line shapes. In my patch, I have defined MIN_ARRAY_SIZE = 128 (array pool)
> to avoid too much resizing as I am doing array recycling.
> - grow: I use x4 instead of x2 to avoid array copies.
>
> Laurent
>
>
>
> 2013/3/28 Phil Race <philip.race at oracle.com>
>
>> Maintaining a pool of objects might be an appropriate thing for an
>> applications,
>> but its a lot trickier for the platform as the application's usage pattern
>> or intent
>> is largely unknown. Weak references or soft references might be of use but
>> weak references usually go away even at the next incremental GC and soft
>> references tend to not go away at all until you run out of heap.
>>
>> You may well be right that always doubling the array size may be too
>> simplistic,
>> but it would need some analysis of the code and its usage to see how much
>> better we can do.
>>
>>
>>> Apparently, Arrays.fill is always faster (size in 10 ... 10 000) !
>>> I suspect hotspot to optimize its code and use native functions, isn't
>> it ???
>>
>> I suppose there is some hotspot magic involved to recognise and intrinsify
>> this
>> method, since the source code looks like a plain old for loop.
>>
>> -phil.
>>
>>
>>
>> On 3/26/2013 4:00 AM, Laurent Bourg?s wrote:
>>
>>> Dear all,
>>>
>>> First I joined recently the openJDK contributors, and I plan to fix
>>> java2D pisces code in my spare time.
>>>
>>> I have a full time job on Aspro2: http://www.jmmc.fr/aspro; it is an
>>> application to prepare astronomical observations at VLTI / CHARA and is
>>> very used in our community (200 users): it provides scientific computations
>>> (observability, model images using complex numbers ...) and zoomable plots
>>> thanks to jFreeChart.
>>>
>>> Aspro2 is known to be very efficient (computation parallelization) and I
>>> am often doing profiling using netbeans profiler or visualVM.
>>>
>>> To fix huge memory usages by java2d.pisces, I started implementing an
>>> efficient ArrayCache (int[] and float[]) (in thread local to concurrency
>>> problems):
>>> - arrays in sizes between 10 and 10000 (more small arrays used than big
>>> ones)
>>> - resizing support (Arrays.copyOf) without wasting arrays
>>> - reentrance i.e. many arrays are used at the same time (java2D Pisces
>>> stroke / dash creates many segments to render)
>>> - GC / Heap friendly ie support cache eviction and avoid consuming too
>>> much memory
>>>
>>> I know object pooling is known to be not efficient with recent VM (GC is
>>> better) but I think it is counter productive to create so many int[] arrays
>>> in java2d.pisces and let the GC remove such wasted memory.
>>>
>>> Does someone have implemented such (open source) array cache (core-libs) ?
>>> Opinions are welcome (but avoid "trolls").
>>>
>>> Moreover, sun.java2d.pisces.Helpers.**widenArray() performs a lot of
>>> array resizing / copy (Arrays.copyOf) that I want to avoid mostly:
>>>      // These use a hardcoded factor of 2 for increasing sizes. Perhaps
>>> this
>>>      // should be provided as an argument.
>>>      static float[] widenArray(float[] in, final int cursize, final int
>>> numToAdd) {
>>>          if (in.length >= cursize + numToAdd) {
>>>              return in;
>>>          }
>>>          return Arrays.copyOf(in, 2 * (cursize + numToAdd));
>>>      }
>>>
>>>      static int[] widenArray(int[] in, final int cursize, final int
>>> numToAdd) {
>>>          if (in.length >= cursize + numToAdd) {
>>>              return in;
>>>          }
>>>          return Arrays.copyOf(in, 2 * (cursize + numToAdd));
>>>      }
>>>
>>> Thanks to Peter Levart, I use its microbench tool (
>>> https://github.com/plevart/**micro-bench/tree/v2<https://github.com/plevart/micro-bench/tree/v2>)
>>> to benchmark ArrayCache operations... and J2DBench to test java2d
>>> performances
>>>
>>> What is the fastest way to clear an array (part) ie fill by 0:
>>> - public static void fill(int[] a, int fromIndex, int toIndex, int val)
>>> - public static native void arraycopy(Object src,  int  srcPos, Object
>>> dest, int destPos, int length);
>>> - unsafe.setMemory(array, Unsafe.ARRAY_INT_BASE_OFFSET, 512 * SIZEOF_INT,
>>> (byte) 0)
>>>
>>> Apparently, Arrays.fill is always faster (size in 10 ... 10 000) !
>>> I suspect hotspot to optimize its code and use native functions, isn't it
>>> ???
>>>
>>> Benchmarks results:
>>>>> JVM START: 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>> Testing arrays: int[1]...
>>> #
>>> # ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
>>> #
>>> # Warm up:
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =      4,47 ns/op (? =   0,00 ns/op) [
>>> 4,47]
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =      4,40 ns/op (? =   0,00 ns/op) [
>>> 4,40]
>>> # Measure:
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =      4,43 ns/op (? =   0,00 ns/op) [
>>> 4,43]
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             2 threads, Tavg =      5,55 ns/op (? =   0,16 ns/op) [
>>> 5,40,      5,72]
>>>
>>> #
>>> # FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
>>> #
>>> # Warm up:
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =      6,47 ns/op (? =   0,00 ns/op) [
>>> 6,47]
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =      6,21 ns/op (? =   0,00 ns/op) [
>>> 6,21]
>>> # Measure:
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =      6,19 ns/op (? =   0,00 ns/op) [
>>> 6,19]
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             2 threads, Tavg =      7,80 ns/op (? =   0,10 ns/op) [
>>> 7,90,      7,71]
>>>
>>> #
>>> # FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
>>> #
>>> # Warm up:
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     26,82 ns/op (? =   0,00 ns/op) [
>>>   26,82]
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     23,48 ns/op (? =   0,00 ns/op) [
>>>   23,48]
>>> # Measure:
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     22,42 ns/op (? =   0,00 ns/op) [
>>>   22,42]
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             2 threads, Tavg =     28,21 ns/op (? =   0,88 ns/op) [
>>>   29,11,     27,36]
>>>
>>> Testing arrays: int[100]...
>>> #
>>> # ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
>>> #
>>> # Warm up:
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     16,49 ns/op (? =   0,00 ns/op) [
>>>   16,49]
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     15,97 ns/op (? =   0,00 ns/op) [
>>>   15,97]
>>> # Measure:
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     16,03 ns/op (? =   0,00 ns/op) [
>>>   16,03]
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             2 threads, Tavg =     19,32 ns/op (? =   0,46 ns/op) [
>>>   18,87,     19,80]
>>>
>>> #
>>> # FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
>>> #
>>> # Warm up:
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     14,51 ns/op (? =   0,00 ns/op) [
>>>   14,51]
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     14,17 ns/op (? =   0,00 ns/op) [
>>>   14,17]
>>> # Measure:
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     14,09 ns/op (? =   0,00 ns/op) [
>>>   14,09]
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             2 threads, Tavg =     31,15 ns/op (? =   4,04 ns/op) [
>>>   27,65,     35,67]
>>>
>>> #
>>> # FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
>>> #
>>> # Warm up:
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     52,32 ns/op (? =   0,00 ns/op) [
>>>   52,32]
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     52,82 ns/op (? =   0,00 ns/op) [
>>>   52,82]
>>> # Measure:
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =     52,19 ns/op (? =   0,00 ns/op) [
>>>   52,19]
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             2 threads, Tavg =     70,87 ns/op (? =   0,71 ns/op) [
>>>   70,17,     71,59]
>>>
>>> Testing arrays: int[10000]...
>>> #
>>> # ZeroFill: run duration:  5 000 ms, #of logical CPUS: 4
>>> #
>>> # Warm up:
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =  1 208,64 ns/op (? =   0,00 ns/op) [ 1
>>> 208,64]
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =  1 238,01 ns/op (? =   0,00 ns/op) [ 1
>>> 238,01]
>>> # Measure:
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =  1 235,81 ns/op (? =   0,00 ns/op) [ 1
>>> 235,81]
>>> runTest[class ArrayCacheBenchmark$ZeroFill] on JVM: 1.8.0-internal
>>> [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             2 threads, Tavg =  1 325,11 ns/op (? =   7,01 ns/op) [ 1
>>> 332,16,  1 318,14]
>>>
>>> #
>>> # FillArraySystemCopy: run duration:  5 000 ms, #of logical CPUS: 4
>>> #
>>> # Warm up:
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =  1 930,93 ns/op (? =   0,00 ns/op) [ 1
>>> 930,93]
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =  2 060,80 ns/op (? =   0,00 ns/op) [ 2
>>> 060,80]
>>> # Measure:
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =  2 105,21 ns/op (? =   0,00 ns/op) [ 2
>>> 105,21]
>>> runTest[class ArrayCacheBenchmark$**FillArraySystemCopy] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             2 threads, Tavg =  2 160,33 ns/op (? =  13,74 ns/op) [ 2
>>> 146,68,  2 174,15]
>>>
>>> #
>>> # FillArrayUnsafe: run duration:  5 000 ms, #of logical CPUS: 4
>>> #
>>> # Warm up:
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =  3 099,50 ns/op (? =   0,00 ns/op) [ 3
>>> 099,50]
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =  3 041,81 ns/op (? =   0,00 ns/op) [ 3
>>> 041,81]
>>> # Measure:
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             1 threads, Tavg =  3 068,34 ns/op (? =   0,00 ns/op) [ 3
>>> 068,34]
>>> runTest[class ArrayCacheBenchmark$**FillArrayUnsafe] on JVM:
>>> 1.8.0-internal [OpenJDK 64-Bit Server VM 25.0-b22]
>>>             2 threads, Tavg =  3 296,13 ns/op (? =  34,97 ns/op) [ 3
>>> 331,47,  3 261,53]
>>>
>>>
>>> PS: java.awt.geom.Path2D has also memory allocation issues:
>>>          void needRoom(boolean needMove, int newCoords) {
>>>              if (needMove && numTypes == 0) {
>>> throw new IllegalPathStateException("**missing initial moveto "+
>>> "in path definition");
>>>              }
>>>              int size = pointTypes.length;
>>>              if (numTypes >= size) {
>>> int grow = size;
>>>                  if (grow > EXPAND_MAX) {
>>> grow = EXPAND_MAX;
>>>                  }
>>> pointTypes = Arrays.copyOf(pointTypes, size+grow);
>>>              }
>>>              size = floatCoords.length;
>>>              if (numCoords + newCoords > size) {
>>> int grow = size;
>>>                  if (grow > EXPAND_MAX * 2) {
>>> grow = EXPAND_MAX * 2;
>>>                  }
>>>                  if (grow < newCoords) {
>>> grow = newCoords;
>>>                  }
>>> floatCoords = Arrays.copyOf(floatCoords, size+grow);
>>>              }
>>>          }
>>>
>>> Best regards,
>>> Laurent
>>>
>>
>>


From bourges.laurent at gmail.com  Sat Mar 30 12:38:32 2013
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Sat, 30 Mar 2013 13:38:32 +0100
Subject: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
In-Reply-To: <51563427.1030206@oracle.com>
References: <CAKjRUT67vJk7Tso=PnaFow+mfHZyTKXe-2R6CdLLT9yq87x1Eg@mail.gmail.com>
	<CAKjRUT4nqtT8t0-WwpT+dEw_19=fzaYN=511u5cB8N8Wt7U2sw@mail.gmail.com>
	<51506136.4020909@oracle.com> <51508139.9000507@oracle.com>
	<CAKjRUT7SmKKSQDkUJiFMW6=_TYmqCLiUoo_3Ur6Ui7HxsND5QQ@mail.gmail.com>
	<51549C3F.1020301@oracle.com>
	<CAKjRUT5JWQFLmbTh1+dmXPO56BprYCuMibiejdypL50GRqVHPw@mail.gmail.com>
	<51563427.1030206@oracle.com>
Message-ID: <CAKjRUT53Q7e2Lq-VeyhVhWNniTmWZLpxnGw2ged5azbnrF7nzA@mail.gmail.com>

Jim,

There are finally only few growable arrays (edges, curves, rowAARLE) and
now I have a working Pisces code (J2DBench pass OK) that performs better
than current (2x - 3x faster on dasher or big shapes) using only few
megabytes (Xmx32m) ...

Moreover, these arrays could be created once per thread (thread local) to
avoid GC (low footprint) and enhance performance (no GC / array resizing or
coyping) with an initial size of 4K or 16K representing only 16 x 4 = 65Kb !

The only array that causes troubles is the growable
PiscesCache.rowAARLE[Y][tuples] which Y size depends on the shape / clip
bounds and tuples depend on the crossing numbers at the current row Y.

For now I am using int[2048][20] but it could be tuned ...

Finally, I figured out several hard-coded values relative to AA (3x3
samples, error level ...) that could be set as rendering hints. For example
I would like to tune the number of samples to 8x8 or 2x2 ... depending on
the use case.

I expect to send an alpha version of my patch to illustrate my talks.

2013/3/30 Jim Graham <james.graham at oracle.com>

> Other thoughts - using chained buckets of edges instead of one single long
> list.  It would be easier to keep a pool of buckets (each holding, say, 256
> edges?) than a "one-size-fits-all" pool of arrays.  Then all you have to do
> is keep high water marks on the number of simultaneously used buckets in
> order to tune the cache for a given application.
>
> It would make the code that manages "pointers" to edges a little more
> complicated, though...
>

Good idea, but maybe difficult for me to implement. As I said, this array
may be less a problem than rowAARLE.

Of course, I need some "real life" tests to be able to perform better
diagnostics: maybe I could add some "instrumentations" / statistics to
gather while running in order to tune Pisces automatically depending on the
user work load.

Regards,
Laurent

On 3/29/2013 6:53 AM, Laurent Bourg?s wrote:

> Phil,
>
> I agree it is a complex issue to improve memory usage while maintaining
> performance at the JDK level: applications can use java2d pisces in very
> different contexts: Swing app (client with only EDT thread), server-side
> application (multi thread headless) ...
>
> For the moment, I spent a lot of my time understanding the different
> classes in java2d.pisces and analyzing memory usage / performance ... using
> J2DBench (all graphics tests).
>
> In my Swing application, pisces produces a lot of waste (GC) but on server
> side, the GC overhead can be more important if several threads use pisces.
>
> Pisces uses memory differently:
> - fixed arrays (dasher, stroker)
> - dynamic arrays (edges ...) rowAARLE (very big one for big shapes)
>
> For the moment I am trying to avoid memory waste (pooling or kept
> reference) without any memory constraint (no eviction) but I agree it is an
> important aspect for server-side applications.
>
> To avoid concurrency issues, I use a ThreadLocal context named
> RendererContext to keep few temporary arrays (float6 and a BIG rowAARLE
> instance) but there is also dynamic IntArrayCache et FloatArrayCache which
> have several pools divided in buckets (256, 1024, 4096, 16384, 32768)
> containing only few instances.
>
> To have best performance, I studied pisces code to clear only the used
> array parts when recycling or using dirty arrays (only clear
> rowAARLE[...][1]).
>
> I think Andrea's proposal is interesting to maybe put some system
> properties to give hints (low memory footprint, use cache or not ...).
>
> 2013/3/28 Phil Race <philip.race at oracle.com>
>
>  Maintaining a pool of objects might be an appropriate thing for an
>> applications,
>> but its a lot trickier for the platform as the application's usage pattern
>> or intent
>> is largely unknown. Weak references or soft references might be of use but
>> weak references usually go away even at the next incremental GC and soft
>> references tend to not go away at all until you run out of heap.
>>
>>
> Agreed; for the moment, pool eviction policy is not implemented but kept in
> mind.
> FYI: each RendererContext (per thread) has its own array pools (not shared)
> that could have different caching policies:
> For instance, AWT / EDT (repaint) could use a large cache although other
> threads do not use array caching at all.
>
>
>  You may well be right that always doubling the array size may be too
>> simplistic,
>> but it would need some analysis of the code and its usage to see how much
>> better we can do.
>>
>
>
> There is two part:
> - initial array size for dynamic arrays: difficult to estimate but for now
> set to very low capacity (8 / 50 ...) to avoid memory waste for rectangle /
> line shapes. In my patch, I have defined MIN_ARRAY_SIZE = 128 (array pool)
> to avoid too much resizing as I am doing array recycling.
> - grow: I use x4 instead of x2 to avoid array copies.
>
> Laurent
>
>
>
> 2013/3/28 Phil Race <philip.race at oracle.com>
>
>  Maintaining a pool of objects might be an appropriate thing for an
>> applications,
>> but its a lot trickier for the platform as the application's usage pattern
>> or intent
>> is largely unknown. Weak references or soft references might be of use but
>> weak references usually go away even at the next incremental GC and soft
>> references tend to not go away at all until you run out of heap.
>>
>> You may well be right that always doubling the array size may be too
>> simplistic,
>> but it would need some analysis of the code and its usage to see how much
>> better we can do.
>>
>>
>>  Apparently, Arrays.fill is always faster (size in 10 ... 10 000) !
>>> I suspect hotspot to optimize its code and use native functions, isn't
>>>
>> it ???
>>
>> I suppose there is some hotspot magic involved to recognise and intrinsify
>> this
>> method, since the source code looks like a plain old for loop.
>>
>> -phil.
>>
>>
>>
>> On 3/26/2013 4:00 AM, Laurent Bourg?s wrote:
>>
>>  Dear all,
>>>
>>> First I joined recently the openJDK contributors, and I plan to fix
>>> java2D pisces code in my spare time.
>>>
>>> I have a full time job on Aspro2: http://www.jmmc.fr/aspro; it is an
>>> application to prepare astronomical observations at VLTI / CHARA and is
>>> very used in our community (200 users): it provides scientific
>>> computations
>>> (observability, model images using complex numbers ...) and zoomable
>>> plots
>>> thanks to jFreeChart.
>>>
>>> Aspro2 is known to be very efficient (computation parallelization) and I
>>> am often doing profiling using netbeans profiler or visualVM.
>>>
>>> To fix huge memory usages by java2d.pisces, I started implementing an
>>> efficient ArrayCache (int[] and float[]) (in thread local to concurrency
>>> problems):
>>> - arrays in sizes between 10 and 10000 (more small arrays used than big
>>> ones)
>>> - resizing support (Arrays.copyOf) without wasting arrays
>>> - reentrance i.e. many arrays are used at the same time (java2D Pisces
>>> stroke / dash creates many segments to render)
>>> - GC / Heap friendly ie support cache eviction and avoid consuming too
>>> much memory
>>>
>>> I know object pooling is known to be not efficient with recent VM (GC is
>>> better) but I think it is counter productive to create so many int[]
>>> arrays
>>> in java2d.pisces and let the GC remove such wasted memory.
>>>
>>> Does someone have implemented such (open source) array cache (core-libs)
>>> ?
>>> Opinions are welcome (but avoid "trolls").
>>>
>>>
>>>
>>>