gcj and UDP datagrams under freebsd

gcj and UDP datagrams under freebsd

[Mark Allman]

 
Folks-

I wonder if anyone else has had a problem using UDP datagrams under
freebsd.  I slurped the latest gcc stuff from CVS a couple of days
ago.  I have two small programs that are attached below.  They
compile using:

    gcj -o snd --main=snd snd.java -pthread
    gcj -o rcv --main=rcv rcv.java -pthread

just fine.

I run rcv -- which just sits there.  But, when I run snd I get this:

% ./snd guns
assertion "!(addr & FLAGS)" failed: file "/home/mallman/GCC/libjava/java/lang/natObject.cc", line 772
Bus error (core dumped) 

This is on a freebsd 4.4 machine.

I tried to same thing on my redhat 6.2 laptop (same version of gcc
that I grabbed from CVS a couple days ago) and it all worked as I
had envisioned.  (The difference is the I don't have to use
"-pthread" when compiling on the linux box.)

Anyone have a guess about what is going on?  Any help would be
appreciated.

Thanks!

allman


--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/


=============================================================================

import java.net.*;
import java.io.*;

class rcv
{
    public static void main (String [] args) throws SocketException, 
	IOException
    {
	DatagramSocket sock = new DatagramSocket (1234);
	byte[] buffer = new byte[256];
	DatagramPacket rpacket = new DatagramPacket (buffer,buffer.length);
	DatagramPacket spacket;
	String rcvd;
	String msg;

	sock.receive (rpacket);
	rcvd = new String (rpacket.getData());
	System.out.println ("RCVD: " + rcvd);
	msg = new String ("from receiver");
	buffer = msg.getBytes ();
	spacket = new DatagramPacket (buffer, buffer.length, 
				      rpacket.getAddress (), 
				      rpacket.getPort ());
	sock.send (spacket);
    }
}

=============================================================================

import java.net.*;
import java.io.*;

class snd
{
    public static void main (String [] args) throws SocketException, 
	IOException
    {
	DatagramSocket sock = new DatagramSocket ();
	byte[] buffer = new byte[256];
	String msg;
	DatagramPacket spacket;
	DatagramPacket rpacket;
	InetAddress address;
	String rcvd;

	if (args.length != 1)
	{
	    System.out.println("Usage: snd host");
	    return;
	}
	msg = new String ("from sender");
	buffer = msg.getBytes ();
	address = InetAddress.getByName (args[0]);
	spacket = new DatagramPacket (buffer, buffer.length, address, 1234);
	sock.send (spacket);
	rpacket = new DatagramPacket (buffer, buffer.length);
	sock.receive (rpacket);
	rcvd = new String (rpacket.getData ());
	System.out.println ("RCVD: " + rcvd);
    }
}

=============================================================================

Re: gcj and UDP datagrams under freebsd

[Loren James Rittle]

Hi Mark,

[...]
> % ./snd guns
> assertion "!(addr & FLAGS)" failed: file
> "/home/mallman/GCC/libjava/java/lang/natObject.cc", line 772
> Bus error (core dumped) 

> This is on a freebsd 4.4 machine.

A few comments.  FYI, you will experience random GC deadlocks on
FreeBSD 4.4 and all previous releases (unless you disable threads
entirely when bootstrapping gcc).  Please upgrade to
FreeBSD-4.5-RELEASE or FreeBSD-4.5-STABLE to use gcj.

However, that is not your problem here.

> I tried to same thing on my redhat 6.2 laptop (same version of gcc
> that I grabbed from CVS a couple days ago) and it all worked as I
> had envisioned.  (The difference is the I don't have to use
> "-pthread" when compiling on the linux box.)

> Anyone have a guess about what is going on?  Any help would be
> appreciated.

Yes, dear lord, this code is doing something *very* nasty with the low
bits of pointers.  Luckily, it had this nice assert() instead of
crashing wildly. ;-)

Compiling your code and running it, I see the same crash:

#2  0x2830b105 in _Jv_MonitorEnter (obj=0x285a8b8c)

with FLAGS == 7 and addr == obj, assert(!(addr & FLAGS));

Yup, that doesn't fly on this platform unless some care is used for
all memory allocations.  Until we figure out how to fully address the
situation, you could disable the hash synchronization code.  Drop this
line:

