You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2009/09/02 19:28:21 UTC
Re: [vote] Declare the signed source for r809832 as 6.0 Milestone 1
In message <4A...@gmail.com>, Tim Ellison writes:
>
> On 01/Sep/2009 08:30, Mark Hindess wrote:
> >
> > There was some agreement that we should create a 6.0 milestone so I'm
> > going to begin a vote. If anyone feels that three days isn't enough
> > time to complete testing then please just ask for more time.
> >
> > I have created a signed source archive for this revision and made it
> > available at:
> >
> > http://people.apache.org/~hindessm/6.0m1/
> >
> > Please test these artifacts and then vote for declaring these source
> > archives as 6.0 milestone 1, and opening up the remaining frozen
> > code trees for general development once again.
> >
> > This vote will be open for at least 3 days, or until all binding
> > votes have been cast (if earlier).
> >
> > If the vote is successful, binary builds from that level will be
> > made available on the download page.
>
> How is this going to work if the DRLVM cannot load class files
> compiled for 1.6 ?! See HARMONY-6317
It will load some class files compiled for 1.6. For instance, if I
compile classlib with hy.javac.{source,target}=1.6 then it runs eclipse.
Do you think we should hold off releasing any 6.0 milestones until the
VM supports all 1.6 features? If no one is planning to implement these
we might not make any 6.0 releases for a rather long time and so the 6.0
classlib code wont get released/exercised?
I'm fine if we decide not to make a release now but we should decide
exactly what the "must have" features are for milestone 1.
-Mark.
Re: [drlvm] Loading 50:0 format class files
Posted by Oliver Deakin <ol...@googlemail.com>.
Mikhail Loenko wrote:
> Hi!
>
> If you are talking about this peace of code:
>
> #ifndef _NDEBUG
> vf_recompute_stackmaptable(method, &context6.substitution,
> error, classwide.class_constraints);
>
> result = context6.verify_method(method);
> if (result != VF_OK) {
> vf_create_error_message(method, context6, error);
> }
> tc_free(context6.substitution);
> context6.substitution = NULL;
> #endif
>
Yes, that's the piece of code.
> then it should not be executed. it was written for debugging purposes
> when I developed recompute stack map functionality.
>
> (recompute stack map functionality populates modified on the fly class
> file with correct stack map attributes)
>
> This peace of code fails when original class file has 6.0 version
> while it can't be verified with Java6 rules.
>
> Just comment it out or even remove it.
>
Brilliant, thanks Mikhail! Ill remove that block altogether.
Regards,
Oliver
> Thanks,
> Mikhail
>
>
>
> 2009/9/4 Oliver Deakin <ol...@googlemail.com>:
>
>> Alexey Varlamov wrote:
>>
>>>> The changes that went into JSR202 include:
>>>> - split verifier support
>>>> - increase various size limits
>>>> - adding support for class literals
>>>> - minor changes to support Java language changes
>>>>
>>>> I'm assuming that the problem in DRLVM is the loading on class literals.
>>>>
>>>>
>>> Actually the class literals were incorporated in Java 5 (v49.0), as
>>> well as other minor features for language support. AFAIK there are no
>>> Java language changes between Java 5 and 6.
>>> DRLVM does support these features, so the evil should be somewhere else.
>>>
>>>
>> Hi Alexey,
>>
>> I have replied about this issue in another part of this thread [1]. It seems
>> there is a problem with some code intended for debug in the verifier. After
>> the initial java 6 method verify, the debug code then tries to recompute the
>> stack map table (which only seems to include Java 5 references oddly) and
>> then verify the method again, and this is where we fail. Without the debug
>> code in place the verification completes successfully.
>>
>> Any ideas why the failure is occurring or why we would want to do the second
>> verify in debug mode after recomputing the stack map table?
>>
>> Regards,
>> Oliver
>>
>> [1]
>> http://mail-archives.apache.org/mod_mbox/harmony-dev/200909.mbox/%3c4A9FD5E6.6060701@googlemail.com%3e
>>
>>
>>> [snip]
>>>
>>>
>>>> I'm happy to keep testing, and if we can make progress quickly then
>>>> let's press ahead, but otherwise let's open all the code and give the
>>>> 6.0 stream a bit more attention before attempting the 6.0M1 again.
>>>>
>>>>
>>> Right decision is already taken ;)
>>>
>>> --
>>> Regards,
>>> Alexey
>>>
>>>
>>>
>>>> Regards,
>>>> Tim
>>>>
>>>>
>>>>
>>>>
>>>
>> --
>> Oliver Deakin
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>> PO6 3AU
>>
>>
>>
>
>
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [drlvm] Loading 50:0 format class files
Posted by Mikhail Loenko <ml...@gmail.com>.
Hi!
If you are talking about this peace of code:
#ifndef _NDEBUG
vf_recompute_stackmaptable(method, &context6.substitution,
error, classwide.class_constraints);
result = context6.verify_method(method);
if (result != VF_OK) {
vf_create_error_message(method, context6, error);
}
tc_free(context6.substitution);
context6.substitution = NULL;
#endif
then it should not be executed. it was written for debugging purposes
when I developed recompute stack map functionality.
(recompute stack map functionality populates modified on the fly class
file with correct stack map attributes)
This peace of code fails when original class file has 6.0 version
while it can't be verified with Java6 rules.
Just comment it out or even remove it.
Thanks,
Mikhail
2009/9/4 Oliver Deakin <ol...@googlemail.com>:
> Alexey Varlamov wrote:
>>>
>>> The changes that went into JSR202 include:
>>> - split verifier support
>>> - increase various size limits
>>> - adding support for class literals
>>> - minor changes to support Java language changes
>>>
>>> I'm assuming that the problem in DRLVM is the loading on class literals.
>>>
>>
>> Actually the class literals were incorporated in Java 5 (v49.0), as
>> well as other minor features for language support. AFAIK there are no
>> Java language changes between Java 5 and 6.
>> DRLVM does support these features, so the evil should be somewhere else.
>>
>
> Hi Alexey,
>
> I have replied about this issue in another part of this thread [1]. It seems
> there is a problem with some code intended for debug in the verifier. After
> the initial java 6 method verify, the debug code then tries to recompute the
> stack map table (which only seems to include Java 5 references oddly) and
> then verify the method again, and this is where we fail. Without the debug
> code in place the verification completes successfully.
>
> Any ideas why the failure is occurring or why we would want to do the second
> verify in debug mode after recomputing the stack map table?
>
> Regards,
> Oliver
>
> [1]
> http://mail-archives.apache.org/mod_mbox/harmony-dev/200909.mbox/%3c4A9FD5E6.6060701@googlemail.com%3e
>
>> [snip]
>>
>>>
>>> I'm happy to keep testing, and if we can make progress quickly then
>>> let's press ahead, but otherwise let's open all the code and give the
>>> 6.0 stream a bit more attention before attempting the 6.0M1 again.
>>>
>>
>> Right decision is already taken ;)
>>
>> --
>> Regards,
>> Alexey
>>
>>
>>>
>>> Regards,
>>> Tim
>>>
>>>
>>>
>>
>>
>
> --
> Oliver Deakin
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>
>
Re: [drlvm] Loading 50:0 format class files
Posted by Oliver Deakin <ol...@googlemail.com>.
Alexey Varlamov wrote:
>> The changes that went into JSR202 include:
>> - split verifier support
>> - increase various size limits
>> - adding support for class literals
>> - minor changes to support Java language changes
>>
>> I'm assuming that the problem in DRLVM is the loading on class literals.
>>
>
> Actually the class literals were incorporated in Java 5 (v49.0), as
> well as other minor features for language support. AFAIK there are no
> Java language changes between Java 5 and 6.
> DRLVM does support these features, so the evil should be somewhere else.
>
Hi Alexey,
I have replied about this issue in another part of this thread [1]. It
seems there is a problem with some code intended for debug in the
verifier. After the initial java 6 method verify, the debug code then
tries to recompute the stack map table (which only seems to include Java
5 references oddly) and then verify the method again, and this is where
we fail. Without the debug code in place the verification completes
successfully.
Any ideas why the failure is occurring or why we would want to do the
second verify in debug mode after recomputing the stack map table?
Regards,
Oliver
[1]
http://mail-archives.apache.org/mod_mbox/harmony-dev/200909.mbox/%3c4A9FD5E6.6060701@googlemail.com%3e
> [snip]
>
>> I'm happy to keep testing, and if we can make progress quickly then
>> let's press ahead, but otherwise let's open all the code and give the
>> 6.0 stream a bit more attention before attempting the 6.0M1 again.
>>
>
> Right decision is already taken ;)
>
> --
> Regards,
> Alexey
>
>
>> Regards,
>> Tim
>>
>>
>>
>
>
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [drlvm] Loading 50:0 format class files (was: Re: [vote] Declare
the signed source for r809832 as 6.0 Milestone 1)
Posted by Alexey Varlamov <al...@gmail.com>.
> The changes that went into JSR202 include:
> - split verifier support
> - increase various size limits
> - adding support for class literals
> - minor changes to support Java language changes
>
> I'm assuming that the problem in DRLVM is the loading on class literals.
Actually the class literals were incorporated in Java 5 (v49.0), as
well as other minor features for language support. AFAIK there are no
Java language changes between Java 5 and 6.
DRLVM does support these features, so the evil should be somewhere else.
[snip]
> I'm happy to keep testing, and if we can make progress quickly then
> let's press ahead, but otherwise let's open all the code and give the
> 6.0 stream a bit more attention before attempting the 6.0M1 again.
Right decision is already taken ;)
--
Regards,
Alexey
>
> Regards,
> Tim
>
>
[drlvm] Loading 50:0 format class files (was: Re: [vote] Declare
the signed source for r809832 as 6.0 Milestone 1)
Posted by Tim Ellison <t....@gmail.com>.
On 02/Sep/2009 22:46, Mark Hindess wrote:
> In message <4A...@gmail.com>, Tim Ellison writes:
>> On 02/Sep/2009 18:28, Mark Hindess wrote:
>>> In message <4A...@gmail.com>, Tim Ellison writes:
>>>> On 01/Sep/2009 08:30, Mark Hindess wrote:
>>>>> There was some agreement that we should create a 6.0 milestone
>>>>> so I'm going to begin a vote. If anyone feels that three days
>>>>> isn't enough time to complete testing then please just ask for
>>>>> more time.
>>>>>
>>>>> I have created a signed source archive for this revision and made
>>>>> it available at:
>>>>>
>>>>> http://people.apache.org/~hindessm/6.0m1/
>>>>>
>>>>> Please test these artifacts and then vote for declaring these
>>>>> source archives as 6.0 milestone 1, and opening up the remaining
>>>>> frozen code trees for general development once again.
>>>>>
>>>>> This vote will be open for at least 3 days, or until all binding
>>>>> votes have been cast (if earlier).
>>>>>
>>>>> If the vote is successful, binary builds from that level will be
>>>>> made available on the download page.
>>>> How is this going to work if the DRLVM cannot load class files
>>>> compiled for 1.6 ?! See HARMONY-6317
>>> It will load some class files compiled for 1.6. For instance, if
>>> I compile classlib with hy.javac.{source,target}=1.6 then it runs
>>> eclipse.
>> I was referring to the ability for the candidate to run applications
>> compiled with target 1.6 (not the classlib compiled with target 1.6).
>
> I know but loading classes from a classlib compiled as 1.6 level class files
> is a good test that using classes without 1.6 features are generally okay.
I see, though classlib compiled as a 1.6 format source/target may also
exhibit the same problems.
The changes that went into JSR202 include:
- split verifier support
- increase various size limits
- adding support for class literals
- minor changes to support Java language changes
I'm assuming that the problem in DRLVM is the loading on class literals.
> As I wrote later, SwingSet2.jar works for me - I've tried several version
> all with 1.6 level class files - on linux/x86.
The first thing I tried was java -version (which reported the wrong
version number) and the next was SwingSet2 from Sun JDK 6.0b16 which
failed to load classes -- so it was not a great start!
The SwingSet2 shipped with IBM JDKs works ok, so I assume that they
compile it differently.
>> AFAIK Eclipse doesn't have any 1.6 level class files.
>
> Of course.
>
>>> Do you think we should hold off releasing any 6.0 milestones
>>> until the VM supports all 1.6 features? If no one is planning to
>>> implement these we might not make any 6.0 releases for a rather long
>>> time and so the 6.0 classlib code wont get released/exercised?
>> No, I understand this is an early driver, so if there are some
>> limitations then putting them into the README is fine. However, if we
>> cannot run any 1.6 class files then that is a show stopper IMHO.
>
> Sorry, it wasn't clear from the JIRA you pointed to that you couldn't
> run *any* 1.6 class files, I assumed the problematic classes used 1.6
> specific features.
I can run some class files compiled with the 1.6 compiler. I haven't
checked the class file format but assume that they are Major 50 Minor 0
format, in which case as I said above I think we should understand the
limitation we have got and mention it in the readme.
>> I also think we should fix HARMONY-6330, even in the first milestone,
>> as that is just silly.
>
> Well, please vote -1 and save anyone wasting more time testing. ;-)
Ok.
>>> I'm fine if we decide not to make a release now but we should decide
>>> exactly what the "must have" features are for milestone 1.
>> Agreed. But I think we need to make a quick decision about whether
>> the relevant branches need to remain frozen or not.
>
> If windows is as bad as you say then I'd be inclined to delay 6.0M1
> until after 5.0M12 to give us time to fix it.
>
> And re-open the entire code base ASAP.
I'm happy to keep testing, and if we can make progress quickly then
let's press ahead, but otherwise let's open all the code and give the
6.0 stream a bit more attention before attempting the 6.0M1 again.
Regards,
Tim
Re: [vote] Declare the signed source for r809832 as 6.0 Milestone 1
Posted by Mark Hindess <ma...@googlemail.com>.
In message <4A...@gmail.com>, Tim Ellison writes:
>
> On 02/Sep/2009 18:28, Mark Hindess wrote:
> > In message <4A...@gmail.com>, Tim Ellison writes:
> >> On 01/Sep/2009 08:30, Mark Hindess wrote:
> >>> There was some agreement that we should create a 6.0 milestone
> >>> so I'm going to begin a vote. If anyone feels that three days
> >>> isn't enough time to complete testing then please just ask for
> >>> more time.
> >>>
> >>> I have created a signed source archive for this revision and made
> >>> it available at:
> >>>
> >>> http://people.apache.org/~hindessm/6.0m1/
> >>>
> >>> Please test these artifacts and then vote for declaring these
> >>> source archives as 6.0 milestone 1, and opening up the remaining
> >>> frozen code trees for general development once again.
> >>>
> >>> This vote will be open for at least 3 days, or until all binding
> >>> votes have been cast (if earlier).
> >>>
> >>> If the vote is successful, binary builds from that level will be
> >>> made available on the download page.
> >>
> >> How is this going to work if the DRLVM cannot load class files
> >> compiled for 1.6 ?! See HARMONY-6317
> >
> > It will load some class files compiled for 1.6. For instance, if
> > I compile classlib with hy.javac.{source,target}=1.6 then it runs
> > eclipse.
>
> I was referring to the ability for the candidate to run applications
> compiled with target 1.6 (not the classlib compiled with target 1.6).
I know but loading classes from a classlib compiled as 1.6 level class files
is a good test that using classes without 1.6 features are generally okay.
As I wrote later, SwingSet2.jar works for me - I've tried several version
all with 1.6 level class files - on linux/x86.
> AFAIK Eclipse doesn't have any 1.6 level class files.
Of course.
> > Do you think we should hold off releasing any 6.0 milestones
> > until the VM supports all 1.6 features? If no one is planning to
> > implement these we might not make any 6.0 releases for a rather long
> > time and so the 6.0 classlib code wont get released/exercised?
>
> No, I understand this is an early driver, so if there are some
> limitations then putting them into the README is fine. However, if we
> cannot run any 1.6 class files then that is a show stopper IMHO.
Sorry, it wasn't clear from the JIRA you pointed to that you couldn't
run *any* 1.6 class files, I assumed the problematic classes used 1.6
specific features.
> I also think we should fix HARMONY-6330, even in the first milestone,
> as that is just silly.
Well, please vote -1 and save anyone wasting more time testing. ;-)
> > I'm fine if we decide not to make a release now but we should decide
> > exactly what the "must have" features are for milestone 1.
>
> Agreed. But I think we need to make a quick decision about whether
> the relevant branches need to remain frozen or not.
If windows is as bad as you say then I'd be inclined to delay 6.0M1
until after 5.0M12 to give us time to fix it.
And re-open the entire code base ASAP.
-Mark.
Re: [vote] Declare the signed source for r809832 as 6.0 Milestone
1
Posted by Tim Ellison <t....@gmail.com>.
On 02/Sep/2009 18:28, Mark Hindess wrote:
> In message <4A...@gmail.com>, Tim Ellison writes:
>> On 01/Sep/2009 08:30, Mark Hindess wrote:
>>> There was some agreement that we should create a 6.0 milestone so I'm
>>> going to begin a vote. If anyone feels that three days isn't enough
>>> time to complete testing then please just ask for more time.
>>>
>>> I have created a signed source archive for this revision and made it
>>> available at:
>>>
>>> http://people.apache.org/~hindessm/6.0m1/
>>>
>>> Please test these artifacts and then vote for declaring these source
>>> archives as 6.0 milestone 1, and opening up the remaining frozen
>>> code trees for general development once again.
>>>
>>> This vote will be open for at least 3 days, or until all binding
>>> votes have been cast (if earlier).
>>>
>>> If the vote is successful, binary builds from that level will be
>>> made available on the download page.
>> How is this going to work if the DRLVM cannot load class files
>> compiled for 1.6 ?! See HARMONY-6317
>
> It will load some class files compiled for 1.6. For instance, if I
> compile classlib with hy.javac.{source,target}=1.6 then it runs eclipse.
I was referring to the ability for the candidate to run applications
compiled with target 1.6 (not the classlib compiled with target 1.6).
AFAIK Eclipse doesn't have any 1.6 level class files.
> Do you think we should hold off releasing any 6.0 milestones until the
> VM supports all 1.6 features? If no one is planning to implement these
> we might not make any 6.0 releases for a rather long time and so the 6.0
> classlib code wont get released/exercised?
No, I understand this is an early driver, so if there are some
limitations then putting them into the README is fine. However, if we
cannot run any 1.6 class files then that is a show stopper IMHO.
I also think we should fix HARMONY-6330, even in the first milestone, as
that is just silly.
> I'm fine if we decide not to make a release now but we should decide
> exactly what the "must have" features are for milestone 1.
Agreed. But I think we need to make a quick decision about whether the
relevant branches need to remain frozen or not.
Regards,
Tim
Re: [vote] Declare the signed source for r809832 as 6.0 Milestone
1
Posted by Oliver Deakin <ol...@googlemail.com>.
Oliver Deakin wrote:
> Mark Hindess wrote:
>> In message <20...@d06av04.portsmouth.uk.ibm.com>,
>> Mark Hindess writes:
>>
>>> In message <4A...@gmail.com>, Tim Ellison writes:
>>>
>>>> On 01/Sep/2009 08:30, Mark Hindess wrote:
>>>>
>>>>> There was some agreement that we should create a 6.0 milestone so I'm
>>>>> going to begin a vote. If anyone feels that three days isn't enough
>>>>> time to complete testing then please just ask for more time.
>>>>>
>>>>> I have created a signed source archive for this revision and made it
>>>>> available at:
>>>>>
>>>>> http://people.apache.org/~hindessm/6.0m1/
>>>>>
>>>>> Please test these artifacts and then vote for declaring these source
>>>>> archives as 6.0 milestone 1, and opening up the remaining frozen
>>>>> code trees for general development once again.
>>>>>
>>>>> This vote will be open for at least 3 days, or until all binding
>>>>> votes have been cast (if earlier).
>>>>>
>>>>> If the vote is successful, binary builds from that level will be
>>>>> made available on the download page.
>>>>>
>>>> How is this going to work if the DRLVM cannot load class files
>>>> compiled for 1.6 ?! See HARMONY-6317
>>>>
>>> It will load some class files compiled for 1.6. For instance, if I
>>> compile classlib with hy.javac.{source,target}=1.6 then it runs
>>> eclipse.
>>>
>>> Do you think we should hold off releasing any 6.0 milestones until the
>>> VM supports all 1.6 features? If no one is planning to implement these
>>> we might not make any 6.0 releases for a rather long time and so the
>>> 6.0
>>> classlib code wont get released/exercised?
>>>
>>> I'm fine if we decide not to make a release now but we should decide
>>> exactly what the "must have" features are for milestone 1.
>>>
>>
>> I've just checked a SwingSet2.jar from Sun 1.6.0_16-b01 (linux/x86) and
>> it works for me on a build based on these source artifacts.
>>
>
> Using my 6.0 federation build (not direct from the source artifacts,
> but should be the same repo revision) I see the same failure as Tim on
> Windows x86 running SwingSet2 from 1.6.0_14-b08:
>
> Uncaught exception in Thread-264:
> java.lang.VerifyError:
> BezierAnimationPanel.paint(Ljava/awt/Graphics;)V, pass: 0
> , instr: 67, reason: incorrect constantpool entry
> at java.lang.ClassLoader.defineClass0(ClassLoader.java)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:367)
> <etc.>
>
> I've had a hunt down through the code, and I can see the error is
> being thrown in vf_Context_6::read_types() in context_6.cpp (the
> ITEM_OBJECT case). cpool_get_class() is returning false, and this
> seems to be caused by the call to read_uint16() a few lines earlier
> returning 0 for the constant pool index (which I think is invalid). I
> don't know what the exact reason for the 0 return is yet - if anyone
> who understands the code better could take a look that would be very
> helpful.
Ok, a little more progress on this today - I've tracked the failure down
to the 2nd call to context6.verify_method(method) in vf_verify6_class()
in ver.cpp. The first call to verify_method() for
BezierAnimationPanel.paint() completes successfully, but the 2nd one fails.
Interestingly, the 2nd call to verify_method() is in an "#ifndef
_NDEBUG" block but, as far as I can see, _NDEBUG is never defined in the
build files so we always build this code. The source actually uses both
_NDEBUG and NDEBUG (which _is_ defined in common-vm.xml) in different
places, so I think we should change the _NDEBUGs to NDEBUG so they are
compiled as I'm assuming they were intended.
Back to the original issue - if I compile without that particular
_NDEBUG block (i.e. remove the 2nd call to verify_method) then the code
is verified and executes successfully until we later hit another exception:
java.lang.NoClassDefFoundError:
javax/swing/filechooser/FileNameExtensionFilter
which is to be expected because we do not have this class implemented in
our swing module.
It's not clear to me why we make the 2nd verify_method() call at all.
Does anyone know why additional debug code would be doing this?
Regards,
Oliver
>
> Regards,
> Oliver
>
>
>> Regards,
>> Mark.
>>
>>
>>
>>
>
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [vote] Declare the signed source for r809832 as 6.0 Milestone
1
Posted by Oliver Deakin <ol...@googlemail.com>.
Mark Hindess wrote:
> In message <20...@d06av04.portsmouth.uk.ibm.com>,
> Mark Hindess writes:
>
>> In message <4A...@gmail.com>, Tim Ellison writes:
>>
>>> On 01/Sep/2009 08:30, Mark Hindess wrote:
>>>
>>>> There was some agreement that we should create a 6.0 milestone so I'm
>>>> going to begin a vote. If anyone feels that three days isn't enough
>>>> time to complete testing then please just ask for more time.
>>>>
>>>> I have created a signed source archive for this revision and made it
>>>> available at:
>>>>
>>>> http://people.apache.org/~hindessm/6.0m1/
>>>>
>>>> Please test these artifacts and then vote for declaring these source
>>>> archives as 6.0 milestone 1, and opening up the remaining frozen
>>>> code trees for general development once again.
>>>>
>>>> This vote will be open for at least 3 days, or until all binding
>>>> votes have been cast (if earlier).
>>>>
>>>> If the vote is successful, binary builds from that level will be
>>>> made available on the download page.
>>>>
>>> How is this going to work if the DRLVM cannot load class files
>>> compiled for 1.6 ?! See HARMONY-6317
>>>
>> It will load some class files compiled for 1.6. For instance, if I
>> compile classlib with hy.javac.{source,target}=1.6 then it runs eclipse.
>>
>> Do you think we should hold off releasing any 6.0 milestones until the
>> VM supports all 1.6 features? If no one is planning to implement these
>> we might not make any 6.0 releases for a rather long time and so the 6.0
>> classlib code wont get released/exercised?
>>
>> I'm fine if we decide not to make a release now but we should decide
>> exactly what the "must have" features are for milestone 1.
>>
>
> I've just checked a SwingSet2.jar from Sun 1.6.0_16-b01 (linux/x86) and
> it works for me on a build based on these source artifacts.
>
Using my 6.0 federation build (not direct from the source artifacts, but
should be the same repo revision) I see the same failure as Tim on
Windows x86 running SwingSet2 from 1.6.0_14-b08:
Uncaught exception in Thread-264:
java.lang.VerifyError: BezierAnimationPanel.paint(Ljava/awt/Graphics;)V,
pass: 0
, instr: 67, reason: incorrect constantpool entry
at java.lang.ClassLoader.defineClass0(ClassLoader.java)
at java.lang.ClassLoader.defineClass(ClassLoader.java:367)
<etc.>
I've had a hunt down through the code, and I can see the error is being
thrown in vf_Context_6::read_types() in context_6.cpp (the ITEM_OBJECT
case). cpool_get_class() is returning false, and this seems to be caused
by the call to read_uint16() a few lines earlier returning 0 for the
constant pool index (which I think is invalid). I don't know what the
exact reason for the 0 return is yet - if anyone who understands the
code better could take a look that would be very helpful.
Regards,
Oliver
> Regards,
> Mark.
>
>
>
>
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [vote] Declare the signed source for r809832 as 6.0 Milestone 1
Posted by Mark Hindess <ma...@googlemail.com>.
In message <20...@d06av04.portsmouth.uk.ibm.com>,
Mark Hindess writes:
>
> In message <4A...@gmail.com>, Tim Ellison writes:
> >
> > On 01/Sep/2009 08:30, Mark Hindess wrote:
> > >
> > > There was some agreement that we should create a 6.0 milestone so I'm
> > > going to begin a vote. If anyone feels that three days isn't enough
> > > time to complete testing then please just ask for more time.
> > >
> > > I have created a signed source archive for this revision and made it
> > > available at:
> > >
> > > http://people.apache.org/~hindessm/6.0m1/
> > >
> > > Please test these artifacts and then vote for declaring these source
> > > archives as 6.0 milestone 1, and opening up the remaining frozen
> > > code trees for general development once again.
> > >
> > > This vote will be open for at least 3 days, or until all binding
> > > votes have been cast (if earlier).
> > >
> > > If the vote is successful, binary builds from that level will be
> > > made available on the download page.
> >
> > How is this going to work if the DRLVM cannot load class files
> > compiled for 1.6 ?! See HARMONY-6317
>
> It will load some class files compiled for 1.6. For instance, if I
> compile classlib with hy.javac.{source,target}=1.6 then it runs eclipse.
>
> Do you think we should hold off releasing any 6.0 milestones until the
> VM supports all 1.6 features? If no one is planning to implement these
> we might not make any 6.0 releases for a rather long time and so the 6.0
> classlib code wont get released/exercised?
>
> I'm fine if we decide not to make a release now but we should decide
> exactly what the "must have" features are for milestone 1.
I've just checked a SwingSet2.jar from Sun 1.6.0_16-b01 (linux/x86) and
it works for me on a build based on these source artifacts.
Regards,
Mark.