From Artem.Ananiev at Sun.COM  Mon Sep  1 07:02:15 2008
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Mon, 01 Sep 2008 18:02:15 +0400
Subject: <AWT Dev> splashscreen.so is missing pnggccrd.c
In-Reply-To: <1ccfd1c10808291046v193d7045vbd13cde154b7095@mail.gmail.com>
References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com>
	<48B28679.20900@sun.com>
	<1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com>
	<48B54D04.1000508@sun.com>
	<1ccfd1c10808271523v4db6e71bt990ea3d6123923fa@mail.gmail.com>
	<48B679C7.8060605@sun.com>
	<1ccfd1c10808280933i3266ff60x909cdad36273c791@mail.gmail.com>
	<48B7D17E.1090103@sun.com>
	<1ccfd1c10808291046v193d7045vbd13cde154b7095@mail.gmail.com>
Message-ID: <48BBF5E7.2070301@sun.com>


Martin Buchholz wrote:
> On Fri, Aug 29, 2008 at 3:37 AM, Anthony Petrov <Anthony.Petrov at sun.com> wrote:
>> On 08/28/2008 08:33 PM Martin Buchholz wrote:
>>> I'm thinking:
>>> - the MMX support is in pnggccrd.c,
>>> - but that file is never compiled in OpenJDK

Quick grep for PNG_MMX_CODE_SUPPORTED shows two .h files and six .c 
files in src/share/native/sun/awt/libpng directory, pnggccrd.c is only 
one of them, but what about others?

Thanks,

Artem

>> Why? There's the following line in the make/sun/splashscreen/Makefile:
>>
>> vpath %.c   $(SHARE_SRC)/native/$(PKGDIR)/libpng
>>
>> that effectively includes all *.c files in the libpng sources directory
>> (src/share/native/sun/awt/libpng/) in the compilation process.
> 
> Anthony,
> 
> I believe this is a small misunderstanding of how vpath works.
> vpath changes the _search path_ for files, but does not affect which
> files are actually compiled.   That is defined in
> make/sun/splashscreen/FILES_c.gmk
> and pnggccrd.c is notably absent from that file.
> If you actually try a clean build, on any platform,
> you will see no references to pnggccrd (or pngvcrd)
> in the logs (prove me wrong!).
> 
> Martin

From martinrb at google.com  Tue Sep  2 01:11:51 2008
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 2 Sep 2008 01:11:51 -0700
Subject: <AWT Dev> splashscreen.so is missing pnggccrd.c
In-Reply-To: <48BBF5E7.2070301@sun.com>
References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com>
	<48B28679.20900@sun.com>
	<1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com>
	<48B54D04.1000508@sun.com>
	<1ccfd1c10808271523v4db6e71bt990ea3d6123923fa@mail.gmail.com>
	<48B679C7.8060605@sun.com>
	<1ccfd1c10808280933i3266ff60x909cdad36273c791@mail.gmail.com>
	<48B7D17E.1090103@sun.com>
	<1ccfd1c10808291046v193d7045vbd13cde154b7095@mail.gmail.com>
	<48BBF5E7.2070301@sun.com>
Message-ID: <1ccfd1c10809020111g5530737bs78dfe509aaae31c2@mail.gmail.com>

Hi Artem and Anthony,

To understand this problem, please examine the snippet in pngconf.h

#  if !defined(PNG_MMX_CODE_SUPPORTED) && !defined(PNG_NO_MMX_CODE) && \
     defined(__MMX__)
#    define PNG_MMX_CODE_SUPPORTED
#  endif

The macro __MMX__ is defined if the gcc is configured to have mmx
support on by default.  You can reproduce the problem probably
most easily by modifying the makefiles to add the flag
"-mmmx" to the C compiler flags.

I believe this issue has existed for a while,
dependent on the way that gcc was configured.

Another way to examine the problem is to
look at the link error, failure to find png_combine_row,
and trace where this function is defined and how
it might be called.  The version of this function in
pngrutil.c is only defined if there is _no_ mmx support.

Martin

On Mon, Sep 1, 2008 at 07:02, Artem Ananiev <Artem.Ananiev at sun.com> wrote:
>
> Martin Buchholz wrote:
>>
>> On Fri, Aug 29, 2008 at 3:37 AM, Anthony Petrov <Anthony.Petrov at sun.com>
>> wrote:
>>>
>>> On 08/28/2008 08:33 PM Martin Buchholz wrote:
>>>>
>>>> I'm thinking:
>>>> - the MMX support is in pnggccrd.c,
>>>> - but that file is never compiled in OpenJDK
>
> Quick grep for PNG_MMX_CODE_SUPPORTED shows two .h files and six .c files in
> src/share/native/sun/awt/libpng directory, pnggccrd.c is only one of them,
> but what about others?
>
> Thanks,
>
> Artem
>
>>> Why? There's the following line in the make/sun/splashscreen/Makefile:
>>>
>>> vpath %.c   $(SHARE_SRC)/native/$(PKGDIR)/libpng
>>>
>>> that effectively includes all *.c files in the libpng sources directory
>>> (src/share/native/sun/awt/libpng/) in the compilation process.
>>
>> Anthony,
>>
>> I believe this is a small misunderstanding of how vpath works.
>> vpath changes the _search path_ for files, but does not affect which
>> files are actually compiled.   That is defined in
>> make/sun/splashscreen/FILES_c.gmk
>> and pnggccrd.c is notably absent from that file.
>> If you actually try a clean build, on any platform,
>> you will see no references to pnggccrd (or pngvcrd)
>> in the logs (prove me wrong!).
>>
>> Martin
>

From yamauchi at google.com  Fri Sep  5 13:20:53 2008
From: yamauchi at google.com (Hiroshi Yamauchi)
Date: Fri, 5 Sep 2008 13:20:53 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
Message-ID: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>

Hi,

I backported the change

  http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/93b6525e3b82

into OpenJDK6 b11 (the patch attached) to avoid JVM crashes in the
AsyncGetCallTrace(). The change appears to have been first introduced
in OpenJDK7 b27 (Hotspot v13-b01).

It'd be great if this patch can be reviewed and applied to future OpenJDK6
builds.

I understand that this may be a 'scary' patch considering the stable
nature of OpenJDK6. I'd appreciate it if the Hotspot folks can review and
comment on this patch.

Thanks,
Hiroshi
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: agct.txt
Url: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080905/1e5263f6/attachment-0001.txt 

From Daniel.Daugherty at Sun.COM  Mon Sep  8 14:48:37 2008
From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty)
Date: Mon, 08 Sep 2008 15:48:37 -0600
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
Message-ID: <48C59DB5.5040406@sun.com>

Can someone remind me which HSX version OpenJDK6-B11 is based on?

Compiler team, Steve G. had talked about back porting this fix
to earlier HSX releases (prior to HSX-13), but I don't believe
that he got to that task or handed off to anyone else on the
Compiler team prior to the unfortunate event at the end of June.

I reviewed Steve's original changes from an AsyncGetCallTrace()
point-of-view and I can review these change from the same POV,
but one or more folks on the compiler team is going to have to
look at these changes from the Compiler team POV...

Dan



Hiroshi Yamauchi wrote:
> Hi,
>
> I backported the change
>
>   http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/93b6525e3b82
>
> into OpenJDK6 b11 (the patch attached) to avoid JVM crashes in the
> AsyncGetCallTrace(). The change appears to have been first introduced
> in OpenJDK7 b27 (Hotspot v13-b01).
>
> It'd be great if this patch can be reviewed and applied to future OpenJDK6
> builds.
>
> I understand that this may be a 'scary' patch considering the stable
> nature of OpenJDK6. I'd appreciate it if the Hotspot folks can review and
> comment on this patch.
>
> Thanks,
> Hiroshi
>   

From Joe.Darcy at Sun.COM  Mon Sep  8 14:55:46 2008
From: Joe.Darcy at Sun.COM (Joe Darcy)
Date: Mon, 08 Sep 2008 14:55:46 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C59DB5.5040406@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com>
Message-ID: <48C59F62.4040806@sun.com>

Daniel D. Daugherty wrote:
> Can someone remind me which HSX version OpenJDK6-B11 is based on?

Currently in OpenJDK 6 we are on HS10, but we plan to upgrade to HS11 in 
the near future.

-Joe

>
> Compiler team, Steve G. had talked about back porting this fix
> to earlier HSX releases (prior to HSX-13), but I don't believe
> that he got to that task or handed off to anyone else on the
> Compiler team prior to the unfortunate event at the end of June.
>
> I reviewed Steve's original changes from an AsyncGetCallTrace()
> point-of-view and I can review these change from the same POV,
> but one or more folks on the compiler team is going to have to
> look at these changes from the Compiler team POV...
>
> Dan
>
>
>
> Hiroshi Yamauchi wrote:
>> Hi,
>>
>> I backported the change
>>
>>   http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/93b6525e3b82
>>
>> into OpenJDK6 b11 (the patch attached) to avoid JVM crashes in the
>> AsyncGetCallTrace(). The change appears to have been first introduced
>> in OpenJDK7 b27 (Hotspot v13-b01).
>>
>> It'd be great if this patch can be reviewed and applied to future 
>> OpenJDK6
>> builds.
>>
>> I understand that this may be a 'scary' patch considering the stable
>> nature of OpenJDK6. I'd appreciate it if the Hotspot folks can review 
>> and
>> comment on this patch.
>>
>> Thanks,
>> Hiroshi
>>   


From mark at klomp.org  Tue Sep  9 00:07:39 2008
From: mark at klomp.org (Mark Wielaard)
Date: Tue, 09 Sep 2008 09:07:39 +0200
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C59F62.4040806@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com>  <48C59F62.4040806@sun.com>
Message-ID: <1220944059.3348.4.camel@dijkstra.wildebeest.org>

On Mon, 2008-09-08 at 14:55 -0700, Joe Darcy wrote:
> Daniel D. Daugherty wrote:
> > Can someone remind me which HSX version OpenJDK6-B11 is based on?
> 
> Currently in OpenJDK 6 we are on HS10, but we plan to upgrade to HS11 in 
> the near future.

Are the HSX versions tagged in the mercurial repos somehow?
In hotspot_version there is a HS_MAJOR_VER, HS_MINOR_VER and
HS_BUILD_NUMBER, how do these numbers match up?

Thanks,

Mark


From Daniel.Daugherty at Sun.COM  Tue Sep  9 06:20:32 2008
From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty)
Date: Tue, 09 Sep 2008 07:20:32 -0600
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <1220944059.3348.4.camel@dijkstra.wildebeest.org>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
Message-ID: <48C67820.6080109@sun.com>

An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080909/e44f4b31/attachment.html 

From mark at klomp.org  Tue Sep  9 07:06:09 2008
From: mark at klomp.org (Mark Wielaard)
Date: Tue, 09 Sep 2008 16:06:09 +0200
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C67820.6080109@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com>
Message-ID: <1220969169.3348.8.camel@dijkstra.wildebeest.org>

Hi Daniel,

On Tue, 2008-09-09 at 07:20 -0600, Daniel D. Daugherty wrote:
> Mark Wielaard wrote: 
> > Are the HSX versions tagged in the mercurial repos somehow?
> > In hotspot_version there is a HS_MAJOR_VER, HS_MINOR_VER and
> > HS_BUILD_NUMBER, how do these numbers match up?
> 
> The hotspot_version should reflect the specific HSX version
> number and build of the snapshot used to create the repo.

Thanks. What is "the snapshot" in this case?
If I am interested in a specific HSX version, how would I find out when
that version was checked into the repo? Is there a way to match the
hotspot mercurial rev number to a HSX version number?

Cheers,

Mark


From Daniel.Daugherty at Sun.COM  Tue Sep  9 07:24:45 2008
From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty)
Date: Tue, 09 Sep 2008 08:24:45 -0600
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <1220969169.3348.8.camel@dijkstra.wildebeest.org>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com>
	<1220969169.3348.8.camel@dijkstra.wildebeest.org>
Message-ID: <48C6872D.7030707@sun.com>

An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080909/ae229d48/attachment.html 

From Joe.Darcy at Sun.COM  Tue Sep  9 09:00:36 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Tue, 09 Sep 2008 09:00:36 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C67820.6080109@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com>
Message-ID: <48C69DA4.8080901@sun.com>

Daniel D. Daugherty wrote:
> Mark Wielaard wrote:
>> On Mon, 2008-09-08 at 14:55 -0700, Joe Darcy wrote:
>>   
>>> Daniel D. Daugherty wrote:
>>>     
>>>> Can someone remind me which HSX version OpenJDK6-B11 is based on?
>>>>       
>>> Currently in OpenJDK 6 we are on HS10, but we plan to upgrade to HS11 in 
>>> the near future.
>>>     
>>
>> Are the HSX versions tagged in the mercurial repos somehow?
>> In hotspot_version there is a HS_MAJOR_VER, HS_MINOR_VER and
>> HS_BUILD_NUMBER, how do these numbers match up?
>>
>> Thanks,
>>
>> Mark
>>   
> 
> The hotspot_version should reflect the specific HSX version
> number and build of the snapshot used to create the repo. I
> don't know if the OpenJDK6 project is incrementing or
> changing those values in any way.

To date, we on OpenJDK 6 have not incremented the HSX version values. 
The listed version might be slightly off; we are basically using the 
same source as the HotSpot in 6u7, but with a few additional fixes.

-Joe


From mark at klomp.org  Tue Sep  9 09:15:07 2008
From: mark at klomp.org (Mark Wielaard)
Date: Tue, 09 Sep 2008 18:15:07 +0200
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C6872D.7030707@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com>
	<1220969169.3348.8.camel@dijkstra.wildebeest.org>
	<48C6872D.7030707@sun.com>
Message-ID: <1220976907.3348.17.camel@dijkstra.wildebeest.org>

Hi Daniel,

On Tue, 2008-09-09 at 08:24 -0600, Daniel D. Daugherty wrote:
> Mark Wielaard wrote: 
> > If I am interested in a specific HSX version, how would I find out when
> > that version was checked into the repo?
> 
> I believe you'll be able to figure that out from the "hg log"
> of the "make/hotspot_version" file. In theory, the folks who
> pushed the updates the "make/hotspot_version" file will have
> included some comment that indicates the change to the HSX
> version number. That should give you the changeset ID for the
> last change that comprises the specific HSX version.

Thanks. I see hg log -v will give me the information I was looking for
since HS_* numbers are updated in a specific commit. What does it mean
for each of these, HS_MAJOR_VER, HS_MINOR_VER and HS_BUILD_NUMBER, to be
incremented? Or is there no meaning attached and are they more or less
random, date based, tags?

> > Is there a way to match the
> > hotspot mercurial rev number to a HSX version number?  
> 
> See above reply. I don't think we're tagging the repros with
> the HSX version number, but perhaps we should. I know we tag
> the JDK7 repos with the JDK7 build number, but I don't think
> we tag the hotspot repos with the HSX version number.

I think that would be beneficial, if there is some meaning attached to
the specific numbers when they are increased. Then someone can make sure
they pick a "stable" or "production" ready version from the hotspot
(jdk7) repository to push into their project.

