Re: GTK peer switching JNIEnv *?

[Mark Wielaard]

Hi,

On Fri, 2005-01-14 at 08:48 +0100, Michael Koch wrote:
> Am Freitag, 14. Januar 2005 04:49 schrieb Archie Cobbs:
> > I got an assertion failure in JC when running a simple Swing app.
> > The stack trace showed JC invoking a gtkpeer native method with
> > one JNIEnv *, some gtk code, and then gtkpeer calling back into
> > JC via the JNI invocation interface with a *different* JNIEnv *
> > (belonging to a different thread), i.e.:
> >
> > ...
> >
> > Before I go digging into the GTK code, has anyone else seen this?
> >
> > NOTE: this is with Classpath 0.12, so it might be fixed already
> > (has anyone fixed a bug like this lately?)
> >
> > Thanks for any hints about where to look, etc.
> 
> We triggered exactly the same bug with jamvm lately. Mark found out it 
> was a bug in jamvm handling JNIEnv* wrongly. I don't know if this was 
> a fix or a hack. But it helped. Perhaps its a bug in JCVM regarding 
> handling of JNIEnv.

It was kind of a hack. There was a real bug in how the JNIEnv was stack
allocated which meant that even the same thread would not get the same
JNIEnv each time. All threads now just get the same (static) JNIEnv
which works for now.

> The GTK peer saves a JNIEnv* pointer for later use for the callback 
> methods. This is according to the JNI spec at least not absolutely 
> correct. The correct way would be to get the current JNIEnv* object 
> through the global JavaVM object. That is not done yet. Perhaps this 
> would help you and other VMs.

Yes, we should do it this way. We actually already store the_vm (JavaVM)
when we initialize gtk+ together with the gdk_env (JNIEnv). Everywhere
we use the stored gdk_env we should carefully look whether it is only
used from the original gtk+ event thread (directly or through a
callback) oitherwise we should get the JNIEnv from the_vm.

Note that the gtk+ AWT peer code has recently (after 0.13) changed to
use only one event thread. But there are probably code paths that can
call into native code from a different (user) thread. I nice addition to
the runtime jni support would be a (slow) debugging path to check for
this at native method call time.

Cheers,

Mark


signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: FAQ, 4.1 OutOfMemoryException

[Andrew Haley]

Artur Biesiadowski writes:
 > Sascha Brawer wrote:
 > 
 > > I was just re-reading the FAQ [1] -- what would speak against 
 > > pre-allocating thread-specific OutOfMemoryException objects when 
 > > creating a thread? (Probably more a VM-specific thing, but since it's 
 > > mentioned in the Classpath FAQ...)
 > 
 > You have basically two choices with implementing OOME. You can go
 > stacktrace-less route (only throw it, do not provide entire stack
 > trace with it) - then you can get away with single instance per
 > entire jvm, as it has no state. Or you can try to fit stack in
 > there - but place for it has to be preallocated. Memory usage can
 > start to sum up if you will preallocate it for every thread out
 > there. This looks like optimizing for very rare case for me and
 > making more garbage in the heap that it is needed for all normal
 > jvm runs.

Right.  In practice, handling OutOfMemoryException in a sane way is
extremely difficult.  I suspect the only real way to do it reliably is
reserve memory so that there is space for the exception to throw, but
then you need to stop other threads running during that time.

 > I'm not sure if danger of many threads throwing OOME at the same
 > time is really so big. Every sane jvm will trigger full gc before
 > throwing OOME - and to have full gc going, there has to be some
 > kind of synchronization on memory allocation between all threads. I
 > suppose it should be possible to lock heap/gc for as long as it is
 > needed to unwind stack to point where OOME is catched (if ever),
 > perform another gc and only then unblock heap monitor.

Indeed.  The problem is that anything you do when catching an
OutOfMemoryException risks running out of memory!  There's not much
any java program can do other than logging the failure and exiting.

Andrew.


___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: FAQ, 4.1 OutOfMemoryException

[Chris Burdess]

Andrew Haley wrote:
Indeed.  The problem is that anything you do when catching an
OutOfMemoryException risks running out of memory!  There's not much
any java program can do other than logging the failure and exiting.
To be pedantic, it's OutOfMemoryError, and the same applies largely to 
any other Error (except possibly in the case of reflection tools).
--
Chris Burdess


___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: FAQ, 4.1 OutOfMemoryException

[Andrew Haley]

Chris Burdess writes:
 > Andrew Haley wrote:
 > > Indeed.  The problem is that anything you do when catching an
 > > OutOfMemoryException risks running out of memory!  There's not much
 > > any java program can do other than logging the failure and exiting.
 > 
 > To be pedantic, it's OutOfMemoryError,

Ahh, cut 'n paste.

 > and the same applies largely to any other Error (except possibly in
 > the case of reflection tools).

Not really.  For example, it's not unreasonable to catch
java.lang.NoClassDefFoundError, which may be thrown when a subsystem
is badly configured.

Andrew.


___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: What are tainted developers allowed to work on?

[James Damour]