enable_hash_synchronization_default=no

into the *-*-freebsd* section of the second case in
libjava/configure.host and completely rebuild libjava (merely
rerunning make after a reconfigure doesn't work in this case).

Since I doubt I will be able to fix this before 3.1 release, I think
this should be disabled on the branch.  Funny that there were zero
test cases to catch it.  I will try to work up such a case.

Regards,
Loren

Re: gcj and UDP datagrams under freebsd

[Bryce McKinlay]

Loren James Rittle wrote:

>Compiling your code and running it, I see the same crash:
>
>#2  0x2830b105 in _Jv_MonitorEnter (obj=0x285a8b8c)
>
>with FLAGS == 7 and addr == obj, assert(!(addr & FLAGS));
>
>Yup, that doesn't fly on this platform unless some care is used for
>all memory allocations.  Until we figure out how to fully address the
>situation, you could disable the hash synchronization code.  Drop this
>line:
>

Yes, it would be good if you could figure out what "obj" is here (should 
be easy to figure out from the stack trace), and why it isn't 8-byte 
aligned.

>Since I doubt I will be able to fix this before 3.1 release, I think
>this should be disabled on the branch.
>

Sounds ok to me.

regards

Bryce.

Re: gcj and UDP datagrams under freebsd

[Loren James Rittle]

In article <3CAE5D3C.1020501@waitaki.otago.ac.nz>,
Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

> Yes, it would be good if you could figure out what "obj" is here (should 
> be easy to figure out from the stack trace), and why it isn't 8-byte 
> aligned.

Hi Bryce,

Agreed, it should be easy. ;-)  FYI, I had to recompile selected files
without -O2 to get this information (but this could be a port rather
than a general issue).  Here is the C++ code line in
libjava/java/net/natInetAddress.cc that uses the non-8-byte aligned
obj:

214           JvSynchronize sync (java::net::InetAddress::localhostAddress);

Here is the static (non-heap, non-stack) object declaration for that
object in libjava/java/net/InetAddress.java:

  private static final byte[] localhostAddress = { 127, 0, 0, 1 };

Does gcj force any alignment of static byte arrays such as this?  Or,
rather, is it suppose to do so and failing to do so here?

Perhaps Mark didn't see it on Linux with his code since it uses a
different code path than FreeBSD 4 which doesn't define
HAVE_GETHOSTBYNAME_R.  This is probably why it wasn't found when hash
synchronization was enabled everywhere.

>> Since I doubt I will be able to fix this before 3.1 release, I think
>> this should be disabled on the branch.

> Sounds ok to me.

A patch of this form appears to force the lock address to be gained
from GC malloc with correct alignment for the hash optimization but it
adds to the private part of the interface:

(I am not proposing this patch be installed as is.  In terms of what
 should go into the libjava source tree itself: It seems like the
 gethostbynameImplLock should be conditionally allocated in
 natInetAddress.cc and not visible in InetAddress.java at all but I
 didn't know the preferred libjava code base way to do that.)

Index: libjava/java/net/InetAddress.java
===================================================================
RCS file: /cvs/gcc/gcc/libjava/java/net/InetAddress.java,v
retrieving revision 1.7
diff -c -r1.7 InetAddress.java
*** libjava/java/net/InetAddress.java	12 Jan 2002 10:11:13 -0000	1.7
--- libjava/java/net/InetAddress.java	9 Apr 2002 07:28:25 -0000
***************
*** 246,251 ****
--- 246,253 ----
      
    private static final byte[] localhostAddress = { 127, 0, 0, 1 };
  
+   private static final Object gethostbynameImplLock = new Object();
+ 
    private static native String getLocalHostname ();
  
    private static InetAddress localhost = null;
Index: libjava/java/net/natInetAddress.cc
===================================================================
RCS file: /cvs/gcc/gcc/libjava/java/net/natInetAddress.cc,v
retrieving revision 1.19
diff -c -r1.19 natInetAddress.cc
*** libjava/java/net/natInetAddress.cc	28 Feb 2002 01:03:37 -0000	1.19
--- libjava/java/net/natInetAddress.cc	9 Apr 2002 07:28:25 -0000
***************
*** 211,217 ****
  #else
        // FIXME: this is insufficient if some other piece of code calls
        // this gethostbyname.
!       JvSynchronize sync (java::net::InetAddress::localhostAddress);
        hptr = gethostbyname (hostname);
  #endif /* HAVE_GETHOSTBYNAME_R */
      }
