Oliver Deakin wrote:
Mark Hindess wrote:
In message <200909021728.n82hsted001...@d06av04.portsmouth.uk.ibm.com>,
Mark Hindess writes:
In message <4a9e6944.9080...@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