StringBuffer.substring sharing
After I checked in Ralph Loader's fix for StringBuffer.substring the
other day, Ralph pointed out that my modification had changed the
meaning of the patch slightly:
On Monday, Sep 22, 2003, at 20:45 Pacific/Auckland, Ralph Loader wrote:
My interpretation of the original code was that it was meant to prevent
the possibility that a small substring of a large StringBuffer would
prevent the large array being gc'd.
The patch you checked in breaks this. Consider:
String Foo()
{
StringBuffer b = new StringBuffer();
... put a megabyte of stuff into b ...
String ignored = b.toString(); // sets b.shared
return b.substring (0, 1);
}
The 1 character String returned from Foo now has it's contents stored
in
a megabyte char[], and that array has no other references.
Passing ((len 2) = value.length) rather than StringBuffer.shared to
the String constructor prevented this.
Its hard to say what is optimal here, as you can also argue that if the
string is already shared then its reasonable to share even if the
substring is small. However, having to copy a small string
unnecessarily doesn't seem as bad as potentially wasting a lot of
memory in the scenario above. So, I'm checking in the following patch,
which reverts to the behaviour of Ralph's original patch.
2003-09-24 Bryce McKinlay [EMAIL PROTECTED]
* java/lang/StringBuffer.java (substring): Don't set `shared' on
small Strings, even if buffer is already shared.
Index: StringBuffer.java
===
RCS file: /cvs/gcc/gcc/libjava/java/lang/StringBuffer.java,v
retrieving revision 1.16
diff -u -r1.16 StringBuffer.java
--- StringBuffer.java 22 Sep 2003 08:17:48 - 1.16
+++ StringBuffer.java 24 Sep 2003 06:02:00 -
@@ -564,11 +564,12 @@
throw new StringIndexOutOfBoundsException();
if (len == 0)
return ;
-// Share unless substring is smaller than 1/4 of the buffer.
-if ((len 2) = value.length)
- shared = true;
+// Don't copy unless substring is smaller than 1/4 of the buffer.
+boolean share_buffer = ((len 2) = value.length);
+if (share_buffer)
+ this.shared = true;
// Package constructor avoids an array copy.
-return new String(value, beginIndex, len, shared);
+return new String(value, beginIndex, len, share_buffer);
}
/**
Regards
Bryce.
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Classpath - javax.sound implementation - which library?
Hi, I've been looking at tritonus, and its mixer capabilities are ALSA-specific (hence Linux-specific). Is there some other library that would be viable for Classpath, such as SDL, that would be more portable? I'm not sure of licensing issues around SDL or even tritonus, but tritonus is LGPL, and the authors are apparently flexible on licensing. Tritonus is at http://www.tritonus.org/ Regards, Ricky. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
HashMap putAll/putAllInternal bug
The HashMap putAll and putAllInternal (called from constructor) methods use size() to get the size of the map to be added, and then iterate over the iterator that many times to add elements. Instead, they should call hasNext() on the iterator. I can make any number of arguments for why this should be the case, but if we're arguing on the merits, there are arguments against this change too, so I won't bother :) Instead, I'll appeal to Sun does it this way and we should be compatible. I've got actual code that breaks on Classpath due to this difference (I spent *ages* tracking it down, too). I know that this means my Map classes aren't quite honoring the Map contract, by not returning the correct value for size(), but I have good reasons for that - and Sun's implementation doesn't care, so Classpath's shouldn't either. I suspect this problem may be more pervasive - it only bit me on HashMap, but it may come up on *Map, *Set, and *List, Hashtable and Vector as well. If Classpath makes this change, I believe I'll be able to post the code of my project onto Savannah (they wouldn't accept it until it ran on a free Java implementation). Stuart. -- Stuart Ballard, Senior Web Developer FASTNET - Web Solutions (215) 283-2300, ext. 126 www.fast.net ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath - javax.sound implementation - which library?
Hi Ricky, Ricky Clarkson wrote: Hi, I've been looking at tritonus, and its mixer capabilities are ALSA-specific (hence Linux-specific). Is there some other library that would be viable for Classpath, such as SDL, that would be more portable? Tritonus also supports ESD as it backed, I've merged in both into kaffe. The tritonus developers were quite open minded about others contributing backends for other libraries when I spoke to them last time around (when the code was merged into kaffe). And it works quite well, by the way ;) I'm not sure of licensing issues around SDL or even tritonus, but tritonus is LGPL, and the authors are apparently flexible on licensing. I doubt LGPL will work with classpath as a) LGPL can be transformed to GPL, which is not equal to GPL + linking exception that Classpath has b) Tritonus developers would have to submit their copyrights for the code to the FSF anyway for the code to enter Classpath. So the best course of action would seem to be to have Mark contact them about contributing their code to Classpath. I would fully support such a move. cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
VMClassLoader
I think the reference VMClassLoader is subtly incorrect. Is anybody using this code as-is? In particular, I think VMClassLoader.getSystemClassLoader must try to use the default system class loader to load the one specified in the java.system.class.loader property. Also, it should pass the default system loader as the argument to this loader's constructor. I base this on the Sun JDK docs for ClassLoader.getSystemClassLoader(). Any opinions? I would check in a cleanup here, but I don't know how I would test it... Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: auto-formatting: no more jalopy
Tom Tromey [EMAIL PROTECTED] writes: Brian == Brian Jones [EMAIL PROTECTED] writes: Brian Bug: Printer Java: GNU brace style does not indent beyond braces Brian http://sourceforge.net/tracker/index.php?func=detailaid=716393group_id=45216atid=442212 I tried adding gnu-style indent to jalopy today. Unfortunately the result dies while trying to parse our javadoc. So, I'm giving up. I can send my hack if somebody wants it. The real GNU.xml style file is attached to the above PR. Go ahead and send my way, I'm starting to play with it too. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: dotnet platform support / gnu config.sub (long)
Dalibor, what message are you replying to? Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: dotnet platform support / gnu config.sub (long)
Andrew Haley wrote: Dalibor, what message are you replying to? One from the libtool mailing list, actually. I cross posted it to classpath and kaffe for reference, as it tried to define some java vm configure script recognition functionality. The original message is here: http://mail.gnu.org/archive/html/libtool/2003-09/msg00109.html cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: dotnet platform support / gnu config.sub (long)
Guido Draheim wrote: For the java machine, the term `jvm` is used universally. I do not remember there were any dependency on pointer lengths, it runs in managed mode always. JVM, JDK, Java, etc. are all trade marks with associated conditions of use. http://www.sun.com/suntrademarks/#J . Are you sure you want/need to use them? Since ilvm64 may be run on a 32bit system, we do set the two cpu/vm types of ilvm and ilvm32 for the dotnet binaries and libraries. Alongside we use jvm for jar binaries A virtual machine capable of executing programs written in java programing language usually executes only classes stored in class files. Some virtual machines also have the capability of executing programs stored in zip archives, or jar archives. So 'jvm' is a misleading term here. Therefore, for jvm we do usually paste 'java' as interpreter and 'jdk' as basic service series. Likewise the dotnet binaries are given as 'ilrun' for the interpreter and 'mono' for the service series (or something alike). Not all java interpreters are called 'java'. there is gij, sablevm, kaffe, wonka, and a ton of others, that don't necessarily fit into this naming scheme. While some of them provide java-named wrapper scripts, I'm not sure if all of them do. jvm-sun-java-jdk jvm-sun-java-j2me jvm-sun-java-j2se jvm-sun-java-j2ee uh, what's that sun doing there? ;) what's the difference between jvm-sun-java-jdk and jvm-sun-java-j2se supposed to be? and so on ... I believe it would be better if you got in touch with kaffe, gcj, sablevm, classpath, debian-java etc. developers before you try to push something as big as this through as some kind of a GNU convention. I don't know much about .net yet, and being a kaffe developer, I'm more focussed on the java side of things. AFAIK, similar definitions have been tried before on debian-java, and failed. On the other hand, if the virtual machine implementors of varios GNU projects have already been consulted, and this is the concensual proposal, I'd like to have the reference to the mailing list threads ;) If that's not happended, then let's discuss this first, as it's a good idea, but it needs to be discussed in a broader, more realted audience, than the libtool mailing list, which, sincerely, doesn't seem like a good pick to debate the finer details of naming vm systems. ;) cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: dotnet platform support / gnu config.sub (long)
Dalibor Topic wrote: Guido Draheim wrote: For the java machine, the term `jvm` is used universally. I do not remember there were any dependency on pointer lengths, it runs in managed mode always. JVM, JDK, Java, etc. are all trade marks with associated conditions of use. http://www.sun.com/suntrademarks/#J . Are you sure you want/need to use them? Yes. Actually, if the target is a java'ish machine then they will have to take care of any of that legalese themselves. The config.sub thing is not a java'ish thing itself here. - Furthermore, the use context is obviously talking about compatiblity with a certain vm type and not identity, as expressed in a lot of corners and we know that config.sub simply trying to get a canonic variant of certain arguments given. jvm, java and similar names _are_ the canonic variant of anything quite like it but not the product (trademark!) itself. That however points out a mistake in my attemps - it should not call for sun as a default vendor vor any of the java lookalike targets. Still we need to have some canonic name that software type, simply that it can be used to autoconf'igure addon software. Since ilvm64 may be run on a 32bit system, we do set the two cpu/vm types of ilvm and ilvm32 for the dotnet binaries and libraries. Alongside we use jvm for jar binaries A virtual machine capable of executing programs written in java programing language usually executes only classes stored in class files. Some virtual machines also have the capability of executing programs stored in zip archives, or jar archives. So 'jvm' is a misleading term here. The jvm is in the place of the processor, the packaging format would be indicated in the last part around the OS-KERNEL type. That's established use for other OS/EXE variants as well. My previous mail was trying to indicate that strongly and differentiate between an executable segment (jvm) and packaging exe format (jar) that can be started by an interpreter (java). Sorry if it was not _that_ clear. Therefore, for jvm we do usually paste 'java' as interpreter and 'jdk' as basic service series. Likewise the dotnet binaries are given as 'ilrun' for the interpreter and 'mono' for the service series (or something alike). Not all java interpreters are called 'java'. there is gij, sablevm, kaffe, wonka, and a ton of others, that don't necessarily fit into this naming scheme. While some of them provide java-named wrapper scripts, I'm not sure if all of them do. Correct. There may be no `java` (lowercased) wrapper script. However, I expect that an autoconf script will detect a shellvar $JAVA to point to it with the help of an ac_check_tool test. That test may include other java wrapper names as tools to test for - probably testing for a `java` wrapper first. That's why the canonic name is `java`, note that the config.sub canonic name is always lowercase, unlike the common form of a shellvar to point to a wrapper script. jvm-sun-java-jdk jvm-sun-java-j2me jvm-sun-java-j2se jvm-sun-java-j2ee uh, what's that sun doing there? ;) what's the difference between jvm-sun-java-jdk and jvm-sun-java-j2se supposed to be? and so on ... I believe it would be better if you got in touch with kaffe, gcj, sablevm, classpath, debian-java etc. developers before you try to push something as big as this through as some kind of a GNU convention. I don't know much about .net yet, and being a kaffe developer, I'm more focussed on the java side of things. AFAIK, similar definitions have been tried before on debian-java, and failed. On the other hand, if the virtual machine implementors of varios GNU projects have already been consulted, and this is the concensual proposal, I'd like to have the reference to the mailing list threads ;) If that's not happended, then let's discuss this first, as it's a good idea, but it needs to be discussed in a broader, more realted audience, than the libtool mailing list, which, sincerely, doesn't seem like a good pick to debate the finer details of naming vm systems. ;) No, I've been trying to get a decent cc list for dotnet targets as it is a platform target that can have C/C++ source code as input - IOW a target that can be different than the primary target of that software. That's not the same for java. - I was including java (and python) in the description in an attempt to establish guidelines for (any) other VM-type target platforms. Note that dotgnu has a compiler that can output an ilrun binary with a jvm executable segment. They call the target -mjvm. The gcc has references to java as well, lot's of them really. Surely one can have F/U/D about the usage of java/jvm trademark stuff but I expect them invalid in this context where we speak about a canonic name for a family of platforms, not any product specifically. Creating a java compatible product however would need to care about the trademark stuff, but here we do not have this case. I'll update that patch and to erase the reference to 'sun'
Re: dotnet platform support / gnu config.sub (long)
Guido Draheim wrote: Dalibor Topic wrote: Guido Draheim wrote: For the java machine, the term `jvm` is used universally. I do not remember there were any dependency on pointer lengths, it runs in managed mode always. JVM, JDK, Java, etc. are all trade marks with associated conditions of use. http://www.sun.com/suntrademarks/#J . Are you sure you want/need to use them? Yes. Actually, if the target is a java'ish machine then they will have to take care of any of that legalese themselves. The config.sub thing is not a java'ish thing itself here. - Furthermore, the use context is obviously talking about compatiblity with a certain vm type and not identity, as expressed in a lot of corners and we know that config.sub simply trying to get a canonic variant of certain arguments given. jvm, java and similar names _are_ the canonic variant of anything quite like it but not the product (trademark!) itself. AFAIK sun has quite strict rules about claiming compatibility with any of their Java products. Basically, you can't do it, unless you shell out big bucks for a license to their code. But I may misunderstand what you want to say. No, I've been trying to get a decent cc list for dotnet targets as it is a platform target that can have C/C++ source code as input - IOW a target that can be different than the primary target of that software. That's not the same for java. - I was including java (and python) in the description in an attempt to establish guidelines for (any) other VM-type target platforms. It's just that all those java'ish runtimes are all somehow different in my experience, so trying to put some kind of 'it's all mutually compatible java' cover on it doesn't really fit. A 'abstract machine'-'runtime' mapping only works as long as there are only a few runtimes available. In java's case, those days are long gone, and the number of options is quite huge, so fitting all of them under the same cap is quite complicated, if not impossible. I assume that in few years, c# will have the similar problem ;) cheers, dalibor topic ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [kaffe] Re: dotnet platform support / gnu config.sub (long)
On Wed, 24 Sep 2003 23:38:38 +0200 Dalibor Topic [EMAIL PROTECTED] wrote: JVM, JDK, Java, etc. are all trade marks with associated conditions of use. http://www.sun.com/suntrademarks/#J . Are you sure you want/need to use them? Yes. Actually, if the target is a java'ish machine then they will have to take care of any of that legalese themselves. The config.sub thing is not a java'ish thing itself here. - Furthermore, the use context is obviously talking about compatiblity with a certain vm type and not identity, as expressed in a lot of corners and we know that config.sub simply trying to get a canonic variant of certain arguments given. jvm, java and similar names _are_ the canonic variant of anything quite like it but not the product (trademark!) itself. AFAIK sun has quite strict rules about claiming compatibility with any of their Java products. Basically, you can't do it, unless you shell out big bucks for a license to their code. But I may misunderstand what you want to say. Sun has a lot of lawyers, and they've been pretty aggressive than most about staking their claims on the linguistic turf (so they can sell it off). Because they claim Java Compatible(tm) as a trademark, it makes it hard to use a normal noun+verb sentence to say that we're compatible with Java -- we are, by most dictionary definitions, but we're not Java Compatible(tm), under Trademark law. Maybe we can say that we're interoperable? :-) Anyways, the config.sub name is just going to be used to define a target - so it makes sense to call the target Java, since it's only going to be used by tools generating Java byte code, which will run on Sun's JVM. Of course it will still run on other virtual machines that can't use the Java trademark, but that shouldn't be of any concern to the tools generating the code, IMHO. Cheers, - Jim ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
File encodings and initialization sequence
Just wanted to share experiences with the initialization sequence and trying to resolve the character encoding problem. To fill in various system properties in Runtime we use native code to get C char arrays with output from things like uname, cwd etc. These are returned as Java byte arrays and have to be converted to Java Strings. The correct way to do this seemed to be to use the String(byte[]) constructor and ensure the corrected decoder was used. But this wasn't possible because the EncodingManager.clinit uses System.getProperty and that would be called before System.clinit had actually initialized its properties object. Hence we'd get a NullPointerException. To fix this Runtime now forces System to use it's properties object until System.clinit reaches the point were it clones runtime's properties object. Before I set any system properties I now extract the default character set name, acquired via native code, and use that to set the file.encoding property. Then I set all the encoding alias properties in case the default charset name is actually an alias. After that I can construct Strings from byte[] using the right decoding. I'm curious how others have dealt with this issue. I'm no expert on character-set/locale/internationalization issues. Related to this problem, I also found out that any exception that occurs prior to the point where System clones the runtime properties will cause recursive exceptions because Throwable.clinit also uses System.getProperty, which will throw NPE. I'd be tempted to have any static initialization code that needs a system property to read it direct from Runtime.properties - though of course that only works for classes in java.lang. Cheers, David Holmes ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