On Thu, 2005-01-13 at 21:12 +0100, Mark Wielaard wrote:
> Hi,
> 
> On Sun, 2005-01-09 at 18:06 +0100, Mark Wielaard wrote:
> > > If we cannot find a solution on at least one of those points because
> > > of legal uncertainity whom do we have to ask then (FSF legal?)
> > > and who is doing the communication?
> > 
> > That should be me. I will ask FSF legal again if they have anything to
> > add to the above (or if I say something which is completely wrong) and
> > the summary you made of the discussion.
> 
> The reply from licensing was that they had nothing to add to the
> previous email explaining the situation.
> 
> I also wrote the following to a more specific question of helping out on
> GNU Classpath and asked if they could check my answer and point out
> anything I said wrongly or to give any suggestions on how I can
> formulate our rules more clearly. To which the reply was that the
> following explanation is fine.
> 
> [Can someone who has seen Sun source code for a particular part
> of the core libraries contribute to GNU Classpath?]
> 
> Depends. (I will forward a copy of this answer to FSF legal so
> they can check what I say.)
> 
> If the developer got access to the source code by signing some
> contract (like the SCSL) with Sun then it would be best to
> examine that contract (by FSF legal) before deciding.
> 
> If the developer just accidentally saw some of the source code
> and had no intention (and didn't actually) study the
> implementation (with the intention of contributing to GNU
> Classpath) there is no problem.
> 
> Studying a proprietary implementation with the intention of
> implementing it (better) for GNU Classpath is a clear no-no. The
> general rule is that if you have looked at or studied any
> (proprietary) implementation of a package you should not work on
> that package for GNU Classpath. That is because it would be
> difficult to proof that you really did an independent
> implementation. Since what you create might look very similar
> (which is not unlikely). Working on something completely
> unrelated is OK (as long as there are no contractual obligations
> with Sun or some other company to not do this of course).
> 
> The important thing is that we want to be clear on the fact that
> we created an independent implementation. We don't want to get
> into tricky legal situations. We want to avoid risking to go to
> court over reverse engineering or clean room situation questions
> if not absolutely necessary. That is why we in general just say
> "please don't contribute if you looked at other
> implementations". If someone thinks that their actions might be
> explained as copying directly or indirectly another
> (proprietary) implementation then that could be a problem that
> we want to avoid.
> 
> FSF Legal will always advise not to take any unnecessary risks
> that might endanger the (perceived) free software status of a
> GNU project. (If we might need to go to court to proof that what
> we did was OK, then don't!)
> 
> I hope these summaries clear up any confusion about the "tainted"
> question.

They did for me.  "Caesar's wife must be above suspicion" is the word of
the day.  Mauve tests and general documentation should be fine... and
Javadocs in packages I have never seen are certainly open.  The rest
raise questions, and the FSF really wants to avoid any question that
could land them in court.
> 
> Cheers,
> 
> Mark


signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: GTK peer switching JNIEnv *?

[Robert Lougher]

Hi,

> > We triggered exactly the same bug with jamvm lately. Mark found out it
> > was a bug in jamvm handling JNIEnv* wrongly. I don't know if this was
> > a fix or a hack. But it helped. Perhaps its a bug in JCVM regarding
> > handling of JNIEnv.
> 
> It was kind of a hack. There was a real bug in how the JNIEnv was stack
> allocated which meant that even the same thread would not get the same
> JNIEnv each time. All threads now just get the same (static) JNIEnv
> which works for now.
> 

JamVM doesn't care which JNIEnv you use as it contains nothing but the
JNI function table pointer.  The stack allocation caused a problem
because the gtk peer code cached the pntr and tried to use it later
after the function had returned.

> > The GTK peer saves a JNIEnv* pointer for later use for the callback
> > methods. This is according to the JNI spec at least not absolutely
> > correct. The correct way would be to get the current JNIEnv* object
> > through the global JavaVM object. That is not done yet. Perhaps this
> > would help you and other VMs.
> 
> Yes, we should do it this way. We actually already store the_vm (JavaVM)
> when we initialize gtk+ together with the gdk_env (JNIEnv). Everywhere
> we use the stored gdk_env we should carefully look whether it is only
> used from the original gtk+ event thread (directly or through a
> callback) oitherwise we should get the JNIEnv from the_vm.
> 

This would also have fixed the problem with JamVM.  However, stack
allocation was a bad idea (I've even forgotten why I did it).  Making
it static means there's only ever one JNIEnv*, which is fine for JamVM
as it's got no thread-specific stuff in it.  The spec just says that
the "VM is guaranteed to pass the same interface pointer to a native
method when it makes multiple calls to the native method from the same
Java thread".  It would be an interesting question to ask if JNI code
should expect the JNIEnv* to be different for different threads. 
Opinions?

> Note that the gtk+ AWT peer code has recently (after 0.13) changed to
> use only one event thread. But there are probably code paths that can
> call into native code from a different (user) thread. I nice addition to
> the runtime jni support would be a (slow) debugging path to check for
> this at native method call time.
> 
> Cheers,
> 
> Mark
> 
> 
> ___
> Classpath mailing list
> Classpath@gnu.org
> http://lists.gnu.org/mailman/listinfo/classpath
> 
> 
> 
>


___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

A few Mauve cleanups

[S. Meslin-Weber]

Hi Everyone,

I've been working on JUnit wrapper for Mauve suitable for running Mauve
from within Eclipse's JUnit visual runner; without requiring a posix
environment (no configure or make steps required)[1].

I've found a few 'Tags:' header lines in non-test classes (ones not
derived from Testlet) which confused my simple file parser. I'm
attaching a patch for these.

I'd also welcome some discussion with regards to adding Eclipse project
files into Mauve such as where should they go - or should they go in at
all - to make writing Mauve test cases for those without access to a
posix environment as painless as possible.

Best regards,

Steph

[1] Screenshot of my work in progress:
http://adorphuye.com/gallery/Miscellaneous/MauveJUnitWrapper_001

-- 

Stephane Meslin-Weber Email: [EMAIL PROTECTED]
Software Engineer Web: http://odonata.tangency.co.uk

Index: gnu/testlet/java/lang/reflect/sub/OtherPkg.java
===
RCS file: /cvs/mauve/mauve/gnu/testlet/java/lang/reflect/sub/OtherPkg.java,v
retrieving revision 1.1
diff -u -r1.1 OtherPkg.java
--- gnu/testlet/java/lang/reflect/sub/OtherPkg.java 25 Oct 2003 08:43:43 
-  1.1
+++ gnu/testlet/java/lang/reflect/sub/OtherPkg.java 14 Jan 2005 13:39:37 
-
@@ -1,5 +1,3 @@
-// Tags: JDK1.1
-
 package gnu.testlet.java.lang.reflect.sub;
 
 public class OtherPkg
Index: gnu/testlet/java/lang/reflect/sub/Super.java
===
RCS file: /cvs/mauve/mauve/gnu/testlet/java/lang/reflect/sub/Super.java,v
retrieving revision 1.1
diff -u -r1.1 Super.java
--- gnu/testlet/java/lang/reflect/sub/Super.java25 Oct 2003 08:43:43 
-  1.1
+++ gnu/testlet/java/lang/reflect/sub/Super.java14 Jan 2005 13:39:37 
-
@@ -1,5 +1,3 @@
-// Tags: JDK1.1
-
 package gnu.testlet.java.lang.reflect.sub;
 
 public class Super
Index: gnu/testlet/java/net/Socket/TestSocketImplFactory.java
===
RCS file: 
/cvs/mauve/mauve/gnu/testlet/java/net/Socket/TestSocketImplFactory.java,v
retrieving revision 1.4
diff -u -r1.4 TestSocketImplFactory.java
--- gnu/testlet/java/net/Socket/TestSocketImplFactory.java  2 Jan 2005 
21:13:21 -   1.4
+++ gnu/testlet/java/net/Socket/TestSocketImplFactory.java  14 Jan 2005 
13:39:37 -
@@ -1,5 +1,3 @@
-// Tags: JDK1.1
-
 /*
   Copyright (C) 2003 C. Brian Jones
   Copyright (C) 2004 Mark J. Wielaard
Index: gnu/testlet/java/nio/Buffer/PlainBufferTest.java
===
RCS file: /cvs/mauve/mauve/gnu/testlet/java/nio/Buffer/PlainBufferTest.java,v
retrieving revision 1.4
diff -u -r1.4 PlainBufferTest.java
--- gnu/testlet/java/nio/Buffer/PlainBufferTest.java17 Jul 2004 17:01:03 
-  1.4
+++ gnu/testlet/java/nio/Buffer/PlainBufferTest.java14 Jan 2005 13:39:38 
-
@@ -1,5 +1,3 @@
-// Tags: JDK1.4
-
 // Copyright (C) 2004 Max Gilead <[EMAIL PROTECTED]>
 
 // This file is part of Mauve.
Index: gnu/testlet/java/nio/Buffer/WrappedWithOffsetBufferTest.java
===
RCS file: 
/cvs/mauve/mauve/gnu/testlet/java/nio/Buffer/WrappedWithOffsetBufferTest.java,v
retrieving revision 1.4
diff -u -r1.4 WrappedWithOffsetBufferTest.java
--- gnu/testlet/java/nio/Buffer/WrappedWithOffsetBufferTest.java17 Jul 
2004 17:01:03 -  1.4
+++ gnu/testlet/java/nio/Buffer/WrappedWithOffsetBufferTest.java14 Jan 
2005 13:39:38 -
@@ -1,5 +1,3 @@
-// Tags: JDK1.4
-
 // Copyright (C) 2004 Max Gilead <[EMAIL PROTECTED]>
 
 // This file is part of Mauve.
Index: gnu/testlet/javax/swing/undo/UndoManager/TestUndoManager.java
===
RCS file: 
/cvs/mauve/mauve/gnu/testlet/javax/swing/undo/UndoManager/TestUndoManager.java,v
retrieving revision 1.1
diff -u -r1.1 TestUndoManager.java
--- gnu/testlet/javax/swing/undo/UndoManager/TestUndoManager.java   11 Feb 
2004 12:15:32 -  1.1
+++ gnu/testlet/javax/swing/undo/UndoManager/TestUndoManager.java   14 Jan 
2005 13:39:40 -
@@ -1,5 +1,3 @@
-// Tags: JDK1.2
-
 // Copyright (C) 2004 Sascha Brawer <[EMAIL PROTECTED]>
 
 // This file is part of Mauve.


signature.asc
Description: Digital signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: GTK peer switching JNIEnv *?

[Mark Wielaard]

Hi,

On Fri, 2005-01-14 at 13:49 +, Robert Lougher wrote:
> Making
> it static means there's only ever one JNIEnv*, which is fine for JamVM
> as it's got no thread-specific stuff in it.

This is the same model as used by libgcj. But kissme for example has
different structures for each thread. (And indeed has trouble with our
gtk+ peer model at the moment.)

> The spec just says that
> the "VM is guaranteed to pass the same interface pointer to a native
> method when it makes multiple calls to the native method from the same
> Java thread".  It would be an interesting question to ask if JNI code
> should expect the JNIEnv* to be different for different threads. 
> Opinions?

The JNI book (8.1.1) says: "The Java virtual machine passes a native
method the same JNIEnv pointer in consecutive invocations from the same
thread, but passes different JNIEnv pointers when invoking that native
method from different threads." and (11.5.1) says: "Native code may use
the JNIEnv pointer as a thread ID that remains unique for the lifetime
of the thread."

Although I admit never having seen code actually use the JNIEnv pointer
as a unique thread ID. I do interpret this as saying that it could do
that and that the runtime must guarantee that each (java-level) thread
should have its own unique JNIEnv associated with it.

Cheers,

Mark


signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: A few Mauve cleanups

[S. Meslin-Weber]

And as requested by Michael Koch, here's a version of the patch without
the ChangeLog entry...

-- 

Stephane Meslin-Weber Email: [EMAIL PROTECTED]
Software Engineer Web: http://odonata.tangency.co.uk

Index: gnu/testlet/java/lang/reflect/sub/OtherPkg.java
===
RCS file: /cvs/mauve/mauve/gnu/testlet/java/lang/reflect/sub/OtherPkg.java,v
retrieving revision 1.1
diff -u -r1.1 OtherPkg.java
--- gnu/testlet/java/lang/reflect/sub/OtherPkg.java 25 Oct 2003 08:43:43 
-  1.1
+++ gnu/testlet/java/lang/reflect/sub/OtherPkg.java 14 Jan 2005 13:39:37 
-
@@ -1,5 +1,3 @@
-// Tags: JDK1.1
-
 package gnu.testlet.java.lang.reflect.sub;
 
 public class OtherPkg
Index: gnu/testlet/java/lang/reflect/sub/Super.java
===
RCS file: /cvs/mauve/mauve/gnu/testlet/java/lang/reflect/sub/Super.java,v
retrieving revision 1.1
diff -u -r1.1 Super.java
--- gnu/testlet/java/lang/reflect/sub/Super.java25 Oct 2003 08:43:43 
-  1.1
+++ gnu/testlet/java/lang/reflect/sub/Super.java14 Jan 2005 13:39:37 
-
@@ -1,5 +1,3 @@
-// Tags: JDK1.1
-
 package gnu.testlet.java.lang.reflect.sub;
 
 public class Super
Index: gnu/testlet/java/net/Socket/TestSocketImplFactory.java
===
RCS file: 
/cvs/mauve/mauve/gnu/testlet/java/net/Socket/TestSocketImplFactory.java,v
retrieving revision 1.4
diff -u -r1.4 TestSocketImplFactory.java
--- gnu/testlet/java/net/Socket/TestSocketImplFactory.java  2 Jan 2005 
21:13:21 -   1.4
+++ gnu/testlet/java/net/Socket/TestSocketImplFactory.java  14 Jan 2005 
13:39:37 -
@@ -1,5 +1,3 @@
-// Tags: JDK1.1
-
 /*
   Copyright (C) 2003 C. Brian Jones
   Copyright (C) 2004 Mark J. Wielaard
Index: gnu/testlet/java/nio/Buffer/PlainBufferTest.java
===
RCS file: /cvs/mauve/mauve/gnu/testlet/java/nio/Buffer/PlainBufferTest.java,v
retrieving revision 1.4
diff -u -r1.4 PlainBufferTest.java
--- gnu/testlet/java/nio/Buffer/PlainBufferTest.java17 Jul 2004 17:01:03 
-  1.4
+++ gnu/testlet/java/nio/Buffer/PlainBufferTest.java14 Jan 2005 13:39:38 
-
@@ -1,5 +1,3 @@
-// Tags: JDK1.4
-
 // Copyright (C) 2004 Max Gilead <[EMAIL PROTECTED]>
 
 // This file is part of Mauve.
Index: gnu/testlet/java/nio/Buffer/WrappedWithOffsetBufferTest.java
===
RCS file: 
/cvs/mauve/mauve/gnu/testlet/java/nio/Buffer/WrappedWithOffsetBufferTest.java,v
retrieving revision 1.4
diff -u -r1.4 WrappedWithOffsetBufferTest.java
--- gnu/testlet/java/nio/Buffer/WrappedWithOffsetBufferTest.java17 Jul 
2004 17:01:03 -  1.4
+++ gnu/testlet/java/nio/Buffer/WrappedWithOffsetBufferTest.java14 Jan 
2005 13:39:38 -
@@ -1,5 +1,3 @@
-// Tags: JDK1.4
-
 // Copyright (C) 2004 Max Gilead <[EMAIL PROTECTED]>
 
 // This file is part of Mauve.
Index: gnu/testlet/javax/swing/undo/UndoManager/TestUndoManager.java
===
RCS file: 
/cvs/mauve/mauve/gnu/testlet/javax/swing/undo/UndoManager/TestUndoManager.java,v
retrieving revision 1.1
diff -u -r1.1 TestUndoManager.java
--- gnu/testlet/javax/swing/undo/UndoManager/TestUndoManager.java   11 Feb 
2004 12:15:32 -  1.1
+++ gnu/testlet/javax/swing/undo/UndoManager/TestUndoManager.java   14 Jan 
2005 13:39:40 -
@@ -1,5 +1,3 @@
-// Tags: JDK1.2
-
 // Copyright (C) 2004 Sascha Brawer <[EMAIL PROTECTED]>
 
 // This file is part of Mauve.


signature.asc
Description: Digital signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: A few Mauve cleanups

[S. Meslin-Weber]

And apologies for making such a mess of the first patch.

Please find attached a patch without CRLF and _with_ the necessary
changes to the ChangeLog!

Best regards,

Steph

--

Stephane Meslin-Weber Email: [EMAIL PROTECTED]
Software Engineer Web: http://odonata.tangency.co.uk

Index: ChangeLog
===
RCS file: /cvs/mauve/mauve/ChangeLog,v
retrieving revision 1.818
diff -u -r1.818 ChangeLog
--- ChangeLog   14 Jan 2005 08:39:23 -  1.818
+++ ChangeLog   14 Jan 2005 13:39:34 -
@@ -1,3 +1,13 @@
+2005-01-14  Stéphane Meslin-Weber  <[EMAIL PROTECTED]>
+
+   * gnu/testlet/java/reflect/sub/OtherPkg.java,
+   * gnu/testlet/java/reflect/sub/Super.java,
+   * gnu/testlet/java/net/Socket/TestSocketImplFactory.java,
+   * gnu/testlet/java/nio/Buffer/PlainBuffer.java,
+   * gnu/testlet/java/nio/Buffer/WrappedWithOffsetBuffer.java,
+   * gnu/testlet/javax/swing/undo/UndoManager/TestUndoManager.java:
+   Removed 'Tags:' header line from classes not extending Testlet.
+
 2005-01-14  Arnaud Vandyck  <[EMAIL PROTECTED]>
 
* gnu/testlet/javax/swing/text/StringContent/stickyPosition.java:
Index: gnu/testlet/java/lang/reflect/sub/OtherPkg.java
===
RCS file: /cvs/mauve/mauve/gnu/testlet/java/lang/reflect/sub/OtherPkg.java,v
retrieving revision 1.1
diff -u -r1.1 OtherPkg.java
--- gnu/testlet/java/lang/reflect/sub/OtherPkg.java 25 Oct 2003 08:43:43 
-  1.1
+++ gnu/testlet/java/lang/reflect/sub/OtherPkg.java 14 Jan 2005 13:39:37 
-
@@ -1,5 +1,3 @@
-// Tags: JDK1.1
-
 package gnu.testlet.java.lang.reflect.sub;
 
 public class OtherPkg
Index: gnu/testlet/java/lang/reflect/sub/Super.java
===
RCS file: /cvs/mauve/mauve/gnu/testlet/java/lang/reflect/sub/Super.java,v
retrieving revision 1.1
diff -u -r1.1 Super.java
--- gnu/testlet/java/lang/reflect/sub/Super.java25 Oct 2003 08:43:43 
-  1.1
+++ gnu/testlet/java/lang/reflect/sub/Super.java14 Jan 2005 13:39:37 
-
@@ -1,5 +1,3 @@
-// Tags: JDK1.1
-
 package gnu.testlet.java.lang.reflect.sub;
 
 public class Super
Index: gnu/testlet/java/net/Socket/TestSocketImplFactory.java
===
RCS file: 
/cvs/mauve/mauve/gnu/testlet/java/net/Socket/TestSocketImplFactory.java,v
retrieving revision 1.4
diff -u -r1.4 TestSocketImplFactory.java
--- gnu/testlet/java/net/Socket/TestSocketImplFactory.java  2 Jan 2005 
21:13:21 -   1.4
+++ gnu/testlet/java/net/Socket/TestSocketImplFactory.java  14 Jan 2005 
13:39:37 -
@@ -1,5 +1,3 @@
-// Tags: JDK1.1
-
 /*
   Copyright (C) 2003 C. Brian Jones
   Copyright (C) 2004 Mark J. Wielaard
Index: gnu/testlet/java/nio/Buffer/PlainBufferTest.java
===
RCS file: /cvs/mauve/mauve/gnu/testlet/java/nio/Buffer/PlainBufferTest.java,v
retrieving revision 1.4
diff -u -r1.4 PlainBufferTest.java
--- gnu/testlet/java/nio/Buffer/PlainBufferTest.java17 Jul 2004 17:01:03 
-  1.4
+++ gnu/testlet/java/nio/Buffer/PlainBufferTest.java14 Jan 2005 13:39:38 
-
@@ -1,5 +1,3 @@
-// Tags: JDK1.4
-
 // Copyright (C) 2004 Max Gilead <[EMAIL PROTECTED]>
 
 // This file is part of Mauve.
Index: gnu/testlet/java/nio/Buffer/WrappedWithOffsetBufferTest.java
===
RCS file: 
/cvs/mauve/mauve/gnu/testlet/java/nio/Buffer/WrappedWithOffsetBufferTest.java,v
retrieving revision 1.4
diff -u -r1.4 WrappedWithOffsetBufferTest.java
--- gnu/testlet/java/nio/Buffer/WrappedWithOffsetBufferTest.java17 Jul 
2004 17:01:03 -  1.4
+++ gnu/testlet/java/nio/Buffer/WrappedWithOffsetBufferTest.java14 Jan 
2005 13:39:38 -
@@ -1,5 +1,3 @@
-// Tags: JDK1.4
-
 // Copyright (C) 2004 Max Gilead <[EMAIL PROTECTED]>
 
 // This file is part of Mauve.
Index: gnu/testlet/javax/swing/undo/UndoManager/TestUndoManager.java
===
RCS file: 
/cvs/mauve/mauve/gnu/testlet/javax/swing/undo/UndoManager/TestUndoManager.java,v
retrieving revision 1.1
diff -u -r1.1 TestUndoManager.java
--- gnu/testlet/javax/swing/undo/UndoManager/TestUndoManager.java   11 Feb 
2004 12:15:32 -  1.1
+++ gnu/testlet/javax/swing/undo/UndoManager/TestUndoManager.java   14 Jan 
2005 13:39:40 -
@@ -1,5 +1,3 @@
-// Tags: JDK1.2
-
 // Copyright (C) 2004 Sascha Brawer <[EMAIL PROTECTED]>
 
 // This file is part of Mauve.


signature.asc
Description: Digital signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: GTK peer switching JNIEnv *?

[Etienne Gagnon]

Robert Lougher wrote:
Opinions?
How about "specification" instead?  :-)
http://java.sun.com/docs/books/jni/html/design.html#10110
 11.5.1 Organization of the JNIEnv Interface Pointer
 ...
 Because the JNIEnv interface pointer is thread-local, native code must
 not use the JNIEnv interface pointer belonging to one thread in another
 thread. Native code may use the JNIEnv pointer as a thread ID that
 remains unique for the lifetime of the thread.
Actually, it's even documented as a common pitfall:
http://java.sun.com/docs/books/jni/html/pitfalls.html#11233
 10.14 Using the JNIEnv across Threads
 The JNIEnv pointer, passed as the first argument to every native
 method, can only be used in the thread with which it is associated. It
 is wrong to cache the JNIEnv interface pointer obtained from one
 thread, and use that pointer in another thread. Section 8.1.4 explains
 how you can obtain the JNIEnv interface pointer for the current thread.
Etienne
--
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM:   http://www.sablevm.org/
SableCC:   http://www.sablecc.org/


signature.asc
Description: OpenPGP digital signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: GTK peer switching JNIEnv *?

[Robert Lougher]

Hi Michael,

> I don't wanna bother you but when will next jamvm version get
> released ? currently its hard to use because we need to apply 4
> patches to jamvm to be able to run GNU classpath from CVS.
> 
> 

Yes, I've seen the reports...  I'll release it over the weekend, once
I've had chance to test it against current CVS.  Sorry, but I don't
have CVS access during the week, and I want to avoid another broken
release like 1.2.2...

Thanks,

Rob.

> Michael
> --
> Homepage: http://www.worldforge.org/
>


___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: GTK peer switching JNIEnv *?

[Robert Lougher]

> The JNI book (8.1.1) says: "The Java virtual machine passes a native
> method the same JNIEnv pointer in consecutive invocations from the same
> thread, but passes different JNIEnv pointers when invoking that native
> method from different threads." and (11.5.1) says: "Native code may use
> the JNIEnv pointer as a thread ID that remains unique for the lifetime
> of the thread."
> 
> Although I admit never having seen code actually use the JNIEnv pointer
> as a unique thread ID. I do interpret this as saying that it could do
> that and that the runtime must guarantee that each (java-level) thread
> should have its own unique JNIEnv associated with it.
> 

So to be compliant I've got to use a separate JNIEnv for each thread,
but there's no point putting anything in it, because it'll break with
the gtk code :)

I'll make it my internal thread structure, adding the function table
pntr to the beginning -- this is obviously what the spec expects it to
be.  I didn't do this before because it makes the thread structure
bigger, even for threads that never call into JNI.  Of course, I won't
be able to assume it's the right one, and still look it up via
pthreads.  A future optimisation.

Thanks,

Rob.

> Cheers,
> 
> Mark
> 
> 
>


___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: GTK peer switching JNIEnv *?

[Michael Koch]

Am Freitag, 14. Januar 2005 15:59 schrieb Robert Lougher:
> > The JNI book (8.1.1) says: "The Java virtual machine passes a
> > native method the same JNIEnv pointer in consecutive invocations
> > from the same thread, but passes different JNIEnv pointers when
> > invoking that native method from different threads." and (11.5.1)
> > says: "Native code may use the JNIEnv pointer as a thread ID that
> > remains unique for the lifetime of the thread."
> >
> > Although I admit never having seen code actually use the JNIEnv
> > pointer as a unique thread ID. I do interpret this as saying that
> > it could do that and that the runtime must guarantee that each
> > (java-level) thread should have its own unique JNIEnv associated
> > with it.
>
> So to be compliant I've got to use a separate JNIEnv for each
> thread, but there's no point putting anything in it, because it'll
> break with the gtk code :)
>
> I'll make it my internal thread structure, adding the function
> table pntr to the beginning -- this is obviously what the spec
> expects it to be.  I didn't do this before because it makes the
> thread structure bigger, even for threads that never call into JNI.
>  Of course, I won't be able to assume it's the right one, and still
> look it up via pthreads.  A future optimisation.

I don't wanna bother you but when will next jamvm version get 
released ? currently its hard to use because we need to apply 4 
patches to jamvm to be able to run GNU classpath from CVS.


Michael
-- 
Homepage: http://www.worldforge.org/


___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: GTK peer switching JNIEnv *?

[Archie Cobbs]

Robert Lougher wrote:
It would be an interesting question to ask if JNI code
should expect the JNIEnv* to be different for different threads. 
Opinions?
Stop the nonsense! :-)
The idea that there is anything other than a 1:1 pairing between
threads and JNIEnv * pointers is crazy^H^H^H^H^Hincorrect. Quoting:
  http://java.sun.com/j2se/1.4.2/docs/guide/jni/spec/design.html
The JNI interface pointer is only valid in the current thread. A native 
method, therefore, must not pass the interface pointer from one thread to 
another. A VM implementing the JNI may allocate and store thread-local data 
in the area pointed to by the JNI interface pointer.

Native methods receive the JNI interface pointer as an argument. The VM is 
guaranteed to pass the same interface pointer to a native method when it 
makes multiple calls to the native method from the same Java thread. 
However, a native method can be called from different Java threads, and 
therefore may receive different JNI interface pointers.

-Archie
__
Archie Cobbs  *CTO, Awarix*  http://www.awarix.com
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: GTK peer switching JNIEnv *?

[Archie Cobbs]

Michael Koch wrote:
The JNIEnv * passed back in frame #23 is different from the one
passed back in frame #7 (not visible in the trace, but I know it's
different).
We triggered exactly the same bug with jamvm lately. Mark found out it 
was a bug in jamvm handling JNIEnv* wrongly. I don't know if this was 
a fix or a hack. But it helped. Perhaps its a bug in JCVM regarding 
handling of JNIEnv.

The GTK peer saves a JNIEnv* pointer for later use for the callback 
methods. This is according to the JNI spec at least not absolutely 
correct. The correct way would be to get the current JNIEnv* object 
through the global JavaVM object. That is not done yet. Perhaps this 
would help you and other VMs.
I'm fairly certain that JC is not mishandling the JNIEnv *. Also,
it is obvious from inspecting the stack that the JNIEnv * changed
when going through the gtkpeer native code.
Apparently the GTK code is saving the JNIEnv * in one thread,
and then using it in a different thread. My guess is that the
callback function is being called by some other thread within
GTK that's not attached to the VM, then picking up the JNIEnv *
that was saved previously in a different (non-callback) thread.
If so, this is completely broken, as JNIEnv *'s are thread specific.
However, the AttachCurrentThread() can be used to attach a new thread
and get a new one for a thread if needed.
Perhaps the GTK peer should use pthread_[sg]etspecific() to store
the JNIEnv * instead of whatever it's currently doing. This would
ensure that the rigth JNIEnv * got used. However, the GTK stuff
would also then have to keep track attaching and detaching threads
to the VM as necessary.
-Archie
__
Archie Cobbs  *CTO, Awarix*  http://www.awarix.com
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: GTK peer switching JNIEnv *?

[Archie Cobbs]

Robert Lougher wrote:
So to be compliant I've got to use a separate JNIEnv for each thread,
but there's no point putting anything in it, because it'll break with
the gtk code :)
No, I don't think the VM has to use different JNIEnv * pointers
for different threads. But it may. The point is that the onus is on
the native code to use the one provided by the VM consistently
with that same thread, no matter what the VM does. The VM is the
"master" and the native code is the "slave" in other words.
For example, the VM could have a single JNIEnv * pointer, and then
use pthread_getspecific() at each crossing into/out of native code
to determine which thread it's actually dealing with.
-Archie
__
Archie Cobbs  *CTO, Awarix*  http://www.awarix.com
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: GTK peer switching JNIEnv *?

[Robert Lougher]

> Robert Lougher wrote:
> > So to be compliant I've got to use a separate JNIEnv for each thread,
> > but there's no point putting anything in it, because it'll break with
> > the gtk code :)
>
> No, I don't think the VM has to use different JNIEnv * pointers
> for different threads. But it may. The point is that the onus is on
> the native code to use the one provided by the VM consistently
> with that same thread, no matter what the VM does. The VM is the
> "master" and the native code is the "slave" in other words.
>
> For example, the VM could have a single JNIEnv * pointer, and then
> use pthread_getspecific() at each crossing into/out of native code
> to determine which thread it's actually dealing with.
>

And that is exactly what JamVM does, which is why it doesn't care what
the JNIEnv* is.  But people have pointed out that it is expected to be
unique and unchanging for every thread.

After making myself look well and truly stupid I should say that I
_have_ read the JNI specification.  The original one, not the book :

http://java.sun.com/j2se/1.3/docs/guide/jni/spec/jniTOC.doc.html

And that says nothing about using the JNIEnv* as a thread ID.

It says threads _may_ see a different JNIEnv* if they're called by
different threads.  Without anything explicit about being able to use
them as thread IDs, I took the "shortcut" of not bothering.  This code
was written a _long_ time ago when JamVM was just my little toy VM and
it's been lurking ever since.

Rob.

- Hide quoted text -

> -Archie
>
>


___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: GTK peer switching JNIEnv *?

[Chris Gray]

On Friday 14 January 2005 15:59, Robert Lougher wrote:

> I'll make it my internal thread structure, adding the function table
> pntr to the beginning -- this is obviously what the spec expects it to
> be.

Yup, and it's what Wonka has always done.

>  I didn't do this before because it makes the thread structure
> bigger, even for threads that never call into JNI.  Of course, I won't
> be able to assume it's the right one, and still look it up via
> pthreads.  A future optimisation.

We just cast the JNIEnv* pointer to a pointer to a thread structure, without 
performing any checks. If people pass bogus pointers to JNI, crashing is 
correct behaviour ...

-- 
Chris Gray  /k/ Embedded Java Solutions
Embedded & Mobile Java, OSGihttp://www.kiffer.be/k/
[EMAIL PROTECTED] +32 3 216 0369

Visit us at Embedded World 2005 
22--24 Feb. 2005 at the Nürnberg Messe (Germany), booth 10-504



___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: Sleeping at FOSDEM

[Arnaud Vandyck]

Thu, 13 Jan 2005 10:32:41 +0100, 
Sascha Brawer <[EMAIL PROTECTED]> wrote: 

> Sounds pretty cool. Actually, who is going to FOSDEM? May
> ex-classpath-hackers-gone-lurking come, too?

Good to hear you Sascha! Of course you are welcome! ;-)

-- 
 Arnaud Vandyck
  ,= ,-_-. =.
 ((_/)o o(\_))
  `-'(. .)`-'
  \_/


___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: FAQ, 4.1 OutOfMemoryException

[Chris Gray]

On Friday 14 January 2005 13:24, Andrew Haley wrote:
> Chris Burdess writes:
>  > Andrew Haley wrote:
>  > > Indeed.  The problem is that anything you do when catching an
>  > > OutOfMemoryException risks running out of memory!  There's not much
>  > > any java program can do other than logging the failure and exiting.
>  >
>  > To be pedantic, it's OutOfMemoryError,
>
> Ahh, cut 'n paste.
>
>  > and the same applies largely to any other Error (except possibly in
>  > the case of reflection tools).
>
> Not really.  For example, it's not unreasonable to catch
> java.lang.NoClassDefFoundError, which may be thrown when a subsystem
> is badly configured.

J2ME CLDC VMs are not required to handle Errors via the exception handling 
mechanism, which kind of implies that other VMs should try to do so.

An application _could_ handle an OOME by switching to a less memory-intensive 
algorithm or flushing caches, but I doubt that many do. It's a bit like doing 
something other than exit() when malloc returns NULL; a good idea in a 
compiler, but probably more trouble than it's worth in a run-off-the-mill 
app.

My own experience is that the feasibility of cleanly throwing OOME depends 
strongly on the complexity of the application. If you have 101 threads all 
trying to load classes and stuff then you'll probably end up with an OOME 
storm and end up crashing in the VM: with a single-threaded application 
you'll probably be able to throw the OOME, catch it in the 
uncaughtExceptionHandler of the root ThreadGroup, and do a clean exit.

-- 
Chris Gray  /k/ Embedded Java Solutions
Embedded & Mobile Java, OSGihttp://www.kiffer.be/k/
[EMAIL PROTECTED] +32 3 216 0369

Visit us at Embedded World 2005 
22--24 Feb. 2005 at the Nürnberg Messe (Germany), booth 10-504



___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: Sleeping at FOSDEM

[Robert Lougher]

Hi,

Are many people from the runtimes going?  I really enjoyed it last
year, and I'd like to go again this year.

Rob.

On Fri, 14 Jan 2005 18:19:47 +0100, Arnaud Vandyck <[EMAIL PROTECTED]> wrote:
> Thu, 13 Jan 2005 10:32:41 +0100,
> Sascha Brawer <[EMAIL PROTECTED]> wrote:
> 
> > Sounds pretty cool. Actually, who is going to FOSDEM? May
> > ex-classpath-hackers-gone-lurking come, too?
> 
> Good to hear you Sascha! Of course you are welcome! ;-)
> 
> --
> Arnaud Vandyck
>  ,= ,-_-. =.
> ((_/)o o(\_))
>  `-'(. .)`-'
>  \_/
> 
> ___
> Classpath mailing list
> Classpath@gnu.org
> http://lists.gnu.org/mailman/listinfo/classpath
>


___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: FAQ, 4.1 OutOfMemoryException

[Chris Gray]

On Thursday 13 January 2005 15:08, Artur Biesiadowski wrote:
> Sascha Brawer wrote:
> > I was just re-reading the FAQ [1] -- what would speak against
> > pre-allocating thread-specific OutOfMemoryException objects when
> > creating a thread? (Probably more a VM-specific thing, but since it's
> > mentioned in the Classpath FAQ...)
>
> You have basically two choices with implementing OOME. You can go
> stacktrace-less route (only throw it, do not provide entire stack trace
> with it) - then you can get away with single instance per entire jvm, as
> it has no state. Or you can try to fit stack in there - but place for it
> has to be preallocated. Memory usage can start to sum up if you will
> preallocate it for every thread out there. This looks like optimizing
> for very rare case for me and making more garbage in the heap that it is
> needed for all normal jvm runs.

This was my conclusion too in the end - the thread-specific OOME object with 
preallocated stack trace ties up a lot of memory without actually solving the 
problem. So either do nothing and let nature take its course, or have a truly 
lightweight solution which will allow the OOME to be thrown without a stack 
trace (could be as little as a 1-bit flag in the thread control block),

> I'm not sure if danger of many threads throwing OOME at the same time is
> really so big. Every sane jvm will trigger full gc before throwing OOME
> - and to have full gc going, there has to be some kind of
> synchronization on memory allocation between all threads [...]

A VM with a mostly-concurrent GC might not conform to this model.

Chris

-- 
Chris Gray  /k/ Embedded Java Solutions
Embedded & Mobile Java, OSGihttp://www.kiffer.be/k/
[EMAIL PROTECTED] +32 3 216 0369

Visit us at Embedded World 2005 
22--24 Feb. 2005 at the Nürnberg Messe (Germany), booth 10-504



___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

Re: Sleeping at FOSDEM

[Patrik Reali]

Hi!
just to say that this year I won't attend FOSDEM; I really would like to, 
but  I'm in California till the end of march.

-Patrik
--On Freitag, 14. Januar 2005 17:53 + Robert Lougher 
<[EMAIL PROTECTED]> wrote:

Hi,
Are many people from the runtimes going?  I really enjoyed it last
year, and I'd like to go again this year.
Rob.
On Fri, 14 Jan 2005 18:19:47 +0100, Arnaud Vandyck <[EMAIL PROTECTED]> wrote:
Thu, 13 Jan 2005 10:32:41 +0100,
Sascha Brawer <[EMAIL PROTECTED]> wrote:
> Sounds pretty cool. Actually, who is going to FOSDEM? May
> ex-classpath-hackers-gone-lurking come, too?
Good to hear you Sascha! Of course you are welcome! ;-)
--
Arnaud Vandyck
 ,= ,-_-. =.
((_/)o o(\_))
 `-'(. .)`-'
 \_/
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath

___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath


___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath