jython-users

[Jython-users] JDK1.4 instability with Jython

[Jeff E. <je...@ad...>]

Until recently, I've been using Jython 2.1a3 and JDK1.3.1
on a 2-CPU Win2K box with great success.  I just switched to
JDK1.4rc and am having terrible problems with the JVM crashing.
I upgraded to Jython 2.1, but the same problems remain.  It's not
as bad with java -server, except that runs substantially slower.
Unfortunately, I can't seem to recreate the problem in an isolated
test case.

Last summer, someone posted that they couldn't even run pystone.py
with the JDK1.4 beta.  Curiously, when I run pystone.py with JDK1.3
and java -server, the JVM crashes.  It works with JDK1.4 with and
without -server.

Has anyone else had similar experiences?  Any suggestions?


Jeff Emanuel

pystone stats for the curious:

C:\>java -showversion org.python.util.jython pystone.py
java version "1.4.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-rc-b91)
Java HotSpot(TM) Client VM (build 1.4.0-rc-b91, mixed mode)

Pystone(1.1) time for 10000 passes = 1.655
This machine benchmarks at 6042.3 pystones/second

C:\>java -server -showversion org.python.util.jython pystone.py
java version "1.4.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-rc-b91)
Java HotSpot(TM) Server VM (build 1.4.0-rc-b91, mixed mode)

Pystone(1.1) time for 10000 passes = 2.718
This machine benchmarks at 3679.18 pystones/second

C:\>java -showversion org.python.util.jython pystone.py
java version "1.3.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01)
Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)

Pystone(1.1) time for 10000 passes = 1.156
This machine benchmarks at 8650.52 pystones/second

Re: [Jython-users] JDK1.4 instability with Jython

[Jeff E. <je...@ad...>]

Now I have a test case that will crash the jvm for me under JDK1.4
on Win2K.  Feed crash.py to jython.  If it doesn't crash the jvm,
try changing the value of m.  Can anyone find a way to determine
where the jvm's fault lies so that I can file a bug report with Sun?


I wrote:

> 
> Until recently, I've been using Jython 2.1a3 and JDK1.3.1
> on a 2-CPU Win2K box with great success.  I just switched to
> JDK1.4rc and am having terrible problems with the JVM crashing.
> I upgraded to Jython 2.1, but the same problems remain.  It's not
> as bad with java -server, except that runs substantially slower.
> Unfortunately, I can't seem to recreate the problem in an isolated
> test case.

Re: [Jython-users] JDK1.4 instability with Jython

[Jan W. <j.w...@sc...>]

On Fri, Feb 08, 2002 at 09:03:40AM -0700, Jeff Emanuel wrote:
[...]
> [Filename: crash.py, Content-Type: text/plain]
> The attachment file in the message has been removed by eManager.

> [Filename: Crash.java, Content-Type: text/plain]
> The attachment file in the message has been removed by eManager.

Hm, somebody didnt like your attachment? Perhaps the filename?

Cheerio,
--=20
J.W...@sc...  -  Fon +4970719457-257 Fax-211
science+computing ag - Hagellocher Weg 71-75 - 72070 T=FCbingen
Lisp is truly amazing.  Anything that's cool in any language existed in L=
isp
before, and probably is still more usable in Lisp. (W. Tanksley in c.l.py=
thon)

Re: [Jython-users] JDK1.4 instability with Jython

[Jeff E. <je...@ad...>]

Ok, here are the files inline:

crash.py:
import java, Crash

def makeContainer(n,m):
   c=java.util.LinkedList()
   for i in range(n):
     c.add(Crash(m))
   return c

def crash(it):
   while it.hasNext():
     node = it.next()
     node.data = java.lang.Object()

if __name__=="__main__":
   n=100000
   m=222
   container=makeContainer(n,m)
   crash(container.iterator())



Crash.java:
public class Crash {
   public Object data;
   public Crash(int n) {
     data=new byte[n];
   }
}

Thanks for your interest.

Re: [Jython-users] JDK1.4 instability with Jython

[Kevin B. <kb...@ca...>]

Very interesting.

Looks like a definite bug in the garbage collector or assignment behavior, but I'm not conversant enough w/ the Java VM internals to pursue it further.  I moved everything to Java then brought pieces back to Python, and found some interesting things.  It only occurs if the assignment is in Python, and only if we allocate a new Jython Instance each time.

Here's my output w/ -verbose:gc

