Re: [cp-patches] RFC: changes to java.lang.Integer, Long...
Ian Rogers wrote: please give your comments on the attached patch. It tries to reduce the size of char[] for strings used to hold numbers. It changes Float/Double equals to use bit based comparisons rather than division. It increases the use of valueOf methods. It adds a cache of values from -128 to 127 for Long. It adds a cache of the values of zero and one to Float and Double. The string size is an estimate. For decimal numbers it will divide the value repeatedly by 8, causing the string length to be over estimated by a character for values like 999. This string size is still better than the current estimate of 33 characters. It also avoids the use of division (shifts are used) and/or lookup tables. I am really not convinced by the cache of values from -128 to 127. It's a significant overhead for the startup time, and I find it hard to imagine a justification for it. Andrew.
Re: [cp-patches] RFC: changes to java.lang.Integer, Long...
Hi,
Andrew John Hughes schrieb:
I'd second that. Are there clear performance benefits to justify
creating 256 objects ahead of time?
Not only does that introduce an overhead in initialising the Long
class, but it also results in increased
memory usage for all applications.
I'd also prefer that future patches focused on just one change. This
seems to be in essence four
patches in one.
Couldnt we have the best of both world? Instead of initializing the
array with all values explicitly let us do it lazily. Something like:
Integer valueOf(int i)
{
Integer I = cached[i];
if (I == null)
I = cached[i] = new Integer(i);
return I;
}
signature.asc
Description: OpenPGP digital signature
Re: [cp-patches] FYI: gjar @file fix
2008/6/3 Robert Schuster [EMAIL PROTECTED]: Hi Tom, I am less sure about adding java-specific file name parsing to the generic command-line parser code. That code is not supposed to be specific to java tooling (at least frysk uses it, fwiw). I will implement the @file handling ClasspathToolParser now. That way only our Classpath tools are affected. Regards Robert That seems a good option. Thanks again for doing this. Let me know before you commit, and I'll revert my gjar patch if that makes things easier. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: [cp-patches] FYI: gjar @file fix
Hi Tom, I am less sure about adding java-specific file name parsing to the generic command-line parser code. That code is not supposed to be specific to java tooling (at least frysk uses it, fwiw). I will implement the @file handling ClasspathToolParser now. That way only our Classpath tools are affected. Regards Robert signature.asc Description: OpenPGP digital signature
Re: [cp-patches] RFC: changes to java.lang.Integer, Long...
Andrew Haley wrote: Ian Rogers wrote: please give your comments on the attached patch. It tries to reduce the size of char[] for strings used to hold numbers. It changes Float/Double equals to use bit based comparisons rather than division. It increases the use of valueOf methods. It adds a cache of values from -128 to 127 for Long. It adds a cache of the values of zero and one to Float and Double. The string size is an estimate. For decimal numbers it will divide the value repeatedly by 8, causing the string length to be over estimated by a character for values like 999. This string size is still better than the current estimate of 33 characters. It also avoids the use of division (shifts are used) and/or lookup tables. I am really not convinced by the cache of values from -128 to 127. It's a significant overhead for the startup time, and I find it hard to imagine a justification for it. Andrew. Sorry, I replied to this off-list accidentally. One alternative is to move the class initialization into an inner class by placing the cache in an inner class. That way the cache is only built when valueOf a cached value is called. This approach would prompt similar changes in the other Number valueOf methods. Ian -- http://www.cs.man.ac.uk/~irogers/
[cp-patches] RFC: @file support for gjavah gjar
Hi,
the following patch adds @file support to gjavah and gjar by enhancing
ClasspathToolParser with a few methods and making both tools use those.
The other tools are not affected by this change nor does this modify the
core getopt functionality (except that I made the 'programName' field
protected - was private).
I originally wanted to use StreamTokenizer or StringTokenizer but I
think those are to complex for the task.
2008-06-03 Robert Schuster [EMAIL PROTECTED]
* tools/gnu/classpath/tools/jar/Main.java:
(run): Call different ClasspathToolParser.parse() variant.
(getParser): Changed return type to ClasspathToolParser.
* tools/gnu/classpath/tools/javah/GcjhMain.java:
(getParser): Changed return type to ClasspathToolParser.
* tools/gnu/classpath/tools/javah/Main.java:
(getParser): Changed return type to ClasspathToolParser.
* tools/gnu/classpath/tools/getopt/Parser.java: Make 'programName'
protected.
* tools/gnu/classpath/tools/common/ClasspathToolParser.java:
(parse(String[], FileArgumentCallback,boolean): New method.
(parse(String[], boolean): New method.
(parseFileList): New method.
(parseLine): New method.
(AtFileArgumentCallback): New inner class.
Regards
Robert
? tools/generated
Index: tools/gnu/classpath/tools/common/ClasspathToolParser.java
===
RCS file: /sources/classpath/classpath/tools/gnu/classpath/tools/common/ClasspathToolParser.java,v
retrieving revision 1.1
diff -u -r1.1 ClasspathToolParser.java
--- tools/gnu/classpath/tools/common/ClasspathToolParser.java 22 Sep 2006 01:01:26 - 1.1
+++ tools/gnu/classpath/tools/common/ClasspathToolParser.java 3 Jun 2008 16:34:45 -
@@ -38,9 +38,16 @@
package gnu.classpath.tools.common;
+import java.io.BufferedReader;
+import java.io.IOException;
+import java.io.FileNotFoundException;
+import java.io.FileReader;
+import java.io.Reader;
import java.text.MessageFormat;
+import java.util.ArrayList;
import gnu.classpath.Configuration;
+import gnu.classpath.tools.getopt.FileArgumentCallback;
import gnu.classpath.tools.getopt.Option;
import gnu.classpath.tools.getopt.OptionException;
import gnu.classpath.tools.getopt.Parser;
@@ -84,4 +91,137 @@
}
});
}
+
+ public void parse(String[] inArgs, FileArgumentCallback files,
+ boolean handleFileLists)
+ {
+ FileArgumentCallback cb;
+
+ if (handleFileLists)
+ cb = new AtFileArgumentCallback(files);
+ else
+ cb = files;
+
+ parse(inArgs, cb);
+ }
+
+ public String[] parse(String[] inArgs, boolean handleFileLists)
+ {
+final ArrayList fileResult = new ArrayList();
+
+ final FileArgumentCallback cb = new FileArgumentCallback()
+ {
+ public void notifyFile(String fileArgument)
+ {
+ fileResult.add(fileArgument);
+ }
+};
+
+ if (handleFileLists)
+ parse(inArgs, new AtFileArgumentCallback(cb));
+ else
+ parse(inArgs, cb);
+
+return (String[]) fileResult.toArray(new String[0]);
+ }
+
+
+ /** Simple function that takes the given [EMAIL PROTECTED] Reader}, treats it like
+ * a textfile and reads all the whitespace separated entries from it
+ * and adds them to the @{link FileArgumentCallback} instance.
+ */
+ public void parseFileList(Reader reader, FileArgumentCallback cb)
+ throws OptionException
+ {
+BufferedReader breader = new BufferedReader(reader);
+String line = null;
+
+try
+ {
+while ((line = breader.readLine()) != null)
+ parseLine(line, cb);
+
+reader.close();
+ }
+catch (IOException ioe)
+ {
+System.err.println(programName + : IO error while reading from inputstream);
+System.exit(1);
+ }
+
+ }
+
+ /** Parses whitespace separated file entries.
+ *
+ * Note: This is not coping with whitespace in files or quoting.
+ */
+ private void parseLine(String line, FileArgumentCallback cb)
+throws IOException, OptionException
+ {
+final int length = line.length();
+int start = 0;
+int end = 0;
+
+ // While not reached end of line ...
+while (start length)
+ {
+// Search for first non-whitespace character for the start of a word.
+while (Character.isWhitespace(line.codePointAt(start)))
+ {
+start++;
+
+if (start == length)
+ return;
+ }
+
+end = start + 1;
+
+// Search for first whitespace character for the end of a word.
+while (end length !Character.isWhitespace(line.codePointAt(end)))
+ end++;
+
+cb.notifyFile(line.substring(start, end));
+
+start = end + 1;
+ }
+ }
+
+ /** Implementation of [EMAIL PROTECTED] FileArgumentCallback} that handles
+ * file arguments in [EMAIL PROTECTED] #notifyFile} starting with a code@/code
+ * through [EMAIL PROTECTED] ClasspathToolParser#parseFileList}.
+ */
+ class AtFileArgumentCallback extends
Re: [cp-patches] RFC: add a copy of gnu/java/security/action/GetPropertyAction into sun/security/action
2008/6/3 Robert Schuster [EMAIL PROTECTED]: Hi, the attached does something very dumb: It makes a copy of an existing class. Still I need it because otherwise a resulting binary is either not runnable with classpath or with openjdk's class library. A better patch would possibly refactor all classpath code to use the sun/security variant and remove the gnu/java/security one. Opinions? 2008-06-03 Robert Schuster [EMAIL PROTECTED] * sun/security/action/GetPropertyAction.java: Functional copy of gnu/java/security/action/GetPropertyAction.java. Regards Robert Er... fix the binary which is clearly broken by relying on internal unspecified classes. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
