Re: [kaffe] What is the rationale for Kaffe's VM memory limits? (The -mx and -ss switches.)
Dalibor Topic: The patch has (at least) one problem, it relies on Runtime.exit() to print the map of stack traces. Apparently it seems to be hard to get freenet to exit(). So I'm not sure how to proceed from here: if it is possible to tell a freenet node to shut down through exit(), that would be helpful, otherwise I could add a thread that prints out the map in regular intervals. I'll hack something together and reply with that stack trace map as soon as I have the time. I suspected that Sun's implementation also had the memory limit. I haven't used a proprietary JVM in ages, so I can't say whether Kaffe is much worse. Freenet is a really bloated program no matter how you run it, in any case. It's entirely reasonable that a user would _want_ his OS to page out data. The working set nearly always constitutes only a small share of a program's allocated memory. I don't see why the frequency of garbage collection relates to this--that blurb explicitly suggests that reducing its frequency through allowing more slack is a false optimization. What's more, if any JVM were crazy enough to wait until the heap limit is hit before invoking the GC (helps determine when a garbage collection (GC) will take place), even lightweight programs will consume an average of half the heap limit in memory. So I'm not at all persuaded that Sun is doing anything remotely sane with that limit, or that Kaffe needs to fall into the same trap. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] What is the rationale for Kaffe's VM memory limits? (The -mx and -ss switches.)
Mark J Roberts: I'll hack something together and reply with that stack trace map as soon as I have the time. I called System.exit() when Freenet was using over 150MB of memory. The output is attached. log.bz2 Description: Binary data
[kaffe] java.lang.ArrayIndexOutOfBoundsException thrown by Stack.push()
Stack.push() should not be throwing this exception. Looks like an obvious bug. Any ideas? java.lang.ArrayIndexOutOfBoundsException at java.lang.Throwable.fillInStackTrace(Throwable.java:native) at java.lang.Throwable.init(Throwable.java:37) at java.lang.Exception.init(Exception.java:20) at java.lang.RuntimeException.init(RuntimeException.java:17) at java.lang.IndexOutOfBoundsException.init(IndexOutOfBoundsException.java:17) at java.lang.ArrayIndexOutOfBoundsException.init(ArrayIndexOutOfBoundsException.java:17) at java.util.Vector.insertElementAt(Vector.java:249) at java.util.Vector.addElement(Vector.java:46) at java.util.Stack.push(Stack.java:40) at freenet.thread.FastThreadFactory$FThread.run(FastThreadFactory.java:105) ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] What is the rationale for Kaffe's VM memory limits? (The -mx and -ss switches.)
I am sick and tired of manually overriding the heap size limit in order to run Freenet without hitting the arbitrary default 64MB limit. I just don't understand why these options are even there, or why they are not unlimited by default. It is _breaking_ applications. The operating system should be the place where resource limits are configured anyway. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] File.createTempFile() creates files in /tmp with mode 0666!
Jim Pick: From the looks of this, it does look somewhat undefined. I think we're doing what Sun does, but that makes me somewhat nervous. I can see how it could be considered correct if somebody uses a temp file location other than /tmp. However, since we default to /tmp (as does Sun), using the default behaviour looks like a way to create security holes to me. If somebody is writing portable code, using File.createTempFile() with the default directory setting looks like bad news to me (unless I'm missing something). So, I personally vote for changing the mode to 0644 or 0600. Does anybody else know anything about this issue? I'm at a loss for why someone would use this API with the intention of creating a file that other users would access, but from your reply, it seems to be designed and even used with that in mind. My feeling is that the whole notion of a default temp dir is stupid and that the two-argument form of this call is insecure by design. So I think we're more or less in agreement. This may be a reasonable solution: * The three-argument form is unchanged. Callers are responsible for whatever security the file will have. * If java.io.tmpdir is explicitly user-configured, behavior is unchanged. The user who configured it is responsible for the security of files in the temp dir. * If java.io.tmpdir is _not_ configured, assume the user wants a secure temp file, and do it in the best platform-specific way. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] File.createTempFile() creates files in /tmp with mode 0666!
Jim Pick: I think what we have here is that the call is secure, providing that the user has the correct umask set up for however the system administrator has set up the groups on their system. I don't see how you arrived at that conclusion. A user who is content to normally create world-readable files by default is nevertheless not very likely to want his temp files created with the same liberal permissions; he might elevate his security at times by working on sensitive data within a mode 0700 directory, or he might merely have a single secret text file with mode 0600. If that data is exposed through a world-readable temporary file, something is _wrong_, umasks notwithstanding. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Two library fixes.
(1) java 1.4 URLDecoder.decode() throws IllegalArgumentException.
(2) java 1.4 Calendar.getTimeInMillis() is public.
Index: libraries/javalib/java/net/URLDecoder.java
===
RCS file: /cvs/kaffe/kaffe/libraries/javalib/java/net/URLDecoder.java,v
retrieving revision 1.3
diff -u -r1.3 URLDecoder.java
--- libraries/javalib/java/net/URLDecoder.java 9 Dec 1999 19:50:31 - 1.3
+++ libraries/javalib/java/net/URLDecoder.java 12 Feb 2003 19:01:06 -
@@ -20,7 +20,7 @@
public URLDecoder() {
}
- public static String decode(String s) throws Exception {
+ public static String decode(String s) {
StringBuffer buf = new StringBuffer();
for (int pos = 0; pos s.length(); pos++) {
@@ -32,7 +32,7 @@
buf.append((char)Integer.parseInt(
s.substring(pos + 1, pos + 3), 16));
} else {
- throw new Exception(invalid input);
+ throw new IllegalArgumentException(invalid
+input);
}
pos += 2;
} else {
Index: libraries/javalib/java/util/Calendar.java
===
RCS file: /cvs/kaffe/kaffe/libraries/javalib/java/util/Calendar.java,v
retrieving revision 1.12
diff -u -r1.12 Calendar.java
--- libraries/javalib/java/util/Calendar.java 4 Sep 2002 11:10:46 - 1.12
+++ libraries/javalib/java/util/Calendar.java 12 Feb 2003 19:01:07 -
@@ -259,7 +259,7 @@
return (new Date(getTimeInMillis()));
}
-protected long getTimeInMillis()
+public long getTimeInMillis()
{
if (!isTimeSet) {
computeTime();
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] [PATCH] GregorianCalendar.add()
--- libraries/javalib/java/util/GregorianCalendar.java +++ libraries/javalib/java/util/GregorianCalendar.java @@ -74,6 +74,7 @@ computeFields(); } fields[field] += amount; + isTimeSet = false; computeTime(); computeFields(); } ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
