Ivan Volosyuk wrote:
> Yes, I have done this in VMThread.run() method for newly created
> threads. But I have seen no way to do this in JNI's ThreadAttach().

Ah, ok got it.

> Looks like gnu classpath doesn't require any callbacks (like
> thread_attach()) to be called on the attached thread, so the jchevm
> doesn't do this.

and to be fair you wouldn't expect them to without reason.

> That is why in order to use classlib, this place
> needs changes in jchevm and it looks like the same applies to all
> other VMs which use gnu classpath interfaces. That is the problem I am
> talking about.

So you either have to think of ways to subvert ThreadAttach() or delay
the classlib attachment until it comes into (classlib) native code.
Either way sounds like grubby hacks required.

Regards,
Tim

> -- 
> Ivan
> 
> On 6/9/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>> Ivan Volosyuk wrote:
>> > Yes, there are a lot of functions without implementation. I have
>> > inserted this exceptions there to fast detect this places. It will
>> > also be a few UnsatisfiedLinkErrors for some missing functions in
>> > java.lang.reflect.Array.
>> > Security is just no-op for now. I have almost zero knowledge in this
>> area.
>> > Most probable reason for the hang in two luni tests is bug or
>> > unimplemented functionality in Thread.java
>> > One of problems in the Thread.java I have no clue how to solve is:
>> >  Classlib implementation uses its own thread manager implementation,
>> > jchevm has also its own. Some classlib's native methods implementation
>> > rely on thread_attach() call before them, otherwise they crash. I have
>> > implemented this in VMThread.run(). But JNI ThreadAttach in jchevm
>> > doesn't call classlib's thread_attach(), so threads attached via JNI
>> > will crash classlib.
>>
>> There are requirements on the VM in order to run the classlib native
>> code, like setting up the port library and playing nicely with the
>> thread library.  For example, native's monitor operations require that
>> the thread has been attached via hythread_attach() [1].
>>
>> I don't know the JCHEVM code well enough to point to the right place,
>> but performing an hythread_attach() when a JCHEVM thread is
>> created/attached -- and a matching detach -- would be the answer.
>>
>> [1]
>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/hythread_8c.html?view=co
>>
>>
>> Regards,
>> Tim
>>
>> > --
>> > Ivan
>> >
>> > On 6/8/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
>> >>
>> >> On 7 June 2006 at 20:50, "Mark Hindess" <[EMAIL PROTECTED]>
>> >> wrote:
>> >> >
>> >> > With HARMONY-569, HARMONY-572 and a couple of simple hacks - like
>> >> > removing the -showversion jvm arguments from test runs - I've been
>> >> > able to run 63% of the classlib tests.  I should get more running
>> with
>> >> > a little more effort.  The test results were:
>> >> >
>> >> >   Tests      Failures        Errors       Success rate
>> >> >   5601       360             744          80.29%
>> >> >
>> >> > which is v. impressive.
>> >>
>> >> I've improved my wrapper script (linux only sorry) to ignore
>> >> -showversion and handle -Xbootclasspath/[ap] appropriately.  I've
>> >> attached this to HARMONY-583.
>> >>
>> >> I had to exclude two luni tests which were causing the vm to hang:
>> >>
>> >>   tests/api/java/lang/IllegalThreadStateExceptionTest.java
>> >>   tests/api/java/lang/ThreadTest.java
>> >>
>> >> But the new test results are:
>> >>
>> >>   Tests      Failures        Errors       Success rate
>> >>   8348       1295            892          73.80%
>> >>
>> >> which is progress even though the success rate went down.
>> >>
>> >> Many of the failures share the same root causes so I think this
>> >> figure could improved pretty quickly.
>> >>
>> >> I wish there was a tool to summarise the root failures out of 2000+
>> >> junit test reports!  Just scanning at random, the most common errors
>> >> seem to be:
>> >>
>> >> 1)
>> >>
>> >>  not implemented
>> >>
>> >>  java.lang.RuntimeException: not implemented at
>> >>  java.lang.ClassLoader.getResources(ClassLoader.java:224) at
>> >> 
>> org.apache.harmony.jndi.internal.EnvironmentReader.readMultipleResourceFiles
>>
>> >>
>> >>  (EnvironmentReader.java:227) at
>> >>  org.apache.harmony.jndi.internal.EnvironmentReader$2.run
>> >>  (EnvironmentReader.java:280) at
>> >> java.security.AccessController.doPrivileged
>> >>  (AccessController.java:241) at
>> >> 
>> org.apache.harmony.jndi.internal.EnvironmentReader.readApplicationResourceFiles
>>
>> >>
>> >>  (EnvironmentReader.java:278) at
>> javax.naming.InitialContext.internalInit
>> >>  (InitialContext.java:207) at javax.naming.InitialContext.<init>
>> >>  (InitialContext.java:151) at
>> >> 
>> org.apache.harmony.jndi.tests.javax.naming.InitialContextMockTest.setUp
>> >>  (InitialContextMockTest.java:50)
>> >>
>> >> 2)
>> >>
>> >> not implemented
>> >>
>> >> java.lang.RuntimeException: not implemented at
>> >>
>> org.apache.harmony.kernel.vm.VM.getNonBootstrapClassLoader(VM.java:77) at
>> >> java.io.ObjectInputStream.readObject(ObjectInputStream.java:1942) at
>> >> java.io.ObjectInputStream.readObject(ObjectInputStream.java:1901) at
>> >> javax.security.auth.SubjectTest.test_PrincipalSetInvalidSerForm
>> >> (SubjectTest.java:1297) at java.lang.reflect.Method.invokeNative
>> >> (Method.java) at org.apache.harmony.auth.internal.SecurityTest.runTest
>> >> (SecurityTest.java:109)
>> >>
>> >> 3) Many of the crypto/auth/security tests are failing with
>> >> "implementation
>> >>    not found" type errors.
>> >>
>> >> 4)
>> >>
>> >> META-INF/ALICE.SF has invalid digest for Test.class in /var/tmp/
>> >> hyts_resources45209/TestCodeSigners.jar
>> >>
>> >> java.lang.SecurityException: META-INF/ALICE.SF has invalid digest for
>> >> Test.class in /var/tmp/hyts_resources45209/TestCodeSigners.jar at
>> >> java.util.jar.JarVerifier.verifyCertificate(JarVerifier.java:331) at
>> >> java.util.jar.JarVerifier.readCertificates(JarVerifier.java:242) at
>> >> java.util.jar.JarFile.getInputStream(JarFile.java:340) at
>> >>
>> org.apache.harmony.archive.tests.java.util.jar.JarEntryTest.test_getCodeSigners
>>
>> >>
>> >> (JarEntryTest.java:122) at
>> >> java.lang.reflect.Method.invokeNative(Method.java)
>> >>
>> >> Regards,
>> >>  Mark.
>> >
>> > ---------------------------------------------------------------------
>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>> -- 
>>
>> Tim Ellison ([EMAIL PROTECTED])
>> IBM Java technology centre, UK.
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to