That is really why I asked, to make sure that I know that when we push
an hotspot version into icedtea (which comes with 2 different versions,
depending on whether or not you build against zero/shark) it is
something that is stable enough and something that the hotspot devs
wouldn't feel uncomfortable with being in a bit wider use.

Thanks,

Mark


From Daniel.Daugherty at Sun.COM  Wed Sep 10 15:34:08 2008
From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty)
Date: Wed, 10 Sep 2008 16:34:08 -0600
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C69DA4.8080901@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com>
Message-ID: <48C84B60.7000806@sun.com>

Joseph D. Darcy wrote:
> Daniel D. Daugherty wrote:
>> Mark Wielaard wrote:
>>> On Mon, 2008-09-08 at 14:55 -0700, Joe Darcy wrote:
>>>  
>>>> Daniel D. Daugherty wrote:
>>>>    
>>>>> Can someone remind me which HSX version OpenJDK6-B11 is based on?
>>>>>       
>>>> Currently in OpenJDK 6 we are on HS10, but we plan to upgrade to 
>>>> HS11 in the near future.
>>>>     
>>>
>>> Are the HSX versions tagged in the mercurial repos somehow?
>>> In hotspot_version there is a HS_MAJOR_VER, HS_MINOR_VER and
>>> HS_BUILD_NUMBER, how do these numbers match up?
>>>
>>> Thanks,
>>>
>>> Mark
>>>   
>>
>> The hotspot_version should reflect the specific HSX version
>> number and build of the snapshot used to create the repo. I
>> don't know if the OpenJDK6 project is incrementing or
>> changing those values in any way.
>
> To date, we on OpenJDK 6 have not incremented the HSX version values. 
> The listed version might be slightly off; we are basically using the 
> same source as the HotSpot in 6u7, but with a few additional fixes.
>
> -Joe

It seems to me that we have a versioning problem here. If the
HSX source in OpenJDK6 is not the same as the baseline HSX source,
then the HSX version number should _not_ be the same.

It might be appropriate to bump the minor version number and then
reset the build number. Something to make the HSX version identity
unique if the source code is indeed different.

Joe, this needs to be discussed with the HotSpot P-Team.

Dan


From mark at klomp.org  Wed Sep 10 15:41:22 2008
From: mark at klomp.org (Mark Wielaard)
Date: Thu, 11 Sep 2008 00:41:22 +0200
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C84B60.7000806@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com>
	<48C84B60.7000806@sun.com>
Message-ID: <1221086482.26700.10.camel@hermans.wildebeest.org>

Hi Daniel,

On Wed, 2008-09-10 at 16:34 -0600, Daniel D. Daugherty wrote:
> It seems to me that we have a versioning problem here. If the
> HSX source in OpenJDK6 is not the same as the baseline HSX source,
> then the HSX version number should _not_ be the same.
> 
> It might be appropriate to bump the minor version number and then
> reset the build number. Something to make the HSX version identity
> unique if the source code is indeed different.
> 
> Joe, this needs to be discussed with the HotSpot P-Team.

What is the HotSpot P-Team?

Thanks,

Mark


From Daniel.Daugherty at Sun.COM  Wed Sep 10 15:47:39 2008
From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty)
Date: Wed, 10 Sep 2008 16:47:39 -0600
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <1221086482.26700.10.camel@hermans.wildebeest.org>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com>
	<48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
Message-ID: <48C84E8B.6030001@sun.com>

P-Team stands for "Product Team" I think :-)

Those are the Sun folks that make the business decisions about
HotSpot Express. The HotSpot P-Team approved the current
versioning system that is used for HotSpot Express releases
so they need to be kept in the loop when there are issues
with HSX version numbers.

Dan


Mark Wielaard wrote:

> What is the HotSpot P-Team?
>   

From mark at klomp.org  Wed Sep 10 16:09:54 2008
From: mark at klomp.org (Mark Wielaard)
Date: Thu, 11 Sep 2008 01:09:54 +0200
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C84E8B.6030001@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com>
	<48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
Message-ID: <1221088194.26700.18.camel@hermans.wildebeest.org>

Hi Daniel,

On Wed, 2008-09-10 at 16:47 -0600, Daniel D. Daugherty wrote:
> P-Team stands for "Product Team" I think :-)
> 
> Those are the Sun folks that make the business decisions about
> HotSpot Express. The HotSpot P-Team approved the current
> versioning system that is used for HotSpot Express releases
> so they need to be kept in the loop when there are issues
> with HSX version numbers.

Thanks. Which brings a followup question. What is "HotSpot Express"?

The thing I am really after is making sure that the versions of hotspot
that we ship with IcedTea in the various GNU/Linux distributions are
good. We actually have two versions, one from openjdk6 with a couple of
backports from the openjdk7 hotspot repo for crashes found with running
various applications (like eclipse). And one older snapshot of the
hotspot from openjdk7 that is used to base the zero/shark port on. It
would be good if we coordinated on good known stable versions of hotspot
whenever possible.

Cheers,

Mark


From gnu_andrew at member.fsf.org  Wed Sep 10 16:16:28 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 11 Sep 2008 00:16:28 +0100
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <1221088194.26700.18.camel@hermans.wildebeest.org>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com>
	<48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
Message-ID: <17c6771e0809101616g4eeda5e9vee0017d06b0f138a@mail.gmail.com>

2008/9/11 Mark Wielaard <mark at klomp.org>:
> Hi Daniel,
>
> On Wed, 2008-09-10 at 16:47 -0600, Daniel D. Daugherty wrote:
>> P-Team stands for "Product Team" I think :-)
>>
>> Those are the Sun folks that make the business decisions about
>> HotSpot Express. The HotSpot P-Team approved the current
>> versioning system that is used for HotSpot Express releases
>> so they need to be kept in the loop when there are issues
>> with HSX version numbers.
>
> Thanks. Which brings a followup question. What is "HotSpot Express"?
>
> The thing I am really after is making sure that the versions of hotspot
> that we ship with IcedTea in the various GNU/Linux distributions are
> good. We actually have two versions, one from openjdk6 with a couple of
> backports from the openjdk7 hotspot repo for crashes found with running
> various applications (like eclipse). And one older snapshot of the
> hotspot from openjdk7 that is used to base the zero/shark port on. It
> would be good if we coordinated on good known stable versions of hotspot
> whenever possible.
>
> Cheers,
>
> Mark
>
>

We actually have 3 in total over the two IcedTea trees - the one in
OpenJDK6 b11, the one
used by the zero patch on IcedTea6 (snapshotted from b24 of OpenJDK7)
and the current
OpenJDK7 version in IcedTea.

Scary :)
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

From Daniel.Daugherty at Sun.COM  Wed Sep 10 17:39:40 2008
From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty)
Date: Wed, 10 Sep 2008 18:39:40 -0600
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <1221088194.26700.18.camel@hermans.wildebeest.org>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59DB5.5040406@sun.com> <48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com>
	<48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
Message-ID: <48C868CC.4050303@sun.com>

An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080910/91b09eef/attachment.html 

From gnu_andrew at member.fsf.org  Thu Sep 11 00:53:12 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 11 Sep 2008 08:53:12 +0100
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C868CC.4050303@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com>
	<48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
Message-ID: <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>

2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
> Mark Wielaard wrote:
>
> Hi Daniel,
>
> On Wed, 2008-09-10 at 16:47 -0600, Daniel D. Daugherty wrote:
>
>
> P-Team stands for "Product Team" I think :-)
>
> Those are the Sun folks that make the business decisions about
> HotSpot Express. The HotSpot P-Team approved the current
> versioning system that is used for HotSpot Express releases
> so they need to be kept in the loop when there are issues
> with HSX version numbers.
>
>
> Thanks. Which brings a followup question. What is "HotSpot Express"?
>
>
> Just the name given to the idea of releasing VMs independently
> of JDK/JRE releases. I'm sure someone else out there has a
> better definition... :-)
>

I think an OpenJDK glossary is in order, if we don't already have one... ;)

>
> The thing I am really after is making sure that the versions of hotspot
> that we ship with IcedTea in the various GNU/Linux distributions are
> good. We actually have two versions, one from openjdk6 with a couple of
> backports from the openjdk7 hotspot repo for crashes found with running
> various applications (like eclipse). And one older snapshot of the
> hotspot from openjdk7 that is used to base the zero/shark port on. It
> would be good if we coordinated on good known stable versions of hotspot
> whenever possible.
>
>
> I'll leave this part of the question to someone with the
> OpenJDK6 or OpenJDK7 projects.
>
> My interest in this whole thread is the AsyncGetCallTrace stuff. :-)
>
> Dan
>
>

FWIW, I don't see any change to the HS_ version numbers in our
patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
Given OpenJDK6 was derived from something like b20, I guess this is
not that strange.

--
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

From Daniel.Daugherty at Sun.COM  Thu Sep 11 06:22:10 2008
From: Daniel.Daugherty at Sun.COM (Daniel D. Daugherty)
Date: Thu, 11 Sep 2008 07:22:10 -0600
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com>
	<48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
Message-ID: <48C91B82.4020502@sun.com>

An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080911/e28b5ad1/attachment.html 

From gnu_andrew at member.fsf.org  Thu Sep 11 07:31:17 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 11 Sep 2008 15:31:17 +0100
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C91B82.4020502@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com>
	<48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C91B82.4020502@sun.com>
Message-ID: <17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>

2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
> Andrew John Hughes wrote:
>
> FWIW, I don't see any change to the HS_ version numbers in our
> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
> Given OpenJDK6 was derived from something like b20, I guess this is
> not that strange.
>
> JDK7-B24 has the following values:
>
>     HS_MAJOR_VER=12
>     HS_MINOR_VER=0
>     HS_BUILD_NUMBER=01
>
> Joe stated earlier in this thread that OpenJDK6 is based on
> HSX-10 so its values should not be the same. For 1.6.0_07,
> I see:
>
>     HS_MAJOR_VER=10
>     HS_MINOR_VER=0
>     HS_BUILD_NUMBER=23
>
> Dan
>
>
>

Hmmm...
Then either Gary's HotSpot patch doesn't update that file or OpenJDK6
is not based on the same as this 1.6.0_07 thing you mention.
I'll try and have a closer look later.
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

From Kelly.Ohair at Sun.COM  Thu Sep 11 09:23:06 2008
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Thu, 11 Sep 2008 09:23:06 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com>
	<48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
Message-ID: <48C945EA.2050505@sun.com>

A glossary like this:

    http://wikis.sun.com/display/OpenJdkBuilds/JDK+Glossary+of+Terms

???

-kto

Andrew John Hughes wrote:
> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>> Mark Wielaard wrote:
>>
>> Hi Daniel,
>>
>> On Wed, 2008-09-10 at 16:47 -0600, Daniel D. Daugherty wrote:
>>
>>
>> P-Team stands for "Product Team" I think :-)
>>
>> Those are the Sun folks that make the business decisions about
>> HotSpot Express. The HotSpot P-Team approved the current
>> versioning system that is used for HotSpot Express releases
>> so they need to be kept in the loop when there are issues
>> with HSX version numbers.
>>
>>
>> Thanks. Which brings a followup question. What is "HotSpot Express"?
>>
>>
>> Just the name given to the idea of releasing VMs independently
>> of JDK/JRE releases. I'm sure someone else out there has a
>> better definition... :-)
>>
> 
> I think an OpenJDK glossary is in order, if we don't already have one... ;)
> 
>> The thing I am really after is making sure that the versions of hotspot
>> that we ship with IcedTea in the various GNU/Linux distributions are
>> good. We actually have two versions, one from openjdk6 with a couple of
>> backports from the openjdk7 hotspot repo for crashes found with running
>> various applications (like eclipse). And one older snapshot of the
>> hotspot from openjdk7 that is used to base the zero/shark port on. It
>> would be good if we coordinated on good known stable versions of hotspot
>> whenever possible.
>>
>>
>> I'll leave this part of the question to someone with the
>> OpenJDK6 or OpenJDK7 projects.
>>
>> My interest in this whole thread is the AsyncGetCallTrace stuff. :-)
>>
>> Dan
>>
>>
> 
> FWIW, I don't see any change to the HS_ version numbers in our
> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
> Given OpenJDK6 was derived from something like b20, I guess this is
> not that strange.
> 
> --
> Andrew :-)
> 
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
> 
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

From Joe.Darcy at Sun.COM  Thu Sep 11 09:23:02 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Thu, 11 Sep 2008 09:23:02 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C59F62.4040806@sun.com>
	<1220944059.3348.4.camel@dijkstra.wildebeest.org>
	<48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com>
	<48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
Message-ID: <48C945E6.6090709@sun.com>

Andrew John Hughes wrote:
> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>> Mark Wielaard wrote:
>>
>> Hi Daniel,
>>
>> On Wed, 2008-09-10 at 16:47 -0600, Daniel D. Daugherty wrote:
>>
>>
>> P-Team stands for "Product Team" I think :-)
>>
>> Those are the Sun folks that make the business decisions about
>> HotSpot Express. The HotSpot P-Team approved the current
>> versioning system that is used for HotSpot Express releases
>> so they need to be kept in the loop when there are issues
>> with HSX version numbers.
>>
>>
>> Thanks. Which brings a followup question. What is "HotSpot Express"?
>>
>>
>> Just the name given to the idea of releasing VMs independently
>> of JDK/JRE releases. I'm sure someone else out there has a
>> better definition... :-)
>>
> 
> I think an OpenJDK glossary is in order, if we don't already have one... ;)

There is a a glossary as part of the OpenJDK Developers' guide:
http://openjdk.java.net/guide/glossary.html

However, it hasn't been updated in a while and it should be expanded to 
cover more terms.

-Joe

From Richard.Barnes at stratus.com  Thu Sep 11 07:26:21 2008
From: Richard.Barnes at stratus.com (Barnes, Richard)
Date: Thu, 11 Sep 2008 10:26:21 -0400
Subject: Java SE Internals for JDK6?
Message-ID: <EEEB1FA7BB798343BD171137F3E7FA538C5D9D@EXNA.corp.stratus.com>

I am a member of a team porting JDK6 to an unusual platform, a
big-endian software environment that runs on IA32.  Is there any
internals documentation available that might be useful in aiding our
effort.

Thanks,

Richard Barnes
Stratus Technologies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080911/8e624adc/attachment.html 

From gnu_andrew at member.fsf.org  Thu Sep 11 14:36:51 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 11 Sep 2008 22:36:51 +0100
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C945EA.2050505@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C67820.6080109@sun.com> <48C69DA4.8080901@sun.com>
	<48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C945EA.2050505@sun.com>
Message-ID: <17c6771e0809111436m3c914921x557a8611e5e5b2bf@mail.gmail.com>

2008/9/11 Kelly O'Hair <Kelly.Ohair at sun.com>:
> A glossary like this:
>
>   http://wikis.sun.com/display/OpenJdkBuilds/JDK+Glossary+of+Terms
>
> ???
>
> -kto
>
> Andrew John Hughes wrote:
>>
>> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>>>
>>> Mark Wielaard wrote:
>>>
>>> Hi Daniel,
>>>
>>> On Wed, 2008-09-10 at 16:47 -0600, Daniel D. Daugherty wrote:
>>>
>>>
>>> P-Team stands for "Product Team" I think :-)
>>>
>>> Those are the Sun folks that make the business decisions about
>>> HotSpot Express. The HotSpot P-Team approved the current
>>> versioning system that is used for HotSpot Express releases
>>> so they need to be kept in the loop when there are issues
>>> with HSX version numbers.
>>>
>>>
>>> Thanks. Which brings a followup question. What is "HotSpot Express"?
>>>
>>>
>>> Just the name given to the idea of releasing VMs independently
>>> of JDK/JRE releases. I'm sure someone else out there has a
>>> better definition... :-)
>>>
>>
>> I think an OpenJDK glossary is in order, if we don't already have one...
>> ;)
>>
>>> The thing I am really after is making sure that the versions of hotspot
>>> that we ship with IcedTea in the various GNU/Linux distributions are
>>> good. We actually have two versions, one from openjdk6 with a couple of
>>> backports from the openjdk7 hotspot repo for crashes found with running
>>> various applications (like eclipse). And one older snapshot of the
>>> hotspot from openjdk7 that is used to base the zero/shark port on. It
>>> would be good if we coordinated on good known stable versions of hotspot
>>> whenever possible.
>>>
>>>
>>> I'll leave this part of the question to someone with the
>>> OpenJDK6 or OpenJDK7 projects.
>>>
>>> My interest in this whole thread is the AsyncGetCallTrace stuff. :-)
>>>
>>> Dan
>>>
>>>
>>
>> FWIW, I don't see any change to the HS_ version numbers in our
>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
>> Given OpenJDK6 was derived from something like b20, I guess this is
>> not that strange.
>>
>> --
>> Andrew :-)
>>
>> Support Free Java!
>> Contribute to GNU Classpath and the OpenJDK
>> http://www.gnu.org/software/classpath
>> http://openjdk.java.net
>>
>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
>

Errr.... yes.. spot on.
I've linked that from the IcedTea wiki now.
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

From gnu_andrew at member.fsf.org  Thu Sep 11 15:10:08 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 11 Sep 2008 23:10:08 +0100
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C91B82.4020502@sun.com>
	<17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>
Message-ID: <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>

2008/9/11 Andrew John Hughes <gnu_andrew at member.fsf.org>:
> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>> Andrew John Hughes wrote:
>>
>> FWIW, I don't see any change to the HS_ version numbers in our
>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
>> Given OpenJDK6 was derived from something like b20, I guess this is
>> not that strange.
>>
>> JDK7-B24 has the following values:
>>
>>     HS_MAJOR_VER=12
>>     HS_MINOR_VER=0
>>     HS_BUILD_NUMBER=01
>>
>> Joe stated earlier in this thread that OpenJDK6 is based on
>> HSX-10 so its values should not be the same. For 1.6.0_07,
>> I see:
>>
>>     HS_MAJOR_VER=10
>>     HS_MINOR_VER=0
>>     HS_BUILD_NUMBER=23
>>
>> Dan
>>
>>
>>
>
> Hmmm...
> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6
> is not based on the same as this 1.6.0_07 thing you mention.
> I'll try and have a closer look later.
> --
> Andrew :-)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
>
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
>

IcedTea6 contains:

HS_MAJOR_VER=10
HS_MINOR_VER=0
HS_BUILD_NUMBER=19

IcedTea/b33 contains:

HS_MAJOR_VER=14
HS_MINOR_VER=0
HS_BUILD_NUMBER=01

icedtea-hotspot-6b11-7b24.patch only updates the src code and not
make/hotspot_version
so it's actually worryingly building a different version of HotSpot
from the one it thinks it is.
It will actually be 12-0-01 as you state, but will report 10-0-19.

Overall, it would be better to always build against the most recent
stable HotSpot tree if possible
rather than the one provided by the build drop.  Do we know what the
most stable would be?
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

From Joe.Darcy at Sun.COM  Thu Sep 11 16:42:13 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Thu, 11 Sep 2008 16:42:13 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C91B82.4020502@sun.com>
	<17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>
	<17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
Message-ID: <48C9ACD5.7030102@sun.com>

Andrew John Hughes wrote:
> 2008/9/11 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>>> Andrew John Hughes wrote:
>>>
>>> FWIW, I don't see any change to the HS_ version numbers in our
>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
>>> Given OpenJDK6 was derived from something like b20, I guess this is
>>> not that strange.
>>>
>>> JDK7-B24 has the following values:
>>>
>>>     HS_MAJOR_VER=12
>>>     HS_MINOR_VER=0
>>>     HS_BUILD_NUMBER=01
>>>
>>> Joe stated earlier in this thread that OpenJDK6 is based on
>>> HSX-10 so its values should not be the same. For 1.6.0_07,
>>> I see:
>>>
>>>     HS_MAJOR_VER=10
>>>     HS_MINOR_VER=0
>>>     HS_BUILD_NUMBER=23
>>>
>>> Dan
>>>
>>>
>>>
>> Hmmm...
>> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6
>> is not based on the same as this 1.6.0_07 thing you mention.
>> I'll try and have a closer look later.
>> --
>> Andrew :-)
>>
>> Support Free Java!
>> Contribute to GNU Classpath and the OpenJDK
>> http://www.gnu.org/software/classpath
>> http://openjdk.java.net
>>
>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
>>
> 
> IcedTea6 contains:
> 
> HS_MAJOR_VER=10
> HS_MINOR_VER=0
> HS_BUILD_NUMBER=19
> 
> IcedTea/b33 contains:
> 
> HS_MAJOR_VER=14
> HS_MINOR_VER=0
> HS_BUILD_NUMBER=01
> 
> icedtea-hotspot-6b11-7b24.patch only updates the src code and not
> make/hotspot_version
> so it's actually worryingly building a different version of HotSpot
> from the one it thinks it is.
> It will actually be 12-0-01 as you state, but will report 10-0-19.
> 
> Overall, it would be better to always build against the most recent
> stable HotSpot tree if possible
> rather than the one provided by the build drop.  Do we know what the
> most stable would be?

Generally, the HotSpot in the base OpenJDK 6 should be pretty stable. 
The policy I've implemented,
http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000005.html,
for the HotSpot in OpenJDK 6 is to track fixes in the 6 update releases, 
augmented with some other fixes for license corrections, gcc build 
issues, (and the occasional Eclipse crash).  The HotSpot in the base 
OpenJDK 6 code base is very close to the HotSpot in the currently 
shipping 6 update release.

-Joe

From martinrb at google.com  Thu Sep 11 16:44:07 2008
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 11 Sep 2008 16:44:07 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C91B82.4020502@sun.com>
	<17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>
	<17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
Message-ID: <1ccfd1c10809111644t1225f6f8rc6989de06f8b15cd@mail.gmail.com>

[+doko, who might be interested in this discussion on jdk6-dev at openjdk.java.net]

So...how come icedtea 6 (on Ubuntu Hardy) reports
a hotspot version number that is not an actual hotspot version number?
Should be "OpenJDK 64-Bit Server VM (build 10.0-b19, mixed mode)"

(martinrb at spraggett) ~ $ /usr/lib/jvm/java-6-openjdk/bin/java -version
java version "1.6.0_0"
OpenJDK  Runtime Environment (build 1.6.0_0-b11)
OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode)
(martinrb at spraggett) ~ $ dpkg -S /usr/lib/jvm/java-6-openjdk/bin/java
openjdk-6-jre-headless: /usr/lib/jvm/java-6-openjdk/bin/java
(martinrb at spraggett) ~ $ aptitude show openjdk-6-jre-headless
Package: openjdk-6-jre-headless
Version: 6b11-2ubuntu2
Maintainer: Ubuntu MOTU Developers <ubuntu-motu at lists.ubuntu.com>
...

Martin

On Thu, Sep 11, 2008 at 15:10, Andrew John Hughes
<gnu_andrew at member.fsf.org> wrote:
> 2008/9/11 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>>> Andrew John Hughes wrote:
>>>
>>> FWIW, I don't see any change to the HS_ version numbers in our
>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
>>> Given OpenJDK6 was derived from something like b20, I guess this is
>>> not that strange.
>>>
>>> JDK7-B24 has the following values:
>>>
>>>     HS_MAJOR_VER=12
>>>     HS_MINOR_VER=0
>>>     HS_BUILD_NUMBER=01
>>>
>>> Joe stated earlier in this thread that OpenJDK6 is based on
>>> HSX-10 so its values should not be the same. For 1.6.0_07,
>>> I see:
>>>
>>>     HS_MAJOR_VER=10
>>>     HS_MINOR_VER=0
>>>     HS_BUILD_NUMBER=23
>>>
>>> Dan
>>>
>>>
>>>
>>
>> Hmmm...
>> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6
>> is not based on the same as this 1.6.0_07 thing you mention.
>> I'll try and have a closer look later.
>> --
>> Andrew :-)
>>
>> Support Free Java!
>> Contribute to GNU Classpath and the OpenJDK
>> http://www.gnu.org/software/classpath
>> http://openjdk.java.net
>>
>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
>>
>
> IcedTea6 contains:
>
> HS_MAJOR_VER=10
> HS_MINOR_VER=0
> HS_BUILD_NUMBER=19
>
> IcedTea/b33 contains:
>
> HS_MAJOR_VER=14
> HS_MINOR_VER=0
> HS_BUILD_NUMBER=01
>
> icedtea-hotspot-6b11-7b24.patch only updates the src code and not
> make/hotspot_version
> so it's actually worryingly building a different version of HotSpot
> from the one it thinks it is.
> It will actually be 12-0-01 as you state, but will report 10-0-19.
>
> Overall, it would be better to always build against the most recent
> stable HotSpot tree if possible
> rather than the one provided by the build drop.  Do we know what the
> most stable would be?
> --
> Andrew :-)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
>
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
>

From gnu_andrew at member.fsf.org  Thu Sep 11 18:17:50 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 12 Sep 2008 02:17:50 +0100
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <1ccfd1c10809111644t1225f6f8rc6989de06f8b15cd@mail.gmail.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C91B82.4020502@sun.com>
	<17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>
	<17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
	<1ccfd1c10809111644t1225f6f8rc6989de06f8b15cd@mail.gmail.com>
Message-ID: <17c6771e0809111817p14bca28sabc5b89844076e82@mail.gmail.com>

2008/9/12 Martin Buchholz <martinrb at google.com>:
> [+doko, who might be interested in this discussion on jdk6-dev at openjdk.java.net]
>
> So...how come icedtea 6 (on Ubuntu Hardy) reports
> a hotspot version number that is not an actual hotspot version number?
> Should be "OpenJDK 64-Bit Server VM (build 10.0-b19, mixed mode)"
>
> (martinrb at spraggett) ~ $ /usr/lib/jvm/java-6-openjdk/bin/java -version
> java version "1.6.0_0"
> OpenJDK  Runtime Environment (build 1.6.0_0-b11)
> OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode)
> (martinrb at spraggett) ~ $ dpkg -S /usr/lib/jvm/java-6-openjdk/bin/java
> openjdk-6-jre-headless: /usr/lib/jvm/java-6-openjdk/bin/java
> (martinrb at spraggett) ~ $ aptitude show openjdk-6-jre-headless
> Package: openjdk-6-jre-headless
> Version: 6b11-2ubuntu2
> Maintainer: Ubuntu MOTU Developers <ubuntu-motu at lists.ubuntu.com>
> ...
>
> Martin
>
> On Thu, Sep 11, 2008 at 15:10, Andrew John Hughes
> <gnu_andrew at member.fsf.org> wrote:
>> 2008/9/11 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>>>> Andrew John Hughes wrote:
>>>>
>>>> FWIW, I don't see any change to the HS_ version numbers in our
>>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
>>>> Given OpenJDK6 was derived from something like b20, I guess this is
>>>> not that strange.
>>>>
>>>> JDK7-B24 has the following values:
>>>>
>>>>     HS_MAJOR_VER=12
>>>>     HS_MINOR_VER=0
>>>>     HS_BUILD_NUMBER=01
>>>>
>>>> Joe stated earlier in this thread that OpenJDK6 is based on
>>>> HSX-10 so its values should not be the same. For 1.6.0_07,
>>>> I see:
>>>>
>>>>     HS_MAJOR_VER=10
>>>>     HS_MINOR_VER=0
>>>>     HS_BUILD_NUMBER=23
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>>
>>> Hmmm...
>>> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6
>>> is not based on the same as this 1.6.0_07 thing you mention.
>>> I'll try and have a closer look later.
>>> --
>>> Andrew :-)
>>>
>>> Support Free Java!
>>> Contribute to GNU Classpath and the OpenJDK
>>> http://www.gnu.org/software/classpath
>>> http://openjdk.java.net
>>>
>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
>>>
>>
>> IcedTea6 contains:
>>
>> HS_MAJOR_VER=10
>> HS_MINOR_VER=0
>> HS_BUILD_NUMBER=19
>>
>> IcedTea/b33 contains:
>>
>> HS_MAJOR_VER=14
>> HS_MINOR_VER=0
>> HS_BUILD_NUMBER=01
>>
>> icedtea-hotspot-6b11-7b24.patch only updates the src code and not
>> make/hotspot_version
>> so it's actually worryingly building a different version of HotSpot
>> from the one it thinks it is.
>> It will actually be 12-0-01 as you state, but will report 10-0-19.
>>
>> Overall, it would be better to always build against the most recent
>> stable HotSpot tree if possible
>> rather than the one provided by the build drop.  Do we know what the
>> most stable would be?
>> --
>> Andrew :-)
>>
>> Support Free Java!
>> Contribute to GNU Classpath and the OpenJDK
>> http://www.gnu.org/software/classpath
>> http://openjdk.java.net
>>
>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
>>
>

All IcedTea builds are like this:

$ java -version
java version "1.6.0_0"
OpenJDK  Runtime Environment (build 1.6.0_0-b11)
OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode)

$ ~/builder/icedtea/openjdk/build/linux-amd64/bin/java -version
java version "1.7.0_0"
IcedTea Runtime Environment (build 1.7.0_0-b33)
OpenJDK 64-Bit Server VM (build 1.7.0_0-b33, mixed mode)

-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

From Paul.Hohensee at Sun.COM  Thu Sep 11 17:19:29 2008
From: Paul.Hohensee at Sun.COM (Paul Hohensee)
Date: Thu, 11 Sep 2008 20:19:29 -0400
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C91B82.4020502@sun.com>
	<17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>
	<17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
Message-ID: <48C9B591.9020308@sun.com>

The most stable version will vary.  We'd like the openjdk version to be 
product-ready,
but we haven't been able to do that yet.  For now the most stable 
version is 6-open,
which is hotspot 10 plus fixes.  When 6u10 ships, our plan is to push 
the vm that
comes with it (hotspot 11) into 6-open.

Paul

Andrew John Hughes wrote:
> 2008/9/11 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>   
>> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>>     
>>> Andrew John Hughes wrote:
>>>
>>> FWIW, I don't see any change to the HS_ version numbers in our
>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
>>> Given OpenJDK6 was derived from something like b20, I guess this is
>>> not that strange.
>>>
>>> JDK7-B24 has the following values:
>>>
>>>     HS_MAJOR_VER=12
>>>     HS_MINOR_VER=0
>>>     HS_BUILD_NUMBER=01
>>>
>>> Joe stated earlier in this thread that OpenJDK6 is based on
>>> HSX-10 so its values should not be the same. For 1.6.0_07,
>>> I see:
>>>
>>>     HS_MAJOR_VER=10
>>>     HS_MINOR_VER=0
>>>     HS_BUILD_NUMBER=23
>>>
>>> Dan
>>>
>>>
>>>
>>>       
>> Hmmm...
>> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6
>> is not based on the same as this 1.6.0_07 thing you mention.
>> I'll try and have a closer look later.
>> --
>> Andrew :-)
>>
>> Support Free Java!
>> Contribute to GNU Classpath and the OpenJDK
>> http://www.gnu.org/software/classpath
>> http://openjdk.java.net
>>
>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
>>
>>     
>
> IcedTea6 contains:
>
> HS_MAJOR_VER=10
> HS_MINOR_VER=0
> HS_BUILD_NUMBER=19
>
> IcedTea/b33 contains:
>
> HS_MAJOR_VER=14
> HS_MINOR_VER=0
> HS_BUILD_NUMBER=01
>
> icedtea-hotspot-6b11-7b24.patch only updates the src code and not
> make/hotspot_version
> so it's actually worryingly building a different version of HotSpot
> from the one it thinks it is.
> It will actually be 12-0-01 as you state, but will report 10-0-19.
>
> Overall, it would be better to always build against the most recent
> stable HotSpot tree if possible
> rather than the one provided by the build drop.  Do we know what the
> most stable would be?
>   

From doko at ubuntu.com  Fri Sep 12 10:01:13 2008
From: doko at ubuntu.com (Matthias Klose)
Date: Fri, 12 Sep 2008 19:01:13 +0200
Subject: Adding version info for a package?
Message-ID: <48CAA059.1050006@ubuntu.com>

How to add version information for a package build?

$ java -version
java version "1.6.0_0"
OpenJDK  Runtime Environment (build 1.6.0_0-b11)
OpenJDK Server VM (build 1.6.0_0-b11, mixed mode)

does changing this to

$ java -version
java version "1.6.0_0"
OpenJDK  Runtime Environment (build 1.6.0_0-b11, Ubuntu 6b11-1ubuntu1)
OpenJDK Server VM (build 1.6.0_0-b11, mixed mode)

break something? Or should an extra line be added (same thing for the crash report)?

  Matthias

From David.Herron at Sun.COM  Fri Sep 12 11:01:08 2008
From: David.Herron at Sun.COM (David Herron)
Date: Fri, 12 Sep 2008 11:01:08 -0700
Subject: Adding version info for a package?
In-Reply-To: <48CAA059.1050006@ubuntu.com>
References: <48CAA059.1050006@ubuntu.com>
Message-ID: <48CAAE64.1020302@sun.com>

Matthias Klose wrote:
> How to add version information for a package build?
>
> $ java -version
> java version "1.6.0_0"
> OpenJDK  Runtime Environment (build 1.6.0_0-b11)
> OpenJDK Server VM (build 1.6.0_0-b11, mixed mode)
>
> does changing this to
>
> $ java -version
> java version "1.6.0_0"
> OpenJDK  Runtime Environment (build 1.6.0_0-b11, Ubuntu 6b11-1ubuntu1)
> OpenJDK Server VM (build 1.6.0_0-b11, mixed mode)
>
> break something? Or should an extra line be added (same thing for the crash report)?
>
>   Matthias
>   

The exact syntax of the -version output isn't well specified.  But there 
is a guideline here:- http://java.sun.com/j2se/versioning_naming.html

That suggests you might use:  1.6.0_0-b11-1ubuntu1 ??

Are you also modifying the value of the system property java.version ??

Another thought is the -version:string option which the java command 
uses to select from multiple versions.   Okay, sure, Ubuntu has its own 
alternatives mechanism, but you could also modify the handling of 
-version:string and how would your modified version string affect this?

Related docs

http://java.sun.com/javase/6/docs/technotes/guides/versioning/spec/versioningTOC.html

http://java.sun.com/javase/6/docs/api/java/lang/System.html#getProperties()

http://java.sun.com/javase/6/docs/technotes/tools/solaris/java.html

From Joe.Darcy at Sun.COM  Fri Sep 12 11:10:23 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Fri, 12 Sep 2008 11:10:23 -0700
Subject: OpenJDK 6 build 12 source posted
Message-ID: <48CAB08F.6010407@sun.com>

Somewhat later than anticipated, the source bundle for OpenJDK 6 build 
12 is available for download from:

    http://download.java.net/openjdk/jdk6/

There are a few changes of note in this build:

* An updated version of Gervill is included. [1]

* Functionality of several IcedTea patches which correct JCK failures 
have been applied. [2]

* I've ported fixes from the forthcoming 6u10 release in the corba, 
jaxp, jaxws, and langtools areas to OpenJDK 6. [3]

* Various build fixes, including the gcc ciTypeFlow.cpp issue. [4]

* Corrected more legal notices. [5]

* Configuration information for some networking tests can now be 
provided as a properties files specified on the jtreg command line. [6]

* Assorted other fixes. [7]

While the changes in this build have corrected a number of JCK 6b test 
failures, a handful of tests still fail; eliminating those few 
remaining  failures is a goal for the next build or two.

Internally, the code for OpenJDK 6 is split into teamware workspaces 
with a similar structure to the JDK 7 Mercurial repositories (corba, 
jaxp, jaxws, langtools, jdk, etc.).  For a subset of those component 
workspaces, I've brought over the fixes in those areas from 6u10.  
OpenJDK 6 build 12 will be one of the last teamware-based OpenJDK 6 
builds before we transition to a public Mercurial repository.  Around 
the time of the Mercurial transition we will also upgrade the HotSpot in 
OpenJDK 6 from HotSpot 10 to HotSpot 11; HotSpot 11 is also being used 
in 6u10.  From that point on, the same HotSpot sources will be used for 
both OpenJDK 6 and the 6 update releases.

I expect the next build within a few weeks with the Mercurial repository 
to follow a few weeks after that.

-Joe

[1] OpenJDK 6 build 12 uses a version of Gervill from late August 2008.
6717691 Update Gervill with post 1.0 fixes
6740210 Update Gervill with more post 1.0 fixes

[2] The patches used to fix these two bugs were contributed by Keith 
Seitz and Tom Fitzsimmons:

6735154 Apply IcedTea Color.createContext patch
6733501 Apply IcedTea little cms patches [Alexey.Ushakov at Sun.COM]

They correspond to the three IcedTea patches:

icedtea-color-createcontext.patch Add support for a PaintContext to 
java.awt.Color.
icedtea-lcms-leak.patch: Fix LCMS memory leak.
icedtea-LCMS-setTagData.patch: Add support for setTagData to LCMS peer.

[3] The follow bug fixes were ported from 6u10 into OpenJDK 6.

 corba
========

6372405 Server thread hangs when fragments don't complete because of 
connection abort
5104239 Java: thread deadlock
6191561 JCK15: 
api/org_omg/PortableInterceptor/ClientRequestInfo/index.html#RIMethods 
sometime hang
6486322 org.omg.CORBA.ORB.init() thread safety issue
6465377 Null pointer exception with RMI ORB in 1.5.0_08
6553303 Corba application fails w/ org.omg.CORBA.COMM_FAILURE: vmcid: 
SUN minor code: 203 completed: No
6372405 Server thread hangs when fragments don't complete because of 
connection abort
6438259 Wrong repository ID generated by IDL


 jaxp
=======

6573268 Four JCK-devtools-6a tests report OOM: Java Heap space since 
JDK7 b14
6738894 Merge jaxp fixes from 6 update train into OpenJDK 6


 jaxws (JAF 1.1.1)
====================

6538484 Fix JAF in Turkish locale
6699090 Avoid NPE if parse fails in isMimeTypeEqual, do a string 
comparison instead


 langtools
===========

6627362 javac generates code that uses array.clone, which is not 
available on JavaCard
6627364 javac needs Float and Double on the bootclasspath even when not 
directly used
6627366 javac needs Cloneable and Serializable on the classpath even 
when not directly used
6176978 current Javadoc's invocation and extension (Doclet) mechanisms 
are problematic

[4] Build fixes:

6732815 CORBA_2_3 java sources not explicitly compiled
6734545 Corrections to missing explicit corba sources on javac compile lines
6590549 Cygwin build of OpenJDK has problems and not very well documented
6720240 IOB exception when getting font metrics of hershey font
6548261 Use of SE in make/common/Defs-windows.gmk
6681798 (build) CharsetEncoder.java fails to compile in openjdk6 on 
ubutu 8.04
6741642 Crash in ciTypeFlow.cpp (see icedtea-hotspot-citypeflow.patch)

[5] Licensing fixes:

6635663 make/tools/AutoMulti/{AutoMulti,TestALFGenerator}.java still 
generate files with wrong legal notices
6719182 update legal notice in java/lang/instrument/package.html

[6] See the source of jdk/test/TestEnv.java for details on how to set 
the networking configuration without modifying the test sources.

6720349 (ch) Channels tests depending on hosts inside Sun

[7] Other fixes:

6681889 JSN security test headline/noWarningApp failed with NPE exception
6739302 Check that deserialization preserves EnumSet integrity
6730743 (tz) Support tzdata2008e


From Joe.Darcy at Sun.COM  Fri Sep 12 11:37:18 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Fri, 12 Sep 2008 11:37:18 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48C9ACD5.7030102@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C69DA4.8080901@sun.com> <48C84B60.7000806@sun.com>
	<1221086482.26700.10.camel@hermans.wildebeest.org>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C91B82.4020502@sun.com>
	<17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>
	<17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
	<48C9ACD5.7030102@sun.com>
Message-ID: <48CAB6DE.8070806@sun.com>

Joseph D. Darcy wrote:
> Andrew John Hughes wrote:
>> 2008/9/11 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>>>> Andrew John Hughes wrote:
>>>>
>>>> FWIW, I don't see any change to the HS_ version numbers in our
>>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
>>>> Given OpenJDK6 was derived from something like b20, I guess this is
>>>> not that strange.
>>>>
>>>> JDK7-B24 has the following values:
>>>>
>>>>     HS_MAJOR_VER=12
>>>>     HS_MINOR_VER=0
>>>>     HS_BUILD_NUMBER=01
>>>>
>>>> Joe stated earlier in this thread that OpenJDK6 is based on
>>>> HSX-10 so its values should not be the same. For 1.6.0_07,
>>>> I see:
>>>>
>>>>     HS_MAJOR_VER=10
>>>>     HS_MINOR_VER=0
>>>>     HS_BUILD_NUMBER=23
>>>>
>>>> Dan
>>>>
>>>>
>>>>
>>> Hmmm...
>>> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6
>>> is not based on the same as this 1.6.0_07 thing you mention.
>>> I'll try and have a closer look later.
>>> -- 
>>> Andrew :-)
>>>
>>> Support Free Java!
>>> Contribute to GNU Classpath and the OpenJDK
>>> http://www.gnu.org/software/classpath
>>> http://openjdk.java.net
>>>
>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
>>>
>>
>> IcedTea6 contains:
>>
>> HS_MAJOR_VER=10
>> HS_MINOR_VER=0
>> HS_BUILD_NUMBER=19
>>
>> IcedTea/b33 contains:
>>
>> HS_MAJOR_VER=14
>> HS_MINOR_VER=0
>> HS_BUILD_NUMBER=01
>>
>> icedtea-hotspot-6b11-7b24.patch only updates the src code and not
>> make/hotspot_version
>> so it's actually worryingly building a different version of HotSpot
>> from the one it thinks it is.
>> It will actually be 12-0-01 as you state, but will report 10-0-19.
>>
>> Overall, it would be better to always build against the most recent
>> stable HotSpot tree if possible
>> rather than the one provided by the build drop.  Do we know what the
>> most stable would be?
>
> Generally, the HotSpot in the base OpenJDK 6 should be pretty stable. 
> The policy I've implemented,
> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000005.html, 
>
> for the HotSpot in OpenJDK 6 is to track fixes in the 6 update 
> releases, augmented with some other fixes for license corrections, gcc 
> build issues, (and the occasional Eclipse crash).  The HotSpot in the 
> base OpenJDK 6 code base is very close to the HotSpot in the currently 
> shipping 6 update release.

... and going forward we will have much closer coordination between the 
OpenJDK 6 and 6 update HotSpots since we'll be using the same source for 
both; so the version information should be updated consistently, etc.

http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-September/000150.html

-Joe

From Joe.Darcy at Sun.COM  Fri Sep 12 12:09:48 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Fri, 12 Sep 2008 12:09:48 -0700
Subject: Java SE Internals for JDK6?
In-Reply-To: <EEEB1FA7BB798343BD171137F3E7FA538C5D9D@EXNA.corp.stratus.com>
References: <EEEB1FA7BB798343BD171137F3E7FA538C5D9D@EXNA.corp.stratus.com>
Message-ID: <48CABE7C.5080805@sun.com>

Barnes, Richard wrote:
>
> I am a member of a team porting JDK6 to an unusual platform, a 
> big-endian software environment that runs on IA32.  Is there any 
> internals documentation available that might be useful in aiding our 
> effort.
>
> Thanks,
>
> Richard Barnes
> Stratus Technologies
>

For community advice on porting the OpenJDK code base, you may want to 
check in with the Porters Group:

http://openjdk.java.net/groups/porters/

-Joe


From gnu_andrew at member.fsf.org  Fri Sep 12 14:49:43 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 12 Sep 2008 22:49:43 +0100
Subject: OpenJDK 6 build 12 source posted
In-Reply-To: <48CAB08F.6010407@sun.com>
References: <48CAB08F.6010407@sun.com>
Message-ID: <17c6771e0809121449tf6ed78eq349c13d3e5c8da45@mail.gmail.com>