--- 211,217 ----
  #else
        // FIXME: this is insufficient if some other piece of code calls
        // this gethostbyname.
!       JvSynchronize sync (java::net::InetAddress::gethostbynameImplLock);
        hptr = gethostbyname (hostname);
  #endif /* HAVE_GETHOSTBYNAME_R */
      }
***************
*** 265,271 ****
  #else /* HAVE_GETHOSTBYADDR_R */
        // FIXME: this is insufficient if some other piece of code calls
        // this gethostbyaddr.
!       JvSynchronize sync (java::net::InetAddress::localhostAddress);
        hptr = gethostbyaddr (val, len, type);
  #endif /* HAVE_GETHOSTBYADDR_R */
      }
--- 265,271 ----
  #else /* HAVE_GETHOSTBYADDR_R */
        // FIXME: this is insufficient if some other piece of code calls
        // this gethostbyaddr.
!       JvSynchronize sync (java::net::InetAddress::gethostbynameImplLock);
        hptr = gethostbyaddr (val, len, type);
  #endif /* HAVE_GETHOSTBYADDR_R */
      }

Re: gcj and UDP datagrams under freebsd

[Bryce McKinlay]

[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

Loren James Rittle wrote:

>Here is the static (non-heap, non-stack) object declaration for that
>object in libjava/java/net/InetAddress.java:
>
>  private static final byte[] localhostAddress = { 127, 0, 0, 1 };
>
>Does gcj force any alignment of static byte arrays such as this?  Or,
>rather, is it suppose to do so and failing to do so here?
>

Exactly - good catch. We are forcing alignment for class objects but I 
forgot about static array objects. Please try this patch.

regards

Bryce.




[-- Attachment #2: java-align.patch --]
[-- Type: text/plain, Size: 1397 bytes --]

2002-04-09  Bryce McKinlay  <bryce@waitaki.otago.ac.nz>

	* class.c (make_class): Set TYPE_ALIGN here to ensure double alignment
	for all class types with hash synchronization.
	* decl.c (java_init_decl_processing): Don't set TYPE_ALIGN here.

Index: class.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/java/class.c,v
retrieving revision 1.130
diff -u -r1.130 class.c
--- class.c	3 Mar 2002 14:07:32 -0000	1.130
+++ class.c	9 Apr 2002 11:48:24 -0000
@@ -303,6 +303,10 @@
 #endif
   MAYBE_CREATE_TYPE_TYPE_LANG_SPECIFIC (type);
 
+  /* Hash synchronization requires at least double-word alignment. */
+  if (flag_hash_synchronization && POINTER_SIZE < 64)
+    TYPE_ALIGN (type) = 64;
+
   return type;
 }
 
Index: decl.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/java/decl.c,v
retrieving revision 1.125
diff -u -r1.125 decl.c
--- decl.c	29 Mar 2002 21:46:26 -0000	1.125
+++ decl.c	9 Apr 2002 11:48:29 -0000
@@ -682,10 +682,6 @@
     FIELD_PRIVATE (t) = 1;
   push_super_field (class_type_node, object_type_node);
 
-  /* Hash synchronization requires at least double-word alignment. */
-  if (flag_hash_synchronization && POINTER_SIZE < 64)
-    TYPE_ALIGN (class_type_node) = 64;
-
   FINISH_RECORD (class_type_node);
   build_decl (TYPE_DECL, get_identifier ("Class"), class_type_node);
 

Re: gcj and UDP datagrams under freebsd

[Loren James Rittle]

In article <3CB2D7EA.3090508@waitaki.otago.ac.nz>,
Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

>> Does gcj force any alignment of static byte arrays such as this?  Or,
>> rather, is it suppose to do so and failing to do so here?

> Exactly - good catch. We are forcing alignment for class objects but I 
> forgot about static array objects. Please try this patch.

Somehow, I think I just got more credit for my dumb questions than
deserved... ;-)

I added your patch to my mainline and 3.1 trees; removed my posted
hack from my mainline tree.  I will report ASAP.

Thanks Bryce!

Re: gcj and UDP datagrams under freebsd

[Loren James Rittle]

>>> Does gcj force any alignment of static byte arrays such as this?  Or,
>>> rather, is it suppose to do so and failing to do so here?

>> Exactly - good catch. We are forcing alignment for class objects but I 
>> forgot about static array objects. Please try this patch.

> I added your patch to my mainline and 3.1 trees; removed my posted
> hack from my mainline tree.  I will report ASAP.

Hi Bryce,

Test method: Fully bootstrapped and check mainline.  Added your patch.
quickstrapped gcc (i.e. rebuilt exactly two object files in gcc/java).
Freshly rebuilt libjava from scratch with new gcj.

I am fairly sure that the patch you sent to enforce 8 byte minimum
alignment in gcj doesn't work for me.  Crash at startup is seen in the
first call to _Jv_RegisterClassHookDefault called from
_Jv_RegisterClasses (called from ELF-style _init):

459       jint hash = HASH_UTF (klass->name);

Of course, I would print both klass and klass->name at this point to
help determine what is wrong.

I can't debug it any further with gdb since all I get is this message:

	can't find class named `java::lang::Class', as given by C++ RTTI

In case you know how to decode the layout of a Class (even looking at
the order of the fields in java/lang/Class.h, I can't), here is the
raw memory of the first entry in __JCR_LIST__ of the corrupt library:

0x28513780 <_ZN4java4util3jar10Attributes6class$E>:     0x0804a5f0      0x00000000      0x00000000      0x284a9b10
0x28513790 <_ZN4java4util3jar10Attributes6class$E+16>:  0x00000001      0x0804a578      0x00000002      0x284ef0c0
0x285137a0 <_ZN4java4util3jar10Attributes6class$E+32>:  0x285991e0      0x28513540      0x00140016      0x28513520
0x285137b0 <_ZN4java4util3jar10Attributes6class$E+48>:  0x00000010      0x00000001      0x28513708      0x00000000
0x285137c0 <_ZN4java4util3jar10Attributes6class$E+64>:  0x00000000      0x28513760      0x00000000      0x00000002
0x285137d0 <_ZN4java4util3jar10Attributes6class$E+80>:  0x00000000      0x00000000      0x00000000      0x00000000
0x285137e0 <_ZN4java4util3jar10Attributes6class$E+96>:  0x00000000      0x00000000      0x00000000      0x00000000
0x285137f0 <_ZN4java4util3jar10Attributes6class$E+112>: 0x00000000      0x00000000      0x00000000      0x00000000

Here is the first entry in __JCR_LIST__ of the well-build library:

0x28513b00 <_ZN4java4util3jar10Attributes6class$E>:     0x0804a5f0      0x00000000      0x284a9e90      0x00000001
0x28513b10 <_ZN4java4util3jar10Attributes6class$E+16>:  0x0804a578      0x00000002      0x284ef440      0x28599560
0x28513b20 <_ZN4java4util3jar10Attributes6class$E+32>:  0x285138c0      0x00140016      0x285138a0      0x00000008
0x28513b30 <_ZN4java4util3jar10Attributes6class$E+48>:  0x00000001      0x28513a88      0x00000000      0x00000000
0x28513b40 <_ZN4java4util3jar10Attributes6class$E+64>:  0x28513ae0      0x00000000      0x00000002      0x00000000
0x28513b50 <_ZN4java4util3jar10Attributes6class$E+80>:  0x00000000      0x00000000      0x00000000      0x00000000
0x28513b60 <_ZN4java4util3jar10Attributes6class$E+96>:  0x00000000      0x00000000      0x00000000      0x00000000
0x28513b70 <_ZN4java4util3jar10Attributes6class$E+112>: 0x00000000      0x00000000      0x00000000      0x00000000

I proposed this new test case:

	* libjava.lang/SyncGlobal.java, libjava.lang/SyncGlobal.out:
	New test case.

// Test suitability of alignment of statically-allocated Objects.
class SyncGlobal
{
  private static final byte[] global_1 = { 1 };
  private static final byte[] global_2 = { 2, 3 };
  private static final byte[] global_3 = { 4, 5, 6 };
  private static final byte[] global_4 = { 7, 8, 9, 10 };
  private static final byte[] global_5 = { 11, 12, 13, 14, 15 };
  private static final byte[] global_6 = { 16, 17, 18, 19, 20, 21 };
  private static final byte[] global_7 = { 22, 23, 24, 25, 26, 27, 28 };
  private static final byte[] global_8 = { 29, 30, 31, 32, 33, 34, 35, 36 };

  public static void main (String args[])
  {
    synchronized (global_1) { System.out.println ("PASS1"); }
    synchronized (global_2) { System.out.println ("PASS2"); }
    synchronized (global_3) { System.out.println ("PASS3"); }
    synchronized (global_4) { System.out.println ("PASS4"); }
    synchronized (global_5) { System.out.println ("PASS5"); }
    synchronized (global_6) { System.out.println ("PASS6"); }
    synchronized (global_7) { System.out.println ("PASS7"); }
    synchronized (global_8) { System.out.println ("PASS8"); }
  }
}

SyncGlobal.out:
PASS1
PASS2
PASS3
PASS4
PASS5
PASS6
PASS7
PASS8

Re: gcj and UDP datagrams under freebsd

[Bryce McKinlay]

Loren James Rittle wrote:

>I am fairly sure that the patch you sent to enforce 8 byte minimum
>alignment in gcj doesn't work for me.  Crash at startup is seen in the
>first call to _Jv_RegisterClassHookDefault called from
>_Jv_RegisterClasses (called from ELF-style _init):
>
>459       jint hash = HASH_UTF (klass->name);
>

Hmm, ok, after doing a full rebuild with my patch, I am seeing this too.

>Of course, I would print both klass and klass->name at this point to
>help determine what is wrong.
>
>I can't debug it any further with gdb since all I get is this message:
>
>	can't find class named `java::lang::Class', as given by C++ RTTI
>

GDB works OK for me BTW. Using "GNU gdb 2002-02-11-cvs" on PPC Linux.

>In case you know how to decode the layout of a Class (even looking at
>the order of the fields in java/lang/Class.h, I can't), here is the
>raw memory of the first entry in __JCR_LIST__ of the corrupt library:
>
>0x28513780 <_ZN4java4util3jar10Attributes6class$E>:     0x0804a5f0      0x00000000      0x00000000      0x284a9b10
>0x28513790 <_ZN4java4util3jar10Attributes6class$E+16>:  0x00000001      0x0804a578      0x00000002      0x284ef0c0
>

It depends if hash synchronization is in use or not. If not then the 
fields will be:

vtable
sync_info
next
name
...

all these are pointers.

Or if hash sychronization is used then they will be:

vtable
next
name
...


So if hash synchronization is in use then clearly the problem is that 
class->name is null. Inspection with GDB reveals that the class name is 
actually at class->name+4.  But I'm not sure how my patch would have 
caused this to happen!

>I proposed this new test case:
>
>	* libjava.lang/SyncGlobal.java, libjava.lang/SyncGlobal.out:
>	New test case.
>

Thanks, please check this in to mainline.

regards

Bryce.

Re: gcj and UDP datagrams under freebsd

[Loren James Rittle]

In article <3CB68E3A.2070307@waitaki.otago.ac.nz>,
Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

> GDB works OK for me BTW. Using "GNU gdb 2002-02-11-cvs" on PPC Linux.

OK, looks like I'm a few days short with 2002-02-05-cvs (or it could
be this port needs help over there as well ;-).  Thanks for the
information and the quick decode.  But I will admit that I'm somewhat
relieved that you can reproduce it as well. ;-)

> So if hash synchronization is in use then clearly the problem is that 
class-> name is null. Inspection with GDB reveals that the class name is 
> actually at class->name+4.  But I'm not sure how my patch would have 
> caused this to happen!

Ah... that explains the crash at least.

>> * libjava.lang/SyncGlobal.java, libjava.lang/SyncGlobal.out:
>> New test case.
> Thanks, please check this in to mainline.

OK, installed on mainline.  I did run the tests in the harness before
commit.  This is interesting.  The bytecode->native execution test
passes (must get padded differently, or we lucky for all 8 sizes).

Regards,
Loren

Re: gcj and UDP datagrams under freebsd

[Bryce McKinlay]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

Loren James Rittle wrote:

>>So if hash synchronization is in use then clearly the problem is that 
>>
>class-> name is null. Inspection with GDB reveals that the class name is 
>
>>actually at class->name+4.  But I'm not sure how my patch would have 
>>caused this to happen!
>>
>
>Ah... that explains the crash at least.
>

OK, duh. Class types are made up with a field_decls for their 
superclasses, so for example java.lang.Object is just a static field 
inside java.lang.Class. Setting TYPE_ALIGN on every class type results 
in the java.lang.Object fields being aligned as well within the 
java.lang.Class object. Since C++ doesn't know about this it crashes.

Could you take this one for a spin?

regards

Bryce.



[-- Attachment #2: java-align-2.patch --]
[-- Type: text/plain, Size: 2253 bytes --]

2002-04-09  Bryce McKinlay  <bryce@waitaki.otago.ac.nz>

	* class.c (make_class_data): Set DECL_ALIGN on static class data,
	for hash synchronization.
	* expr.c (java_expand_expr): Set DECL_ALIGN on static array objects.
	* decl.c (java_init_decl_processing): Don't set TYPE_ALIGN for
	class_type_node.

Index: class.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/java/class.c,v
retrieving revision 1.130
diff -u -r1.130 class.c
--- class.c	3 Mar 2002 14:07:32 -0000	1.130
+++ class.c	13 Apr 2002 03:44:35 -0000
@@ -1736,6 +1740,11 @@
   FINISH_RECORD_CONSTRUCTOR (cons);
 
   DECL_INITIAL (decl) = cons;
+  
+  /* Hash synchronization requires at least 64-bit alignment. */
+  if (flag_hash_synchronization && POINTER_SIZE < 64)
+    DECL_ALIGN (decl) = 64; 
+  
   rest_of_decl_compilation (decl, (char*) 0, 1, 0);
 }
  
Index: decl.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/java/decl.c,v
retrieving revision 1.125
diff -u -r1.125 decl.c
--- decl.c	29 Mar 2002 21:46:26 -0000	1.125
+++ decl.c	13 Apr 2002 03:44:49 -0000
@@ -682,10 +682,6 @@
     FIELD_PRIVATE (t) = 1;
   push_super_field (class_type_node, object_type_node);
 
-  /* Hash synchronization requires at least double-word alignment. */
-  if (flag_hash_synchronization && POINTER_SIZE < 64)
-    TYPE_ALIGN (class_type_node) = 64;
-
   FINISH_RECORD (class_type_node);
   build_decl (TYPE_DECL, get_identifier ("Class"), class_type_node);
 
Index: expr.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/java/expr.c,v
retrieving revision 1.143
diff -u -r1.143 expr.c
--- expr.c	4 Apr 2002 22:19:55 -0000	1.143
+++ expr.c	13 Apr 2002 03:44:59 -0000
@@ -2526,6 +2548,9 @@
 	    DECL_INITIAL (init_decl) = value;
 	    DECL_IGNORED_P (init_decl) = 1;
 	    TREE_READONLY (init_decl) = 1;
+	    /* Hash synchronization requires at least 64-bit alignment. */
+	    if (flag_hash_synchronization && POINTER_SIZE < 64)
+	      DECL_ALIGN (init_decl) = 64;
 	    rest_of_decl_compilation (init_decl, NULL, 1, 0);
 	    TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (init_decl)) = 1;
 	    init = build1 (ADDR_EXPR, TREE_TYPE (exp), init_decl);

Re: gcj and UDP datagrams under freebsd

[Tom Tromey]

>>>>> "Loren" == Loren James Rittle <rittle@latour.rsch.comm.mot.com> writes:

Loren> OK, installed on mainline.  I did run the tests in the harness
Loren> before commit.  This is interesting.  The bytecode->native
Loren> execution test passes (must get padded differently, or we lucky
Loren> for all 8 sizes).

When compiling bytecode->native we currently don't statically allocate
arrays.  That's because in the bytecode the array initialization looks
like a long series of iastore instructions; we would have to recognize
this specially to turn it into a static array initialization.  (This
is something IBM does; one of their papers describes it.)  When
compiling from .java the array initialization is represented in a way
that is easier for us to manipulate.

Tom

Re: gcj and UDP datagrams under freebsd

[Loren James Rittle]

In article <3CB7AD0F.6090800@waitaki.otago.ac.nz>,
Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

> Could you take this one for a spin?

> 2002-04-09  Bryce McKinlay  <bryce@waitaki.otago.ac.nz>

> 	* class.c (make_class_data): Set DECL_ALIGN on static class data,
> 	for hash synchronization.
> 	* expr.c (java_expand_expr): Set DECL_ALIGN on static array objects.
> 	* decl.c (java_init_decl_processing): Don't set TYPE_ALIGN for
> 	class_type_node.

Hi Bryce,

Sorry the spin took a while.  Fixed both the test case I submitted and
shows no regressions on i386-*-unknown4.5.

Thanks,
Loren

Re: gcj and UDP datagrams under freebsd

[Bryce McKinlay]

Loren James Rittle wrote:

>>2002-04-09  Bryce McKinlay  <bryce@waitaki.otago.ac.nz>
>>
>>	* class.c (make_class_data): Set DECL_ALIGN on static class data,
>>	for hash synchronization.
>>	* expr.c (java_expand_expr): Set DECL_ALIGN on static array objects.
>>	* decl.c (java_init_decl_processing): Don't set TYPE_ALIGN for
>>	class_type_node.
>>
>
>Hi Bryce,
>
>Sorry the spin took a while.  Fixed both the test case I submitted and
>shows no regressions on i386-*-unknown4.5.
>

Thanks Loren.

I believe this is pretty low risk, so I've checked it in. I've tested in 
on PowerPC linux (which also needed the TYPE_ALIGN/DECL_ALIGN stuff for 
hash synchonization) with no problems, and it does nothing on platforms 
that arn't using hash synchronization.

regards

Bryce.

RE: gcj and UDP datagrams under freebsd

[Boehm, Hans]

We had discussed dropping the three low order bits on some platforms instead
of just checking them in an assertion.  Apparently that never made it into
the code though?  That would be safe if you can guarantee that you never
acquire locks on addresses that aren't at least 8 bytes apart.

This problem should only occur if you are trying to synchronize on something
that isn't a heap allocated object.  Heap allocated objects should be 8-byte
aligned to start with.

Hans

> -----Original Message-----
> From: Loren James Rittle [mailto:rittle@latour.rsch.comm.mot.com]
> Sent: Friday, April 05, 2002 3:28 PM
> To: java@gcc.gnu.org
> Cc: mallman@grc.nasa.gov
> Subject: Re: gcj and UDP datagrams under freebsd
> 
> 
> Hi Mark,
> 
> [...]
> > % ./snd guns
> > assertion "!(addr & FLAGS)" failed: file
> > "/home/mallman/GCC/libjava/java/lang/natObject.cc", line 772
> > Bus error (core dumped) 
> 
> > This is on a freebsd 4.4 machine.
> 
> A few comments.  FYI, you will experience random GC deadlocks on
> FreeBSD 4.4 and all previous releases (unless you disable threads
> entirely when bootstrapping gcc).  Please upgrade to
> FreeBSD-4.5-RELEASE or FreeBSD-4.5-STABLE to use gcj.
> 
> However, that is not your problem here.
> 
> > I tried to same thing on my redhat 6.2 laptop (same version of gcc
> > that I grabbed from CVS a couple days ago) and it all worked as I
> > had envisioned.  (The difference is the I don't have to use
> > "-pthread" when compiling on the linux box.)
> 
> > Anyone have a guess about what is going on?  Any help would be
> > appreciated.
> 
> Yes, dear lord, this code is doing something *very* nasty with the low
> bits of pointers.  Luckily, it had this nice assert() instead of
> crashing wildly. ;-)
> 
> Compiling your code and running it, I see the same crash:
> 
> #2  0x2830b105 in _Jv_MonitorEnter (obj=0x285a8b8c)
> 
> with FLAGS == 7 and addr == obj, assert(!(addr & FLAGS));
> 
> Yup, that doesn't fly on this platform unless some care is used for
> all memory allocations.  Until we figure out how to fully address the
> situation, you could disable the hash synchronization code.  Drop this
> line:
> 
> enable_hash_synchronization_default=no
> 
> into the *-*-freebsd* section of the second case in
> libjava/configure.host and completely rebuild libjava (merely
> rerunning make after a reconfigure doesn't work in this case).
> 
> Since I doubt I will be able to fix this before 3.1 release, I think
> this should be disabled on the branch.  Funny that there were zero
> test cases to catch it.  I will try to work up such a case.
> 
> Regards,
> Loren
>