[Tim, 7/22/96:]
The original problem has been fixed, and Java should start up with any permitted
-ms and -mx value so long as the -ms value or default is less than or equal to the
-mx value or default. The smallest permitted values for these things is 1000 bytes.
However, the -mr and -my flags also need to figure into this and aren't handled
completely right yet. The constraint on these values should be
-ms + -mr + -my <= -mx
and so long as that is true, the runtime should run. This is not yet the case, at
minimum because the -mr and -my values are getting accounted to the total
initial heap size, which is divided 20%/80% between handles and objects. I'm
leaving this bug open until that stuff is handled right.
[Original report:]
If you don't give the runtime enough memory to start up, typically by forgetting
to add the 'k' or 'm' after an argument to -ms (and maybe -mx??), the runtime
crashes. There ought to be some sanity check that handles this more gracefully.
The actual site of the crash is down a rat hole, so it would probably be easier to
not let the system try to run rather than handle what goes wrong.
<java 675> java_g -ms2000 bitset_test
Full thread dump:
NULL (TID:0xee3330a0, sys_thread_t:0xc72b8) prio=5 *current thread*
java.lang.Character.<clinit>(Character.java:314)
java.lang.Integer.toString(Integer.java:65)
java.lang.String.valueOf(String.java:853)
java.lang.StringBuffer.append(StringBuffer.java:283)
java.lang.Thread.<init>(Thread.java:215)
*** panic: "../../../../src/solaris/java/green_threads/src/monitor_md.c", line 404: assertion failure
SIGABRT 6* abort (generated by abort(3) routine)
si_signo [6]: SIGABRT 6* abort (generated by abort(3) routine)
si_errno [0]: Error 0
si_code [0]: SI_USER [pid: 438, uid: 25704]
stackbase=0, stackpointer=0
Full thread dump:
NULL (TID:0xee3330a0, sys_thread_t:0xc72b8) prio=5 *current thread*
java.lang.Character.<clinit>(Character.java:314)
java.lang.Integer.toString(Integer.java:65)
java.lang.String.valueOf(String.java:853)
java.lang.StringBuffer.append(StringBuffer.java:283)
java.lang.Thread.<init>(Thread.java:215)
Monitor Cache Dump:
unknown key (key=0xd99c8): monitor owner: NULL
unknown key (key=0xd8c20): monitor owner: NULL
Registered Monitor Dump:
Thread queue lock: unowned
Class lock: unowned
String intern lock: unowned
Java stack lock: unowned
Code rewrite lock: unowned
Heap lock: monitor owner: NULL
Has finalization queue lock: monitor owner: NULL
Monitor IO lock: unowned
Child death monitor: unowned
Event monitor: unowned
I/O monitor: unowned
Alarm monitor: unowned
Sbrk lock: unowned
Monitor cache lock: unowned
Monitor registry: monitor owner: NULL
Thread Alarm Q:
Abort (core dumped)
The original problem has been fixed, and Java should start up with any permitted
-ms and -mx value so long as the -ms value or default is less than or equal to the
-mx value or default. The smallest permitted values for these things is 1000 bytes.
However, the -mr and -my flags also need to figure into this and aren't handled
completely right yet. The constraint on these values should be
-ms + -mr + -my <= -mx
and so long as that is true, the runtime should run. This is not yet the case, at
minimum because the -mr and -my values are getting accounted to the total
initial heap size, which is divided 20%/80% between handles and objects. I'm
leaving this bug open until that stuff is handled right.
[Original report:]
If you don't give the runtime enough memory to start up, typically by forgetting
to add the 'k' or 'm' after an argument to -ms (and maybe -mx??), the runtime
crashes. There ought to be some sanity check that handles this more gracefully.
The actual site of the crash is down a rat hole, so it would probably be easier to
not let the system try to run rather than handle what goes wrong.
<java 675> java_g -ms2000 bitset_test
Full thread dump:
NULL (TID:0xee3330a0, sys_thread_t:0xc72b8) prio=5 *current thread*
java.lang.Character.<clinit>(Character.java:314)
java.lang.Integer.toString(Integer.java:65)
java.lang.String.valueOf(String.java:853)
java.lang.StringBuffer.append(StringBuffer.java:283)
java.lang.Thread.<init>(Thread.java:215)
*** panic: "../../../../src/solaris/java/green_threads/src/monitor_md.c", line 404: assertion failure
SIGABRT 6* abort (generated by abort(3) routine)
si_signo [6]: SIGABRT 6* abort (generated by abort(3) routine)
si_errno [0]: Error 0
si_code [0]: SI_USER [pid: 438, uid: 25704]
stackbase=0, stackpointer=0
Full thread dump:
NULL (TID:0xee3330a0, sys_thread_t:0xc72b8) prio=5 *current thread*
java.lang.Character.<clinit>(Character.java:314)
java.lang.Integer.toString(Integer.java:65)
java.lang.String.valueOf(String.java:853)
java.lang.StringBuffer.append(StringBuffer.java:283)
java.lang.Thread.<init>(Thread.java:215)
Monitor Cache Dump:
unknown key (key=0xd99c8): monitor owner: NULL
unknown key (key=0xd8c20): monitor owner: NULL
Registered Monitor Dump:
Thread queue lock: unowned
Class lock: unowned
String intern lock: unowned
Java stack lock: unowned
Code rewrite lock: unowned
Heap lock: monitor owner: NULL
Has finalization queue lock: monitor owner: NULL
Monitor IO lock: unowned
Child death monitor: unowned
Event monitor: unowned
I/O monitor: unowned
Alarm monitor: unowned
Sbrk lock: unowned
Monitor cache lock: unowned
Monitor registry: monitor owner: NULL
Thread Alarm Q:
Abort (core dumped)