2008/9/12 Joseph D. Darcy <Joe.Darcy at sun.com>:
> Somewhat later than anticipated, the source bundle for OpenJDK 6 build 12 is
> available for download from:
>
>   http://download.java.net/openjdk/jdk6/
>
> There are a few changes of note in this build:
>
> * An updated version of Gervill is included. [1]
>
> * Functionality of several IcedTea patches which correct JCK failures have
> been applied. [2]
>
> * I've ported fixes from the forthcoming 6u10 release in the corba, jaxp,
> jaxws, and langtools areas to OpenJDK 6. [3]
>
> * Various build fixes, including the gcc ciTypeFlow.cpp issue. [4]
>
> * Corrected more legal notices. [5]
>
> * Configuration information for some networking tests can now be provided as
> a properties files specified on the jtreg command line. [6]
>
> * Assorted other fixes. [7]
>
> While the changes in this build have corrected a number of JCK 6b test
> failures, a handful of tests still fail; eliminating those few remaining
>  failures is a goal for the next build or two.
>
> Internally, the code for OpenJDK 6 is split into teamware workspaces with a
> similar structure to the JDK 7 Mercurial repositories (corba, jaxp, jaxws,
> langtools, jdk, etc.).  For a subset of those component workspaces, I've
> brought over the fixes in those areas from 6u10.  OpenJDK 6 build 12 will be
> one of the last teamware-based OpenJDK 6 builds before we transition to a
> public Mercurial repository.  Around the time of the Mercurial transition we
> will also upgrade the HotSpot in OpenJDK 6 from HotSpot 10 to HotSpot 11;
> HotSpot 11 is also being used in 6u10.  From that point on, the same HotSpot
> sources will be used for both OpenJDK 6 and the 6 update releases.
>
> I expect the next build within a few weeks with the Mercurial repository to
> follow a few weeks after that.
>
> -Joe
>
> [1] OpenJDK 6 build 12 uses a version of Gervill from late August 2008.
> 6717691 Update Gervill with post 1.0 fixes
> 6740210 Update Gervill with more post 1.0 fixes
>
> [2] The patches used to fix these two bugs were contributed by Keith Seitz
> and Tom Fitzsimmons:
>
> 6735154 Apply IcedTea Color.createContext patch
> 6733501 Apply IcedTea little cms patches [Alexey.Ushakov at Sun.COM]
>
> They correspond to the three IcedTea patches:
>
> icedtea-color-createcontext.patch Add support for a PaintContext to
> java.awt.Color.
> icedtea-lcms-leak.patch: Fix LCMS memory leak.
> icedtea-LCMS-setTagData.patch: Add support for setTagData to LCMS peer.
>
> [3] The follow bug fixes were ported from 6u10 into OpenJDK 6.
>
> corba
> ========
>
> 6372405 Server thread hangs when fragments don't complete because of
> connection abort
> 5104239 Java: thread deadlock
> 6191561 JCK15:
> api/org_omg/PortableInterceptor/ClientRequestInfo/index.html#RIMethods
> sometime hang
> 6486322 org.omg.CORBA.ORB.init() thread safety issue
> 6465377 Null pointer exception with RMI ORB in 1.5.0_08
> 6553303 Corba application fails w/ org.omg.CORBA.COMM_FAILURE: vmcid: SUN
> minor code: 203 completed: No
> 6372405 Server thread hangs when fragments don't complete because of
> connection abort
> 6438259 Wrong repository ID generated by IDL
>
>
> jaxp
> =======
>
> 6573268 Four JCK-devtools-6a tests report OOM: Java Heap space since JDK7
> b14
> 6738894 Merge jaxp fixes from 6 update train into OpenJDK 6
>
>
> jaxws (JAF 1.1.1)
> ====================
>
> 6538484 Fix JAF in Turkish locale
> 6699090 Avoid NPE if parse fails in isMimeTypeEqual, do a string comparison
> instead
>
>
> langtools
> ===========
>
> 6627362 javac generates code that uses array.clone, which is not available
> on JavaCard
> 6627364 javac needs Float and Double on the bootclasspath even when not
> directly used
> 6627366 javac needs Cloneable and Serializable on the classpath even when
> not directly used
> 6176978 current Javadoc's invocation and extension (Doclet) mechanisms are
> problematic
>
> [4] Build fixes:
>
> 6732815 CORBA_2_3 java sources not explicitly compiled
> 6734545 Corrections to missing explicit corba sources on javac compile lines
> 6590549 Cygwin build of OpenJDK has problems and not very well documented
> 6720240 IOB exception when getting font metrics of hershey font
> 6548261 Use of SE in make/common/Defs-windows.gmk
> 6681798 (build) CharsetEncoder.java fails to compile in openjdk6 on ubutu
> 8.04
> 6741642 Crash in ciTypeFlow.cpp (see icedtea-hotspot-citypeflow.patch)
>
> [5] Licensing fixes:
>
> 6635663 make/tools/AutoMulti/{AutoMulti,TestALFGenerator}.java still
> generate files with wrong legal notices
> 6719182 update legal notice in java/lang/instrument/package.html
>
> [6] See the source of jdk/test/TestEnv.java for details on how to set the
> networking configuration without modifying the test sources.
>
> 6720349 (ch) Channels tests depending on hosts inside Sun
>
> [7] Other fixes:
>
> 6681889 JSN security test headline/noWarningApp failed with NPE exception
> 6739302 Check that deserialization preserves EnumSet integrity
> 6730743 (tz) Support tzdata2008e
>
>

Thanks for being so through in describing the changes in b12.
This is of great help when updating IcedTea6 :)

Cheers,
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

From fw at deneb.enyo.de  Sat Sep 13 01:27:19 2008
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sat, 13 Sep 2008 10:27:19 +0200
Subject: [patch] fix build on architectures with a signed size_t
In-Reply-To: <4895EC16.6030406@ubuntu.com> (Matthias Klose's message of "Sun, 
	03 Aug 2008 19:34:14 +0200")
References: <4895EC16.6030406@ubuntu.com>
Message-ID: <8763p0mowo.fsf@mid.deneb.enyo.de>

* Matthias Klose:

> attached are three patches to build on architectures with a signed size_t
> (s390-linux-gnu).
>
>  - jdk-signed-size_t.diff, there's already a compat SSIZE_T macro in the code,
>    just use it.
>
>  - hotspot-idx_t-signed-size_t.diff, the BitMap code assumes a unsigned
>    size_t.
>
>  - hotspot-params-signed-size_t.diff, command line parameters of type
>    size_t currently are not supported. As a workaround, add casts. This
>    may be better addressed.

So what has happened to this patch?

From mark at klomp.org  Sun Sep 14 01:52:27 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 14 Sep 2008 10:52:27 +0200
Subject: Mercurial repo for openjdk6 drops
Message-ID: <1221382347.22691.29.camel@hermans.wildebeest.org>

Hi,

To make it easier to examine the various changes that go into openjdk6 I
imported all tar balls into a mercurial repo that you can hg clone and
hg diff as much as you like.
hg clone http://icedtea.classpath.org/hg/openjdk6
(It is approx. 175 MB or 500MB for a fully exploded bxx.)

The import was basically done by going over each tar ball and date for a
bxx drop from b05 (2008-02-12) till b12 (2008-08-28) and do:
$ rm -rf *
$ tar zxf ../openjdk-6-src-b[XX]*.gz 
$ hg addremove -s 95
$ hg commit -m "Import b[XX]" -d [date]
$ hg tag -d [date] b[XX]

I'll keep it up to date with any future openjdk6 drops.

Cheers,

Mark


From mark at klomp.org  Sun Sep 14 07:16:30 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 14 Sep 2008 16:16:30 +0200
Subject: OpenJDK 6 build 12 source posted (corba, jaxp, jaxws)
In-Reply-To: <48CAB08F.6010407@sun.com>
References: <48CAB08F.6010407@sun.com>
Message-ID: <1221401790.3542.32.camel@dijkstra.wildebeest.org>

Hi Joe,

Andrew and Matthias did all the hard work to integrate this with
icedtea6 already. Going through the diffs now that the source drops have
been imported into http://icedtea.classpath.org/hg/openjdk6 and some of
the changes needed in IcedTea I had some comments questions.

On Fri, 2008-09-12 at 11:10 -0700, Joseph D. Darcy wrote:
> * I've ported fixes from the forthcoming 6u10 release in the corba, 
> jaxp, jaxws, and langtools areas to OpenJDK 6. [3]

I see the changes for langtools went into openjdk7 already, but for
corba, jaxp and jaxws they still seem to be missing there. What is the
patch flow and timelines for these components?

Some of the xalan files seem to only have changed their CVS $Id. You
might want to remove those completely or do inputs with -kk. Also some
seem to just have random whitespace changes which makes the diffs a
little hard to read.

None of these come with tests. I'll run things through the various mauve
tests we have for these areas, but if there are any internal tests it
would be nice to get them liberated also.

Cheers,

Mark


From mark at klomp.org  Sun Sep 14 07:19:31 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 14 Sep 2008 16:19:31 +0200
Subject: OpenJDK 6 build 12 source posted (build fixes)
In-Reply-To: <48CAB08F.6010407@sun.com>
References: <48CAB08F.6010407@sun.com>
Message-ID: <1221401971.3542.37.camel@dijkstra.wildebeest.org>

Hi Joe,

On Fri, 2008-09-12 at 11:10 -0700, Joseph D. Darcy wrote:
> * Various build fixes, including the gcc ciTypeFlow.cpp issue. [4]

Thanks this cleans up the icedtea-corba.patch and some of the build
things in icedtea-ecj.patch, plus icedtea-hotspot-citypeflow.patch.

Saw that nio spp.sh was replaced by a Spp.java, that makes bootstrapping
a little less convenient. Andrew has some fixes so that this java
version can also be run on alternative free runtimes. See
icedtea-ecj-spp.patch.

Cheers,

Mark


From mark at klomp.org  Sun Sep 14 07:22:04 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 14 Sep 2008 16:22:04 +0200
Subject: OpenJDK 6 build 12 source posted (directaudio/alsa backend)
In-Reply-To: <48CAB08F.6010407@sun.com>
References: <48CAB08F.6010407@sun.com>
Message-ID: <1221402124.3542.40.camel@dijkstra.wildebeest.org>

Hi Joe,

Although not in your changelogs, I saw you also included two of my fixes
for the ALSA directaudio backend which I posted back in May on
sound-dev, and which are included in icedtea already.
- The sloppy open/close patch:
http://mail.openjdk.java.net/pipermail/sound-dev/2008-May/000053.html
- The ALSA native lock patch:
http://mail.openjdk.java.net/pipermail/sound-dev/2008-May/000054.html

Although it makes some applets that use some primitive sound output work
better I never got a real response. Did you get someone from the sound
team to look at these patches? They do seem to work for me and the few
test users of those applets, but a full review by one of the sound
engineers would be appreciated. They don't seem to be in the JDK7 tree.

Karl did correctly pointed out back then that we just need a better/new
sound backend. I do hope in time the pulseaudio backend that Ioana and
Omair are working on will be that backend.

Cheers,

Mark


From gnu_andrew at member.fsf.org  Sun Sep 14 07:31:06 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Sun, 14 Sep 2008 15:31:06 +0100
Subject: OpenJDK 6 build 12 source posted (build fixes)
In-Reply-To: <1221401971.3542.37.camel@dijkstra.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221401971.3542.37.camel@dijkstra.wildebeest.org>
Message-ID: <17c6771e0809140731o3a6470e1pcc1c49b7dddf8d16@mail.gmail.com>

2008/9/14 Mark Wielaard <mark at klomp.org>:
> Hi Joe,
>
> On Fri, 2008-09-12 at 11:10 -0700, Joseph D. Darcy wrote:
>> * Various build fixes, including the gcc ciTypeFlow.cpp issue. [4]
>
> Thanks this cleans up the icedtea-corba.patch and some of the build
> things in icedtea-ecj.patch, plus icedtea-hotspot-citypeflow.patch.
>

The latter was also fixed in OpenJDK b34 or b35, being part of HotSpot
(not sure which as it isn't documented in the lists for these build drops,
and we went from b33 to b35).

> Saw that nio spp.sh was replaced by a Spp.java, that makes bootstrapping
> a little less convenient. Andrew has some fixes so that this java
> version can also be run on alternative free runtimes. See
> icedtea-ecj-spp.patch.
>

Spp.java is preferable in the long term, as it removes the reported
problems with
shells like /bin/dash.  Note that the current CVS of GNU Classpath has
fixes that
will allow this to work unmodified, and these fixes are being ported
for GCJ 4.4.
The patch is only needed for the current status quo.

I did find it rather strange that java.util.Scanner was used not for
its scanner facilities
but simply as an input stream! It made the replacement simple though,
so I'm not complaining :)

> Cheers,
>
> Mark
>
>

Cheers,
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

From mark at klomp.org  Sun Sep 14 09:17:26 2008
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 14 Sep 2008 18:17:26 +0200
Subject: ChunkedInputStream/test.txt
In-Reply-To: <48CAB08F.6010407@sun.com>
References: <48CAB08F.6010407@sun.com>
Message-ID: <1221409046.3542.47.camel@dijkstra.wildebeest.org>

Hi Joe,

In each bxx drop there seems to be some one byte change to the file
test/sun/net/www/http/ChunkedInputStream/test.txt. This is a 500K file
that only seems to be used as test input. Since it is an ascii file all
on one line it makes the diff pretty messy. Do you know why the test
input is changed each time for a new bxx drop?

The ChunkedInputStream tests pass btw.
And in jdk7 this file never changes.

Thanks,

Mark


From Joe.Darcy at Sun.COM  Sun Sep 14 09:50:02 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Sun, 14 Sep 2008 09:50:02 -0700
Subject: OpenJDK 6 build 12 source posted (corba, jaxp, jaxws)
In-Reply-To: <1221401790.3542.32.camel@dijkstra.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221401790.3542.32.camel@dijkstra.wildebeest.org>
Message-ID: <48CD40BA.6010104@sun.com>

Hello.

Mark Wielaard wrote:
> Hi Joe,
>
> Andrew and Matthias did all the hard work to integrate this with
> icedtea6 already. Going through the diffs now that the source drops have
> been imported into http://icedtea.classpath.org/hg/openjdk6 and some of
> the changes needed in IcedTea I had some comments questions.
>
> On Fri, 2008-09-12 at 11:10 -0700, Joseph D. Darcy wrote:
>   
>> * I've ported fixes from the forthcoming 6u10 release in the corba, 
>> jaxp, jaxws, and langtools areas to OpenJDK 6. [3]
>>     
>
> I see the changes for langtools went into openjdk7 already, but for
> corba, jaxp and jaxws they still seem to be missing there. What is the
> patch flow and timelines for these components?
>   

There is no particular timeline for getting these fixes in JDK 7; 
although they should get there at some point of course.

> Some of the xalan files seem to only have changed their CVS $Id. You
> might want to remove those completely or do inputs with -kk. Also some
> seem to just have random whitespace changes which makes the diffs a
> little hard to read.
>   

Yes, nuking those CVS $Ids was on my possible to-do list before the 
OpenJDK 6 Mercurial transition.  We'll also renormalize the whitespace 
in all the sources before switching to Hg.

> None of these come with tests. I'll run things through the various mauve
> tests we have for these areas, but if there are any internal tests it
> would be nice to get them liberated also.
>
>   

There were a few new tests for the JAF upgrade in jaxws, but we had 
problems getting them to run inside jprt although they passed fine in 
other settings.  There is a bug for getting those tests in OpenJDK 6 
(6741224 "Integrate tests for JAF 1.1.1"); I didn't want to hold up the 
rest of b12 for figuring this out.

-Joe

From martinrb at google.com  Sun Sep 14 19:21:30 2008
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 14 Sep 2008 19:21:30 -0700
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <1221382347.22691.29.camel@hermans.wildebeest.org>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
Message-ID: <1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>

Hi Mark,

I think this is great.

I would prefer if the tag for a release was
consistent with the naming convention in OpenJDK7,
i.e. something like "jdk6-b12"

Joe, as I mentioned to you offline,
I think having some history for the mercurial repos
at creation time would be valuable.

I bet the community would do the conversion down to the
changeset if Sun provided the history in Teamware form.

Martin

On Sun, Sep 14, 2008 at 01:52, Mark Wielaard <mark at klomp.org> wrote:
> Hi,
>
> To make it easier to examine the various changes that go into openjdk6 I
> imported all tar balls into a mercurial repo that you can hg clone and
> hg diff as much as you like.
> hg clone http://icedtea.classpath.org/hg/openjdk6
> (It is approx. 175 MB or 500MB for a fully exploded bxx.)
>
> The import was basically done by going over each tar ball and date for a
> bxx drop from b05 (2008-02-12) till b12 (2008-08-28) and do:
> $ rm -rf *
> $ tar zxf ../openjdk-6-src-b[XX]*.gz
> $ hg addremove -s 95
> $ hg commit -m "Import b[XX]" -d [date]
> $ hg tag -d [date] b[XX]
>
> I'll keep it up to date with any future openjdk6 drops.
>
> Cheers,
>
> Mark
>
>

From Joe.Darcy at Sun.COM  Sun Sep 14 23:31:45 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Sun, 14 Sep 2008 23:31:45 -0700
Subject: ChunkedInputStream/test.txt
In-Reply-To: <1221409046.3542.47.camel@dijkstra.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
Message-ID: <48CE0151.1080303@sun.com>

Mark Wielaard wrote:
> Hi Joe,
>
> In each bxx drop there seems to be some one byte change to the file
> test/sun/net/www/http/ChunkedInputStream/test.txt. This is a 500K file
> that only seems to be used as test input. Since it is an ascii file all
> on one line it makes the diff pretty messy. Do you know why the test
> input is changed each time for a new bxx drop?
>
> The ChunkedInputStream tests pass btw.
> And in jdk7 this file never changes.
>
> Thanks,
>
> Mark

Hmm.  That is strange; the file doesn't have any delta's on it after its 
creation so it should be the same for each build; these are the hashes I 
get on the file in my workspace:

md5 (test.txt) = 85833c4399256ea461d68601fc8c146c
sha1 (test.txt) = 317740eed4a0e3d13887dead3507c7d9e6442edb

-Joe

From mark at klomp.org  Mon Sep 15 02:45:40 2008
From: mark at klomp.org (Mark Wielaard)
Date: Mon, 15 Sep 2008 11:45:40 +0200
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
Message-ID: <1221471940.3280.1.camel@dijkstra.wildebeest.org>

Hi Martin,

On Sun, 2008-09-14 at 19:21 -0700, Martin Buchholz wrote:
> I would prefer if the tag for a release was
> consistent with the naming convention in OpenJDK7,
> i.e. something like "jdk6-b12"

Good point. It is unlikely that the bxx numbers for 7 and 6 will overlap
soon, but better to be clear about it. Please pull for the renamed tags.

Cheers,

Mark


From mark at klomp.org  Mon Sep 15 03:10:43 2008
From: mark at klomp.org (Mark Wielaard)
Date: Mon, 15 Sep 2008 12:10:43 +0200
Subject: ChunkedInputStream/test.txt
In-Reply-To: <48CE0151.1080303@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
Message-ID: <1221473443.3280.15.camel@dijkstra.wildebeest.org>

Hi Joe,

On Sun, 2008-09-14 at 23:31 -0700, Joseph D. Darcy wrote:
> Hmm.  That is strange; the file doesn't have any delta's on it after its 
> creation so it should be the same for each build; these are the hashes I 
> get on the file in my workspace:
> 
> md5 (test.txt) = 85833c4399256ea461d68601fc8c146c
> sha1 (test.txt) = 317740eed4a0e3d13887dead3507c7d9e6442edb

So the md5 sum from the b11 tar.gz is:
e6b5fb24a26df9f71d36a8fd8da70381

And for the b12 tar.gz:
54c1282d3766fe77f8fa23edb28bc041

The one from jdk7 mercurial is also different btw:
b5443594ec4cb07e644b1ccb6c4ec600

Converting with hexdump and creating a diff gives:

--- jdk6-b11.text.txt.hex
+++ jdk6-b12.text.txt.hex
@@ -13798,7 +13798,7 @@
 0035e50 745b 3159 6d55 1768 2b2b 104c 5120 3960
 0035e60 2a37 5a21 1d4e 562e 6521 6c0e 3245 306e
 0035e70 6061 5b16 1412 1549 5145 3c6e 305b 2f38
-0035e80 3730 312f 4330 4954 4556 600e 260f 5522
+0035e80 3830 322f 4338 4954 4556 600e 260f 5522
 0035e90 4923 3b68 3a74 4b59 4420 6b17 5c15 3026
 0035ea0 1d42 6b4b 5351 3d5c 2e12 1f59 6861 1b32
 0035eb0 6e1c 555a 3124 541f 2d2f 1352 4b1b 6958

So somewhere between your and mine machine this one byte gets changed.
Maybe in the packing or unpacking of the tar.gz file?

Cheers,

Mark


From Joe.Darcy at Sun.COM  Mon Sep 15 23:29:57 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Mon, 15 Sep 2008 23:29:57 -0700
Subject: OpenJDK 6 build 12 source posted (corba, jaxp, jaxws)
In-Reply-To: <48CD40BA.6010104@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221401790.3542.32.camel@dijkstra.wildebeest.org>
	<48CD40BA.6010104@sun.com>
Message-ID: <48CF5265.70208@sun.com>

Joseph D. Darcy wrote:
> Hello.
>
> Mark Wielaard wrote:
>> Hi Joe,
>>
>> Andrew and Matthias did all the hard work to integrate this with
>> icedtea6 already. Going through the diffs now that the source drops have
>> been imported into http://icedtea.classpath.org/hg/openjdk6 and some of
>> the changes needed in IcedTea I had some comments questions.
>>
>> On Fri, 2008-09-12 at 11:10 -0700, Joseph D. Darcy wrote:
>>  
>>> * I've ported fixes from the forthcoming 6u10 release in the corba, 
>>> jaxp, jaxws, and langtools areas to OpenJDK 6. [3]
>>>     
>>
>> I see the changes for langtools went into openjdk7 already, but for
>> corba, jaxp and jaxws they still seem to be missing there. What is the
>> patch flow and timelines for these components?
>>   
>
> There is no particular timeline for getting these fixes in JDK 7; 
> although they should get there at some point of course.
>
>> Some of the xalan files seem to only have changed their CVS $Id. You
>> might want to remove those completely or do inputs with -kk. Also some
>> seem to just have random whitespace changes which makes the diffs a
>> little hard to read.
>>   
>
> Yes, nuking those CVS $Ids was on my possible to-do list before the 
> OpenJDK 6 Mercurial transition.  We'll also renormalize the whitespace 
> in all the sources before switching to Hg.

PS A patch to remove the $Id's would be welcome :-)

-Joe

From mark at klomp.org  Tue Sep 16 01:34:48 2008
From: mark at klomp.org (Mark Wielaard)
Date: Tue, 16 Sep 2008 10:34:48 +0200
Subject: OpenJDK 6 build 12 source posted (corba, jaxp, jaxws)
In-Reply-To: <48CF5265.70208@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221401790.3542.32.camel@dijkstra.wildebeest.org>
	<48CD40BA.6010104@sun.com>  <48CF5265.70208@sun.com>
Message-ID: <1221554088.4046.7.camel@hermans.wildebeest.org>

Hi Joe,

On Mon, 2008-09-15 at 23:29 -0700, Joseph D. Darcy wrote:
> > Yes, nuking those CVS $Ids was on my possible to-do list before the 
> > OpenJDK 6 Mercurial transition.  We'll also renormalize the whitespace 
> > in all the sources before switching to Hg.
> 
> PS A patch to remove the $Id's would be welcome :-)

Since most of this is in upstream code how do you handle that?
In GNU Classpath we keep such code separate (in an external dir, where
there is an README explaining how to do a fresh import) and have the
rule that changes should be pushed upstream before applying/reimporting.

Which version/branch of the upstream code do you use and how do patches
flow back and forth between the projects normally?

In the case of CVS $Id's of course another option is to import them
without keyword expansion to keep divergence as small as possible.

Cheers,

Mark


From mark at klomp.org  Tue Sep 16 07:41:22 2008
From: mark at klomp.org (Mark Wielaard)
Date: Tue, 16 Sep 2008 16:41:22 +0200
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
Message-ID: <1221576082.3889.10.camel@dijkstra.wildebeest.org>

Hi,

On Sun, 2008-09-14 at 19:21 -0700, Martin Buchholz wrote:
> Joe, as I mentioned to you offline,
> I think having some history for the mercurial repos
> at creation time would be valuable.
> 
> I bet the community would do the conversion down to the
> changeset if Sun provided the history in Teamware form.

Yes, we were just discussing that again on irc. And Martin is completely
right. We would be happy to help in any way getting the individual
patches and changesets into a public mercurial repository if made
available (at least the back to the future parts, clearly anything from
before jdk7 will be a bit too hard).

It would greatly help with reviewing the code and any changes in the
future.

Cheers,

Mark


From Joe.Darcy at Sun.COM  Tue Sep 16 08:50:25 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Tue, 16 Sep 2008 08:50:25 -0700
Subject: ChunkedInputStream/test.txt
In-Reply-To: <1221473443.3280.15.camel@dijkstra.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
	<1221473443.3280.15.camel@dijkstra.wildebeest.org>
Message-ID: <48CFD5C1.4000608@sun.com>

Mark Wielaard wrote:
> Hi Joe,
>
> On Sun, 2008-09-14 at 23:31 -0700, Joseph D. Darcy wrote:
>   
>> Hmm.  That is strange; the file doesn't have any delta's on it after its 
>> creation so it should be the same for each build; these are the hashes I 
>> get on the file in my workspace:
>>
>> md5 (test.txt) = 85833c4399256ea461d68601fc8c146c
>> sha1 (test.txt) = 317740eed4a0e3d13887dead3507c7d9e6442edb
>>     
>
> So the md5 sum from the b11 tar.gz is:
> e6b5fb24a26df9f71d36a8fd8da70381
>
> And for the b12 tar.gz:
> 54c1282d3766fe77f8fa23edb28bc041
>
> The one from jdk7 mercurial is also different btw:
> b5443594ec4cb07e644b1ccb6c4ec600
>
> Converting with hexdump and creating a diff gives:
>
> --- jdk6-b11.text.txt.hex
> +++ jdk6-b12.text.txt.hex
> @@ -13798,7 +13798,7 @@
>  0035e50 745b 3159 6d55 1768 2b2b 104c 5120 3960
>  0035e60 2a37 5a21 1d4e 562e 6521 6c0e 3245 306e
>  0035e70 6061 5b16 1412 1549 5145 3c6e 305b 2f38
> -0035e80 3730 312f 4330 4954 4556 600e 260f 5522
> +0035e80 3830 322f 4338 4954 4556 600e 260f 5522
>  0035e90 4923 3b68 3a74 4b59 4420 6b17 5c15 3026
>  0035ea0 1d42 6b4b 5351 3d5c 2e12 1f59 6861 1b32
>  0035eb0 6e1c 555a 3124 541f 2d2f 1352 4b1b 6958
>
> So somewhere between your and mine machine this one byte gets changed.
> Maybe in the packing or unpacking of the tar.gz file?
>
>   

I'm looking into what might be going on.

-Joe


From Joe.Darcy at Sun.COM  Tue Sep 16 09:37:28 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Tue, 16 Sep 2008 09:37:28 -0700
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <1221576082.3889.10.camel@dijkstra.wildebeest.org>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
	<1221576082.3889.10.camel@dijkstra.wildebeest.org>
Message-ID: <48CFE0C8.6090809@sun.com>

Mark Wielaard wrote:
> Hi,
>
> On Sun, 2008-09-14 at 19:21 -0700, Martin Buchholz wrote:
>   
>> Joe, as I mentioned to you offline,
>> I think having some history for the mercurial repos
>> at creation time would be valuable.
>>
>> I bet the community would do the conversion down to the
>> changeset if Sun provided the history in Teamware form.
>>     
>
> Yes, we were just discussing that again on irc. And Martin is completely
> right. We would be happy to help in any way getting the individual
> patches and changesets into a public mercurial repository if made
> available (at least the back to the future parts, clearly anything from
> before jdk7 will be a bit too hard).
>
> It would greatly help with reviewing the code and any changes in the
> future.
>
> Cheers,
>
> Mark
>   

Hello.

While I'm sympathetic to the request and appreciate the offer of help, 
it is unlikely I'll be able to publish the initial Mercurial 
repositories with any history.  The most history that could be published 
dates back to when OpenJDK 6 branched off from the already open sourced 
JDK 7.  The total amount of bugs fixed from then until now is on the 
order of 400-500, with somewhat fewer logical changesets.  This number 
of changesets is quite small compared to the amount of pre-Mercurial 
history that is not being published externally at all.  However, the 
number is large enough that is would be troublesome for me to reliably 
synthesize changesets.   I don't have Martin's process for scripting and 
SCM hackery and one of the limitation of the teamware SCM is that the 
changes are only really tracked on a per-file basis.  Published 
truncated teamware histories outside of Sun's firewall for people to 
help cons up changesets might be technically possible, but much of the 
prep work and reviews would have to be done internally and the 
costs/benefits on that portion don't look attractive to me.  I'd rather 
see the Mercurial repository up and running sooner so all future changes 
can be tracked well.

-Joe


From Joe.Darcy at Sun.COM  Tue Sep 16 14:43:12 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Tue, 16 Sep 2008 14:43:12 -0700
Subject: OpenJDK 6 build 12 source posted (corba, jaxp, jaxws)
In-Reply-To: <1221554088.4046.7.camel@hermans.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221401790.3542.32.camel@dijkstra.wildebeest.org>
	<48CD40BA.6010104@sun.com> <48CF5265.70208@sun.com>
	<1221554088.4046.7.camel@hermans.wildebeest.org>
Message-ID: <48D02870.80604@sun.com>

Mark Wielaard wrote:
> Hi Joe,
>
> On Mon, 2008-09-15 at 23:29 -0700, Joseph D. Darcy wrote:
>   
>>> Yes, nuking those CVS $Ids was on my possible to-do list before the 
>>> OpenJDK 6 Mercurial transition.  We'll also renormalize the whitespace 
>>> in all the sources before switching to Hg.
>>>       
>> PS A patch to remove the $Id's would be welcome :-)
>>     
>
> Since most of this is in upstream code how do you handle that?
>   

Not particularly well ;-)

> In GNU Classpath we keep such code separate (in an external dir, where
> there is an README explaining how to do a fresh import) and have the
> rule that changes should be pushed upstream before applying/reimporting.
>
> Which version/branch of the upstream code do you use and how do patches
> flow back and forth between the projects normally?
>
> In the case of CVS $Id's of course another option is to import them
> without keyword expansion to keep divergence as small as possible.
>
>   

In the JDK, we import some large bodies of code that are actively 
maintained elsewhere, such as the GlassFish project.  This is generally 
a copy-and-paste of the upstream code, with perhaps some local fixes or 
licensing changes.  This approach has the attendant code maintenance 
issues and in the future I'd like to revisit how we interact with these 
other code bases; the approach of just having the code as a build 
dependency and keeping local patches under revision control, as done in 
IcedTea, might be better overall.

-Joe

From martinrb at google.com  Tue Sep 16 14:51:16 2008
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 16 Sep 2008 14:51:16 -0700
Subject: OpenJDK 6 build 12 source posted (corba, jaxp, jaxws)
In-Reply-To: <48D02870.80604@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221401790.3542.32.camel@dijkstra.wildebeest.org>
	<48CD40BA.6010104@sun.com> <48CF5265.70208@sun.com>
	<1221554088.4046.7.camel@hermans.wildebeest.org>
	<48D02870.80604@sun.com>
Message-ID: <1ccfd1c10809161451l750fd3cdqef1187c816a8260e@mail.gmail.com>

Over time, I've also become a big fan of maintaining mods to
sources which are primarily maintained elsewhere, in the form of
explicit patch files, as in the debian project.

Mercurial has pretty good infrastructure to help with this,
using the Mercurial Queues extension.  It has pretty good
documentation in the hgbook
http://hgbook.red-bean.com/hgbookch12.html#x16-26700012

Managing distributed development is never easy, however.

Martin

On Tue, Sep 16, 2008 at 14:43, Joseph D. Darcy <Joe.Darcy at sun.com> wrote:
> Mark Wielaard wrote:

> In the JDK, we import some large bodies of code that are actively maintained
> elsewhere, such as the GlassFish project.  This is generally a
> copy-and-paste of the upstream code, with perhaps some local fixes or
> licensing changes.  This approach has the attendant code maintenance issues
> and in the future I'd like to revisit how we interact with these other code
> bases; the approach of just having the code as a build dependency and
> keeping local patches under revision control, as done in IcedTea, might be
> better overall.
>
> -Joe
>

From mark at klomp.org  Wed Sep 17 02:30:27 2008
From: mark at klomp.org (Mark Wielaard)
Date: Wed, 17 Sep 2008 11:30:27 +0200
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <48CFE0C8.6090809@sun.com>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
	<1221576082.3889.10.camel@dijkstra.wildebeest.org>
	<48CFE0C8.6090809@sun.com>
Message-ID: <1221643827.3246.64.camel@dijkstra.wildebeest.org>

Hi Joe,

On Tue, 2008-09-16 at 09:37 -0700, Joseph D. Darcy wrote:
> While I'm sympathetic to the request and appreciate the offer of help, 
> it is unlikely I'll be able to publish the initial Mercurial 
> repositories with any history.  The most history that could be published 
> dates back to when OpenJDK 6 branched off from the already open sourced 
> JDK 7.  The total amount of bugs fixed from then until now is on the 
> order of 400-500, with somewhat fewer logical changesets.  This number 
> of changesets is quite small compared to the amount of pre-Mercurial 
> history that is not being published externally at all.

That is actually about half of what jdk7 or icedtea (disregarding
openjdk import changes) have been seeing. So I do think it is a
significant amount of changes. It would certain help with getting a
better view of how changes relate to each other.

> However, the 
> number is large enough that is would be troublesome for me to reliably 
> synthesize changesets.   I don't have Martin's process for scripting and 
> SCM hackery and one of the limitation of the teamware SCM is that the 
> changes are only really tracked on a per-file basis.  Published 
> truncated teamware histories outside of Sun's firewall for people to 
> help cons up changesets might be technically possible, but much of the 
> prep work and reviews would have to be done internally and the 
> costs/benefits on that portion don't look attractive to me.

Ah, that is a bummer. I had assumed that the teamware history only
included stuff starting with the public release of openjdk7. Isn't there
any way to "replay" the patches starting at that point and post those?
rcs and cvs also maintain history on a per-file basis, but with some
scripting tricks it is still possible to reconstruct cross-file
changesets from them mostly. If that is impossible, could you start
posting patches to the jdk6-dev when you apply them to your repository?
So the chunks are smaller and can be commented on more timely than when
you do full bxx code drops?

Thanks,

Mark


From mark at klomp.org  Wed Sep 17 02:55:31 2008
From: mark at klomp.org (Mark Wielaard)
Date: Wed, 17 Sep 2008 11:55:31 +0200
Subject: OpenJDK 6 build 12 source posted (corba, jaxp, jaxws)
In-Reply-To: <48D02870.80604@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221401790.3542.32.camel@dijkstra.wildebeest.org>
	<48CD40BA.6010104@sun.com> <48CF5265.70208@sun.com>
	<1221554088.4046.7.camel@hermans.wildebeest.org>
	<48D02870.80604@sun.com>
Message-ID: <1221645331.3246.70.camel@dijkstra.wildebeest.org>

Hi Joe,

On Tue, 2008-09-16 at 14:43 -0700, Joseph D. Darcy wrote:
> In the JDK, we import some large bodies of code that are actively 
> maintained elsewhere, such as the GlassFish project.  This is generally 
> a copy-and-paste of the upstream code, with perhaps some local fixes or 
> licensing changes.  This approach has the attendant code maintenance 
> issues and in the future I'd like to revisit how we interact with these 
> other code bases; the approach of just having the code as a build 
> dependency and keeping local patches under revision control, as done in 
> IcedTea, might be better overall.

Actually directly working on patches is also not very good. As Martin
suggested switching to something like mercurial queues might be a good
idea.

I think the main thing to take care of is having a more or less formal
description on how to do new imports. What is considered the canonical
upstream source, how to record a new import (version, etc), when to
import a new (stable) upstream version, and how to clearly mark any
local changes in the sources themselves if they are necessary and cannot
be pushed upstream (directly) for some reason.

Cheers,

Mark


From Kelly.Ohair at Sun.COM  Wed Sep 17 09:29:35 2008
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Wed, 17 Sep 2008 09:29:35 -0700
Subject: ChunkedInputStream/test.txt
In-Reply-To: <48CFD5C1.4000608@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
	<1221473443.3280.15.camel@dijkstra.wildebeest.org>
	<48CFD5C1.4000608@sun.com>
Message-ID: <48D1306F.9080907@sun.com>

This binary file has a %[A-Z]% byte pattern in it, and when it gets
processed by sccs, those bytes get turned into an SCCS keyword value.

This problem was found when I did the Mercurial conversion, which gets
the SCCS 'pre-keyword' file contents.

I'd ignore this one, except for the fact that is is a binary file. :^(

-kto


Joseph D. Darcy wrote:
> Mark Wielaard wrote:
>> Hi Joe,
>>
>> On Sun, 2008-09-14 at 23:31 -0700, Joseph D. Darcy wrote:
>>  
>>> Hmm.  That is strange; the file doesn't have any delta's on it after 
>>> its creation so it should be the same for each build; these are the 
>>> hashes I get on the file in my workspace:
>>>
>>> md5 (test.txt) = 85833c4399256ea461d68601fc8c146c
>>> sha1 (test.txt) = 317740eed4a0e3d13887dead3507c7d9e6442edb
>>>     
>>
>> So the md5 sum from the b11 tar.gz is:
>> e6b5fb24a26df9f71d36a8fd8da70381
>>
>> And for the b12 tar.gz:
>> 54c1282d3766fe77f8fa23edb28bc041
>>
>> The one from jdk7 mercurial is also different btw:
>> b5443594ec4cb07e644b1ccb6c4ec600
>>
>> Converting with hexdump and creating a diff gives:
>>
>> --- jdk6-b11.text.txt.hex
>> +++ jdk6-b12.text.txt.hex
>> @@ -13798,7 +13798,7 @@
>>  0035e50 745b 3159 6d55 1768 2b2b 104c 5120 3960
>>  0035e60 2a37 5a21 1d4e 562e 6521 6c0e 3245 306e
>>  0035e70 6061 5b16 1412 1549 5145 3c6e 305b 2f38
>> -0035e80 3730 312f 4330 4954 4556 600e 260f 5522
>> +0035e80 3830 322f 4338 4954 4556 600e 260f 5522
>>  0035e90 4923 3b68 3a74 4b59 4420 6b17 5c15 3026
>>  0035ea0 1d42 6b4b 5351 3d5c 2e12 1f59 6861 1b32
>>  0035eb0 6e1c 555a 3124 541f 2d2f 1352 4b1b 6958
>>
>> So somewhere between your and mine machine this one byte gets changed.
>> Maybe in the packing or unpacking of the tar.gz file?
>>
>>   
> 
> I'm looking into what might be going on.
> 
> -Joe
> 

From Kelly.Ohair at Sun.COM  Wed Sep 17 10:26:06 2008
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Wed, 17 Sep 2008 10:26:06 -0700
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <1221643827.3246.64.camel@dijkstra.wildebeest.org>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
	<1221576082.3889.10.camel@dijkstra.wildebeest.org>
	<48CFE0C8.6090809@sun.com>
	<1221643827.3246.64.camel@dijkstra.wildebeest.org>
Message-ID: <48D13DAE.9030009@sun.com>

Speaking from experience, any attempts at cleanly creating changesets
from TeamWare data alone is a waste of time. Just doesn't work well.
Granted we have pretty complete OpenJDK6 changeset data (data beyond
the TeamWare data) and could potentially do this, it's quite a bit of
grunt work to accomplish. Before we go off on this kind of adventure
we need to make sure the time spent is worth it.
A different approach would be to create changesets per build/promotion,
but those kind of large changesets can have limited usefulness.

I'll try and talk to Joe about this tomorrow.

Also, don't forget that the OpenJDK7 sources are a Mercurial forest,
not just one repository. I assume that we want to mimic the same
forest layout, keeping the langtools, corba, jaxp, jaxws, and hotspot
sources in their own repositories, separate from the core 'jdk' repository.
That allows us to do some plug and play with these repositories
between OpenJDK6 and OpenJDK7.

-kto

Mark Wielaard wrote:
> Hi Joe,
> 
> On Tue, 2008-09-16 at 09:37 -0700, Joseph D. Darcy wrote:
>> While I'm sympathetic to the request and appreciate the offer of help, 
>> it is unlikely I'll be able to publish the initial Mercurial 
>> repositories with any history.  The most history that could be published 
>> dates back to when OpenJDK 6 branched off from the already open sourced 
>> JDK 7.  The total amount of bugs fixed from then until now is on the 
>> order of 400-500, with somewhat fewer logical changesets.  This number 
>> of changesets is quite small compared to the amount of pre-Mercurial 
>> history that is not being published externally at all.
> 
> That is actually about half of what jdk7 or icedtea (disregarding
> openjdk import changes) have been seeing. So I do think it is a
> significant amount of changes. It would certain help with getting a
> better view of how changes relate to each other.
> 
>> However, the 
>> number is large enough that is would be troublesome for me to reliably 
>> synthesize changesets.   I don't have Martin's process for scripting and 
>> SCM hackery and one of the limitation of the teamware SCM is that the 
>> changes are only really tracked on a per-file basis.  Published 
>> truncated teamware histories outside of Sun's firewall for people to 
>> help cons up changesets might be technically possible, but much of the 
>> prep work and reviews would have to be done internally and the 
>> costs/benefits on that portion don't look attractive to me.
> 
> Ah, that is a bummer. I had assumed that the teamware history only
> included stuff starting with the public release of openjdk7. Isn't there
> any way to "replay" the patches starting at that point and post those?
> rcs and cvs also maintain history on a per-file basis, but with some
> scripting tricks it is still possible to reconstruct cross-file
> changesets from them mostly. If that is impossible, could you start
> posting patches to the jdk6-dev when you apply them to your repository?
> So the chunks are smaller and can be commented on more timely than when
> you do full bxx code drops?
> 
> Thanks,
> 
> Mark
> 

From martinrb at google.com  Wed Sep 17 12:10:57 2008
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 17 Sep 2008 12:10:57 -0700
Subject: ChunkedInputStream/test.txt
In-Reply-To: <48D1306F.9080907@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
	<1221473443.3280.15.camel@dijkstra.wildebeest.org>
	<48CFD5C1.4000608@sun.com> <48D1306F.9080907@sun.com>
Message-ID: <1ccfd1c10809171210x6d8b64d4p81f23611b4cedb61@mail.gmail.com>

On Wed, Sep 17, 2008 at 09:29, Kelly O'Hair <Kelly.Ohair at sun.com> wrote:
> This binary file has a %[A-Z]% byte pattern in it, and when it gets
> processed by sccs, those bytes get turned into an SCCS keyword value.

I'm sure that the SCCS keyword expansion headache-to-benefit
ratio is at least 10:1.

One big benefit of mercurialization is that this problem will evaporate.
Make sure you import the non-keyword-expanded version of every file.
But y'all probably all already know this from jdk7 mercurialization experience.

Martin

From Kelly.Ohair at Sun.COM  Wed Sep 17 12:18:04 2008
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Wed, 17 Sep 2008 12:18:04 -0700
Subject: ChunkedInputStream/test.txt
In-Reply-To: <1ccfd1c10809171210x6d8b64d4p81f23611b4cedb61@mail.gmail.com>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
	<1221473443.3280.15.camel@dijkstra.wildebeest.org>
	<48CFD5C1.4000608@sun.com> <48D1306F.9080907@sun.com>
	<1ccfd1c10809171210x6d8b64d4p81f23611b4cedb61@mail.gmail.com>
Message-ID: <48D157EC.1000205@sun.com>



Martin Buchholz wrote:
> On Wed, Sep 17, 2008 at 09:29, Kelly O'Hair <Kelly.Ohair at sun.com> wrote:
>> This binary file has a %[A-Z]% byte pattern in it, and when it gets
>> processed by sccs, those bytes get turned into an SCCS keyword value.
> 
> I'm sure that the SCCS keyword expansion headache-to-benefit
> ratio is at least 10:1.

I agree.

Which is one reason why we decided to not use any Mercurial keyword extensions
to continue this practice.

> 
> One big benefit of mercurialization is that this problem will evaporate.
> Make sure you import the non-keyword-expanded version of every file.
> But y'all probably all already know this from jdk7 mercurialization experience.

Yup. Known issue.

-kto

> 
> Martin

From gnu_andrew at member.fsf.org  Wed Sep 17 15:04:19 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Wed, 17 Sep 2008 23:04:19 +0100
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <1221643827.3246.64.camel@dijkstra.wildebeest.org>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
	<1221576082.3889.10.camel@dijkstra.wildebeest.org>
	<48CFE0C8.6090809@sun.com>
	<1221643827.3246.64.camel@dijkstra.wildebeest.org>
Message-ID: <17c6771e0809171504s5caf3613lc38c51b48c3bd87d@mail.gmail.com>