[GC 511K->143K(1984K), 0.0063209 secs]
[GC 646K->154K(1984K), 0.0057092 secs]
[GC 666K->334K(1984K), 0.0076847 secs]
[GC 846K->609K(1984K), 0.0089791 secs]
[GC 1121K->769K(1984K), 0.0077756 secs]
[GC 1349K->972K(1984K), 0.0075615 secs]
[GC 1484K->1017K(1984K), 0.0041208 secs]
[GC 1529K->1529K(2112K), 0.0108365 secs]
[Full GC 1529K->1256K(2112K), 0.1101383 secs]
[GC 1768K->1768K(2672K), 0.0089964 secs]
[GC 2280K->2280K(2800K), 0.0093338 secs]
[Full GC[Unloading class sun.reflect.GeneratedMethodAccessor1]
 2280K->2280K(2800K), 0.1113977 secs]
[GC 2735K->2735K(4284K), 0.0495713 secs]
[GC 3247K->3247K(4284K), 0.0097242 secs]
[GC 3759K->3759K(4284K), 0.0100759 secs]
[GC 4271K->4271K(4796K), 0.0101293 secs]
[Full GC 4271K->4271K(4796K), 0.1363462 secs]
[GC 4731K->4731K(7612K), 0.0557635 secs]
[GC 5243K->5243K(7612K), 0.0109620 secs]
[GC 5755K->5755K(7612K), 0.0101355 secs]
[GC 6267K->6267K(7612K), 0.0105186 secs]
[GC 6779K->6779K(7612K), 0.0099337 secs]
[GC 7291K->7291K(7868K), 0.0099397 secs]
[Full GC 7291K->7231K(7868K), 0.2444919 secs]
[GC 8127K->8127K(13016K), 0.0159969 secs]
[GC 9023K->9023K(13016K), 0.0183957 secs]
[GC 9918K->9918K(13016K), 0.0185267 secs]
[GC 10814K->10814K(13016K), 0.0156633 secs]
[GC 11710K->11710K(13016K), 0.0180231 secs]
[GC 12606K->12606K(13528K), 0.0179447 secs]
[Full GC 12606K->12606K(13528K), 0.2222574 secs]
[GC 14103K->14103K(22612K), 0.1005230 secs]
[GC 15639K->15639K(22612K), 0.0282855 secs]
[GC 17175K->17175K(22612K), 0.0373953 secs]
[GC 18711K->18711K(22612K), 0.0282713 secs]
[GC 20247K->20247K(22612K), 0.0307812 secs]
[GC 21783K->21783K(23380K), 0.0296263 secs]
[Full GC 21783K->21783K(23380K), 0.3246291 secs]
[GC 24275K->24275K(39012K), 0.1485914 secs]
[GC 26835K->26835K(39012K), 0.0468365 secs]
256 512 768 1024 1280 1536 1792 2048 2304 2560 2816 3072 3328 3584 3840 4096 4352 4608 4864 5120 5376 5632 5888 6144 6400 6656 6912 7168 7424 7680 7936 8192 8448 8704 8960 9216 9472 9728 9984 10240 10496 10752 [GC 29395K->28034K(39012K), 0.0413931 secs]
11008 11264 11520 11776 12032 12288 12544 12800 13056 13312 13568 13824 14080 14336 14592 14848 15104 15360 15616 15872 16128 16384 16640 16896 17152 17408 17664 17920 18176 18432 18688 18944 19200 19456 19712 19968 20224 20480 20736 20992 21248 21504 21760 22016 22272 22528 22784 23040 23296 23552 23808 24064 24320 24576 24832 25088 25344 25600 25856 26112 26368 26624 26880 27136 27392 27648 27904 28160 28416 28672 28928 29184 29440 29696 [GC


Yes, the protection fault occurred just after writing '[GC'

Here's the code (Crash.java): 

import org.python.util.PythonInterpreter; 
import org.python.core.*; 
import java.util.*;

public class Crash {
    public Object data;
    public Crash(int n) {
        data=new byte[n];
    }

    static PythonInterpreter cInterp = new PythonInterpreter();
    static PyCode cCode = 
        __builtin__.compile( "obj.data = newvalue", "<string>", "exec" );

    static
    {
        cInterp.set( "newvalue", new Object() );
    }

    // only crashes if DO_EACH and DO_PYTHON are both true
    static boolean DO_EACH = true;
    static boolean DO_PYTHON = true;
        
    public static void replace( Object o )
    {
        cInterp.set( "obj", o );
        if ( DO_EACH )
        {
            cInterp.set( "newvalue", new Object() );
        }
        if ( DO_PYTHON )
        {
            cInterp.exec( cCode );
        }
        else
        {
            ((Crash)o).data = new PyJavaInstance( new Object() );
        }
    }

    public static void iterate( Collection c )
    {
        Iterator i = c.iterator();
        int n =0;
        while (i.hasNext())
        {
            if ( (++n & 255) == 0 )
                System.out.print( n + " " );
            replace( i.next() );
        }
    }
        
    public static Collection makeCollection( int n, int m )
    {
        Collection c = new LinkedList();
        for ( int i = 0; i < n; i++ )
        {
            c.add( new Crash( m ));
        }
        return c;
    }

    public static void crash( int n, int m )
    {
        iterate( makeCollection( n, m ));
    }

    public static void main(String []args)
    {
        int n = Integer.getInteger( "n", 100000 ).intValue();
        int m = Integer.getInteger( "m", 222 ).intValue();
        crash( n, m );
    }
}



And here's the makefile:

JDK=f:/j2sdk1.4
JAVAC=${JDK}/bin/javac
JAVA=${JDK}/bin/java
JYTHON=w:\tools\jython\jython.jar

test2: Crash.class
	${JAVA} -verbose:gc -classpath '${JYTHON};${CLASSPATH}' Crash

Jeff, do you want to/did you enter a bug, or shall I?

kb

Jeff Emanuel wrote:
> 
> Ok, here are the files inline:
> 
> crash.py:
> import java, Crash
> 
> def makeContainer(n,m):
>    c=java.util.LinkedList()
>    for i in range(n):
>      c.add(Crash(m))
>    return c
> 
> def crash(it):
>    while it.hasNext():
>      node = it.next()
>      node.data = java.lang.Object()
> 
> if __name__=="__main__":
>    n=100000
>    m=222
>    container=makeContainer(n,m)
>    crash(container.iterator())
> 
> Crash.java:
> public class Crash {
>    public Object data;
>    public Crash(int n) {
>      data=new byte[n];
>    }
> }
> 
> Thanks for your interest.

Re: [Jython-users] JDK1.4 instability with Jython

[Jeff E. <je...@ad...>]

Thanks for the great analysis.  I'll log the bug.


Kevin Butler wrote:

> Very interesting.
> 
> Looks like a definite bug in the garbage collector or assignment behavior, but I'm not conversant enough w/ the Java VM internals to pursue it further.  I moved everything to Java then brought pieces back to Python, and found some interesting things.  It only occurs if the assignment is in Python, and only if we allocate a new Jython Instance each time.
> Jeff, do you want to/did you enter a bug, or shall I?
> 
> kb

Re: [Jython-users] dir('string') in Jython / Python

[Oti <oh...@ya...>]

[ Waclawczyk Janusch ]

>1. 
>I'm getting following result in jython (2.1):
>  > dir("String")
>  []
>but python's (2.1) answer is:
>  > dir("string")
>  ['capitalize', 'center', ...., 'upper'] 
>Ist this intended?

>2. 
>The result of dir("string".__class__) in jython is not the same as
dir("string")
>in python.
>Why?


Hello Janusch,

please note I am not a CPython expert. Nonetheless the Jython session
below might give you some hints:

Jython 2.1 on java1.3.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> dir("String")
[]
>>> dir("string")
[]
>>> dir("any text")
[]
>>> import string
>>> dir(string)
['_StringType', '__doc__', '__file__', '__name__', '_apply', '_float',
'_idmap', '_idmapL', '_int', '_long', 'atof', 'atof_error', 'atoi',
'atoi_error', 'atol', 'atol_error', 'capitalize', 'capwords', 'center',
'count', 'digits', 'expandtabs', 'find', 'hexdigits', 'index',
'index_error', 'join', 'joinfields', 'letters', 'ljust', 'lower',
'lowercase', 'lstrip', 'maketrans', 'octdigits', 'replace', 'rfind',
'rindex', 'rjust', 'rstrip', 'split', 'splitfields', 'strip',
'swapcase', 'translate', 'upper', 'uppercase', 'whitespace', 'zfill']
>>> from java.lang import String
>>> dir(String)
['CASE_INSENSITIVE_ORDER', 'bytes', 'charAt', 'compareTo',
'compareToIgnoreCase', 'concat', 'copyValueOf', 'endsWith',
'equalsIgnoreCase', 'getBytes', 'getChars', 'indexOf', 'intern',
'lastIndexOf', 'length', 'regionMatches', 'replace', 'startsWith',
'substring', 'toCharArray', 'toLowerCase', 'toUpperCase', 'trim',
'valueOf']
>>> dir( string.__class__ )
['__delattr__', '__dict__', '__findattr__', '__setattr__', 'toString']
>>> 

Best wishes,
Oti.


__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com

[Jython-users] string.replace( java.lang.String )

[Oti <oh...@ya...>]

Hello,

I just stumbled over the following behaviour of string.replace().
Is it true I cannot pass a java.lang.String as first argument:

[appl|pwe] > jython
Jython 2.1 on java1.3.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> import string
>>> from java.lang import String
>>> old = String( "old" )
>>> string.replace( old, "l", "d" )
Traceback (innermost last):
  File "<console>", line 1, in ?
  File "e:\jython21\Lib\string.py", line 409, in replace
TypeError: replace(): expected 2 args; got 3
>>> string.replace( old.intern(), "l", "d" )
'odd'


Best wishes, and thanks,
Oti.


__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/

Re: [Jython-users] string.replace( java.lang.String )

[Samuele P. <pe...@in...>]

From: Oti <oh...@ya...>
> Hello,
> 
> I just stumbled over the following behaviour of string.replace().
> Is it true I cannot pass a java.lang.String as first argument:
> 
> [appl|pwe] > jython
> Jython 2.1 on java1.3.0 (JIT: null)
> Type "copyright", "credits" or "license" for more information.
> >>> import string
> >>> from java.lang import String
> >>> old = String( "old" )
> >>> string.replace( old, "l", "d" )
> Traceback (innermost last):
>   File "<console>", line 1, in ?
>   File "e:\jython21\Lib\string.py", line 409, in replace
> TypeError: replace(): expected 2 args; got 3
> >>> string.replace( old.intern(), "l", "d" )
> 'odd'
> 
> 

Yes, the odd behavior is expected.

You should consider that string.py is coded
assuming Python string input, and simply
using the Python string object methods.

so string.replace(s,old,new,maxsplit)

simply calls s.replace(old,new,maxsplit)

now perchance Java strings have a replace method
which takes only 2 arguments.

The other thing to consider 
is that Java constructors
called from Jython do not convert the result, its 
Java instance nature is preserved.
OTOH normal Java methods have their
results always converted following the usual
rules (eg. java.lang.String -> string):

>>> from java.lang import String
>>> s=String("java")
>>> s.__class__
<jclass java.lang.String at 8070355>
>>> type(s)
<jclass org.python.core.PyJavaInstance at 6040101>
>>> s2=s.toString()
>>> type(s) == type('')
0
>>> type(s2) == type('')
1

The following also fails:
>>> s+'__'
Traceback (innermost last):
  File "<console>", line 1, in ?
TypeError: __add__ nor __radd__ defined for these operands

I don't know if we should change all this.

regards.






 

Re: [Jython-users] string.replace( java.lang.String )

[Oti <oh...@ya...>]

[ Samuele Pedroni ]

> From: Oti <oh...@ya...>
> > Hello,
> > 
> > I just stumbled over the following behaviour of string.replace().
> > Is it true I cannot pass a java.lang.String as first argument:
> > 
> > [appl|pwe] > jython
> > Jython 2.1 on java1.3.0 (JIT: null)
> > Type "copyright", "credits" or "license" for more information.
> > >>> import string
> > >>> from java.lang import String
> > >>> old = String( "old" )
> > >>> string.replace( old, "l", "d" )
> > Traceback (innermost last):
> >   File "<console>", line 1, in ?
> >   File "e:\jython21\Lib\string.py", line 409, in replace
> > TypeError: replace(): expected 2 args; got 3
> > >>> string.replace( old.intern(), "l", "d" )
> > 'odd'
> > 
> > 
> 
> Yes, the odd behavior is expected.
> 
> You should consider that string.py is coded
> assuming Python string input, and simply
> using the Python string object methods.
> 
> so string.replace(s,old,new,maxsplit)
> 
> simply calls s.replace(old,new,maxsplit)
> 
> now perchance Java strings have a replace method
> which takes only 2 arguments.
> 
> The other thing to consider 
> is that Java constructors
> called from Jython do not convert the result, its 
> Java instance nature is preserved.
> OTOH normal Java methods have their
> results always converted following the usual
> rules (eg. java.lang.String -> string):
> 
> >>> from java.lang import String
> >>> s=String("java")
> >>> s.__class__
> <jclass java.lang.String at 8070355>
> >>> type(s)
> <jclass org.python.core.PyJavaInstance at 6040101>
> >>> s2=s.toString()
> >>> type(s) == type('')
> 0
> >>> type(s2) == type('')
> 1
> 
> The following also fails:
> >>> s+'__'
> Traceback (innermost last):
>   File "<console>", line 1, in ?
> TypeError: __add__ nor __radd__ defined for these operands
> 
> I don't know if we should change all this.

No, I think you shouldn't.

Thank you very much for your explanation.
As you might havae guessed, I am (still) struggling to upgrade from
good old JPython1.0.3, where the example above ran.
I hope these are rare cases.

Best wishes,
Oti.

__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/