2008/9/17 Mark Wielaard <mark at klomp.org>:
> Hi Joe,
>
> On Tue, 2008-09-16 at 09:37 -0700, Joseph D. Darcy wrote:
>> While I'm sympathetic to the request and appreciate the offer of help,
>> it is unlikely I'll be able to publish the initial Mercurial
>> repositories with any history.  The most history that could be published
>> dates back to when OpenJDK 6 branched off from the already open sourced
>> JDK 7.  The total amount of bugs fixed from then until now is on the
>> order of 400-500, with somewhat fewer logical changesets.  This number
>> of changesets is quite small compared to the amount of pre-Mercurial
>> history that is not being published externally at all.
>
> That is actually about half of what jdk7 or icedtea (disregarding
> openjdk import changes) have been seeing. So I do think it is a
> significant amount of changes. It would certain help with getting a
> better view of how changes relate to each other.
>
>> However, the
>> number is large enough that is would be troublesome for me to reliably
>> synthesize changesets.   I don't have Martin's process for scripting and
>> SCM hackery and one of the limitation of the teamware SCM is that the
>> changes are only really tracked on a per-file basis.  Published
>> truncated teamware histories outside of Sun's firewall for people to
>> help cons up changesets might be technically possible, but much of the
>> prep work and reviews would have to be done internally and the
>> costs/benefits on that portion don't look attractive to me.
>
> Ah, that is a bummer. I had assumed that the teamware history only
> included stuff starting with the public release of openjdk7. Isn't there
> any way to "replay" the patches starting at that point and post those?
> rcs and cvs also maintain history on a per-file basis, but with some
> scripting tricks it is still possible to reconstruct cross-file
> changesets from them mostly. If that is impossible, could you start
> posting patches to the jdk6-dev when you apply them to your repository?
> So the chunks are smaller and can be commented on more timely than when
> you do full bxx code drops?
>
> Thanks,
>
> Mark
>
>

Seconded.  If you posted patchsets as things are developed, we could
maintain them in our Mercurial repository until such time as a Sun OpenJDK6 one
is launched.
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

From yamauchi at google.com  Wed Sep 17 16:50:41 2008
From: yamauchi at google.com (Hiroshi Yamauchi)
Date: Wed, 17 Sep 2008 16:50:41 -0700
Subject: Backporting an AsyncGetCallTrace patch to OpenJDK6
In-Reply-To: <48CAB6DE.8070806@sun.com>
References: <d6262f010809051320k7b852890pba74ff39552ed2a9@mail.gmail.com>
	<48C84E8B.6030001@sun.com>
	<1221088194.26700.18.camel@hermans.wildebeest.org>
	<48C868CC.4050303@sun.com>
	<17c6771e0809110053g73b2ce49h467a7b67ea817e1@mail.gmail.com>
	<48C91B82.4020502@sun.com>
	<17c6771e0809110731j59e632b2rbb4caf98cc937036@mail.gmail.com>
	<17c6771e0809111510q4edd875ex4a4288bd08aa9dec@mail.gmail.com>
	<48C9ACD5.7030102@sun.com> <48CAB6DE.8070806@sun.com>
Message-ID: <d6262f010809171650t1453c1f1hf0c8c9f6295d60e3@mail.gmail.com>

Hi, Any comment about the patch itself?

On Fri, Sep 12, 2008 at 11:37 AM, Joseph D. Darcy <Joe.Darcy at sun.com> wrote:
> Joseph D. Darcy wrote:
>>
>> Andrew John Hughes wrote:
>>>
>>> 2008/9/11 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>>>
>>>> 2008/9/11 Daniel D. Daugherty <Daniel.Daugherty at sun.com>:
>>>>>
>>>>> Andrew John Hughes wrote:
>>>>>
>>>>> FWIW, I don't see any change to the HS_ version numbers in our
>>>>> patch to switch from OpenJDK6 b11's to OpenJDK7 b24's HotSpot.
>>>>> Given OpenJDK6 was derived from something like b20, I guess this is
>>>>> not that strange.
>>>>>
>>>>> JDK7-B24 has the following values:
>>>>>
>>>>>    HS_MAJOR_VER=12
>>>>>    HS_MINOR_VER=0
>>>>>    HS_BUILD_NUMBER=01
>>>>>
>>>>> Joe stated earlier in this thread that OpenJDK6 is based on
>>>>> HSX-10 so its values should not be the same. For 1.6.0_07,
>>>>> I see:
>>>>>
>>>>>    HS_MAJOR_VER=10
>>>>>    HS_MINOR_VER=0
>>>>>    HS_BUILD_NUMBER=23
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>
>>>> Hmmm...
>>>> Then either Gary's HotSpot patch doesn't update that file or OpenJDK6
>>>> is not based on the same as this 1.6.0_07 thing you mention.
>>>> I'll try and have a closer look later.
>>>> --
>>>> Andrew :-)
>>>>
>>>> Support Free Java!
>>>> Contribute to GNU Classpath and the OpenJDK
>>>> http://www.gnu.org/software/classpath
>>>> http://openjdk.java.net
>>>>
>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
>>>>
>>>
>>> IcedTea6 contains:
>>>
>>> HS_MAJOR_VER=10
>>> HS_MINOR_VER=0
>>> HS_BUILD_NUMBER=19
>>>
>>> IcedTea/b33 contains:
>>>
>>> HS_MAJOR_VER=14
>>> HS_MINOR_VER=0
>>> HS_BUILD_NUMBER=01
>>>
>>> icedtea-hotspot-6b11-7b24.patch only updates the src code and not
>>> make/hotspot_version
>>> so it's actually worryingly building a different version of HotSpot
>>> from the one it thinks it is.
>>> It will actually be 12-0-01 as you state, but will report 10-0-19.
>>>
>>> Overall, it would be better to always build against the most recent
>>> stable HotSpot tree if possible
>>> rather than the one provided by the build drop.  Do we know what the
>>> most stable would be?
>>
>> Generally, the HotSpot in the base OpenJDK 6 should be pretty stable. The
>> policy I've implemented,
>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-February/000005.html,
>> for the HotSpot in OpenJDK 6 is to track fixes in the 6 update releases,
>> augmented with some other fixes for license corrections, gcc build issues,
>> (and the occasional Eclipse crash).  The HotSpot in the base OpenJDK 6 code
>> base is very close to the HotSpot in the currently shipping 6 update
>> release.
>
> ... and going forward we will have much closer coordination between the
> OpenJDK 6 and 6 update HotSpots since we'll be using the same source for
> both; so the version information should be updated consistently, etc.
>
> http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-September/000150.html
>
> -Joe
>

From Joe.Darcy at Sun.COM  Thu Sep 18 05:57:14 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Thu, 18 Sep 2008 05:57:14 -0700
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <48D13DAE.9030009@sun.com>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
	<1221576082.3889.10.camel@dijkstra.wildebeest.org>
	<48CFE0C8.6090809@sun.com>
	<1221643827.3246.64.camel@dijkstra.wildebeest.org>
	<48D13DAE.9030009@sun.com>
Message-ID: <48D2502A.7020001@sun.com>

Kelly O'Hair wrote:
> Speaking from experience, any attempts at cleanly creating changesets
> from TeamWare data alone is a waste of time. Just doesn't work well.
> Granted we have pretty complete OpenJDK6 changeset data (data beyond
> the TeamWare data) and could potentially do this, it's quite a bit of
> grunt work to accomplish. Before we go off on this kind of adventure
> we need to make sure the time spent is worth it.
> A different approach would be to create changesets per build/promotion,
> but those kind of large changesets can have limited usefulness.
>
> I'll try and talk to Joe about this tomorrow.
>
> Also, don't forget that the OpenJDK7 sources are a Mercurial forest,
> not just one repository. I assume that we want to mimic the same
> forest layout, keeping the langtools, corba, jaxp, jaxws, and hotspot
> sources in their own repositories, separate from the core 'jdk' 
> repository.
> That allows us to do some plug and play with these repositories
> between OpenJDK6 and OpenJDK7.
>
> -kto
Yes, my thinking has been to mirror the overall JDK 7 repository forest 
structure in OpenJDK 6.

-Joe

From Joe.Darcy at Sun.COM  Mon Sep 22 12:54:54 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Mon, 22 Sep 2008 12:54:54 -0700
Subject: OpenJDK 6 build 12 source posted (directaudio/alsa backend)
In-Reply-To: <1221402124.3542.40.camel@dijkstra.wildebeest.org>
References: <48CAB08F.6010407@sun.com>
	<1221402124.3542.40.camel@dijkstra.wildebeest.org>
Message-ID: <48D7F80E.6060802@sun.com>

Hi Mark.

Mark Wielaard wrote:
> Hi Joe,
>
> Although not in your changelogs, I saw you also included two of my fixes
> for the ALSA directaudio backend which I posted back in May on
> sound-dev, and which are included in icedtea already.
> - The sloppy open/close patch:
> http://mail.openjdk.java.net/pipermail/sound-dev/2008-May/000053.html
> - The ALSA native lock patch:
> http://mail.openjdk.java.net/pipermail/sound-dev/2008-May/000054.html
>
> Although it makes some applets that use some primitive sound output work
> better I never got a real response. Did you get someone from the sound
> team to look at these patches? They do seem to work for me and the few
> test users of those applets, but a full review by one of the sound
> engineers would be appreciated. They don't seem to be in the JDK7 tree.
>   

No; the patches were not explicitly reviewed; Alex, please take a look 
at them.

Neither Gervill nor your patches have yet been incorporated into JDK 7.

> Karl did correctly pointed out back then that we just need a better/new
> sound backend. I do hope in time the pulseaudio backend that Ioana and
> Omair are working on will be that backend.
>   

I don't have any technical background to speak of in sound, so I'll let 
others weigh in on evaluating any new backends.

Regards,

-Joe



From Joe.Darcy at Sun.COM  Mon Sep 22 13:40:02 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Mon, 22 Sep 2008 13:40:02 -0700
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <48D2502A.7020001@sun.com>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
	<1221576082.3889.10.camel@dijkstra.wildebeest.org>
	<48CFE0C8.6090809@sun.com>
	<1221643827.3246.64.camel@dijkstra.wildebeest.org>
	<48D13DAE.9030009@sun.com> <48D2502A.7020001@sun.com>
Message-ID: <48D802A2.6080509@sun.com>

Joseph D. Darcy wrote:
> Kelly O'Hair wrote:
>> Speaking from experience, any attempts at cleanly creating changesets
>> from TeamWare data alone is a waste of time. Just doesn't work well.
>> Granted we have pretty complete OpenJDK6 changeset data (data beyond
>> the TeamWare data) and could potentially do this, it's quite a bit of
>> grunt work to accomplish. Before we go off on this kind of adventure
>> we need to make sure the time spent is worth it.
>> A different approach would be to create changesets per build/promotion,
>> but those kind of large changesets can have limited usefulness.
>>
>> I'll try and talk to Joe about this tomorrow.
>>
>> Also, don't forget that the OpenJDK7 sources are a Mercurial forest,
>> not just one repository. I assume that we want to mimic the same
>> forest layout, keeping the langtools, corba, jaxp, jaxws, and hotspot
>> sources in their own repositories, separate from the core 'jdk' 
>> repository.
>> That allows us to do some plug and play with these repositories
>> between OpenJDK6 and OpenJDK7.
>>
>> -kto
> Yes, my thinking has been to mirror the overall JDK 7 repository 
> forest structure in OpenJDK 6.

Quick follow-up, I've been traveling recently and haven't had a chance 
to chat with Kelly yet.

Given that there is currently the per-build external Mercurial 
repository and that it is easy to get the list of bugs fixed in a build, 
retroactively synthesizing the (approximate) patches associated with a 
set of bugs *might* be workable since figuring out the bug <-> file 
mapping shouldn't be that bad.  If those interested in seeing the past 
history synthesized these patches, I could focus on finishing getting 
the OpenJDK build 12++ code ready for Mercurial and then reverse apply 
the set of patches to get back to the earlier public source drops.  
However, this might be more work than I think and I'll want to talk to 
Kelly about the detailed logistics of what would be necessary for this 
to happen.

My priority is on getting the "official" Mercurial repository up and 
running so we can collaborate there going forward as opposed to spending 
lots of time on retrofitting the existing build history into the new 
repository.

Also, in the future I'd like to consider an infrastructure where areas 
like corba, jaxp, and jaxws for OpenJDK 6 could be managed as patches to 
an imported code base rather than having a fully populated copy of the 
code under revision management for the release.

Cheers,

-Joe

From mark at klomp.org  Tue Sep 23 02:40:33 2008
From: mark at klomp.org (Mark Wielaard)
Date: Tue, 23 Sep 2008 11:40:33 +0200
Subject: ChunkedInputStream/test.txt
In-Reply-To: <48D1306F.9080907@sun.com>
References: <48CAB08F.6010407@sun.com>
	<1221409046.3542.47.camel@dijkstra.wildebeest.org>
	<48CE0151.1080303@sun.com>
	<1221473443.3280.15.camel@dijkstra.wildebeest.org>
	<48CFD5C1.4000608@sun.com>  <48D1306F.9080907@sun.com>
Message-ID: <1222162833.3178.18.camel@dijkstra.wildebeest.org>

Hi Kelly,

On Wed, 2008-09-17 at 09:29 -0700, Kelly O'Hair wrote:
> This binary file has a %[A-Z]% byte pattern in it, and when it gets
> processed by sccs, those bytes get turned into an SCCS keyword value.
> 
> This problem was found when I did the Mercurial conversion, which gets
> the SCCS 'pre-keyword' file contents.
> 
> I'd ignore this one, except for the fact that is is a binary file. :^(

Maybe we should just rewrite the test. The contents of test.txt seems to
not really matter. And in fact the way it is read in ChunkedEncodingTest
doesn't even guarantee that it is fully read in. So it seems to make
sense to rewrite the test in a way that it just uses (random) data made
up at runtime instead of having to 500K file in te repository. Or am I
missing something subtle here?

Cheers,

Mark


From mark at klomp.org  Tue Sep 23 02:59:35 2008
From: mark at klomp.org (Mark Wielaard)
Date: Tue, 23 Sep 2008 11:59:35 +0200
Subject: Mercurial repo for openjdk6 drops
In-Reply-To: <48D13DAE.9030009@sun.com>
References: <1221382347.22691.29.camel@hermans.wildebeest.org>
	<1ccfd1c10809141921m1565d916rf50c4b822536d7f0@mail.gmail.com>
	<1221576082.3889.10.camel@dijkstra.wildebeest.org>
	<48CFE0C8.6090809@sun.com>
	<1221643827.3246.64.camel@dijkstra.wildebeest.org>
	<48D13DAE.9030009@sun.com>
Message-ID: <1222163975.3178.38.camel@dijkstra.wildebeest.org>

Hi Kelly,

On Wed, 2008-09-17 at 10:26 -0700, Kelly O'Hair wrote:
> Speaking from experience, any attempts at cleanly creating changesets
> from TeamWare data alone is a waste of time. Just doesn't work well.
> Granted we have pretty complete OpenJDK6 changeset data (data beyond
> the TeamWare data) and could potentially do this, it's quite a bit of
> grunt work to accomplish. Before we go off on this kind of adventure
> we need to make sure the time spent is worth it.

It depends on what your goal is. To be useful having any changeset data
that is more fine grained grained than the big source code drop changes
we have now is already enough. While it would be great to have an all
singing and dancing mercurial repo that exactly matches the teamware
changesets going back to the birth of openjdk6 and that then is
essentially a tree that can be easily merged with openjdk7 would be
super great. But to be useful just having the changes as they are going
in (even if it is just patches