Jan Röhrich wrote:
Hello list,
imagine the following case: A method supports the lookup of objects
using a name - object mapping. The objects are stored in a map but can
easily be newly created instead of performing a real lookup. Shall we
perform this real lookup even if the newly created
Kendall Bell wrote:
I would like to implement Comparable in java.util.Calendar.java. I
fell that this is necessary for compatibility with other JRE's.
Kendall Bell
Which other JRE's are you talking about?
For the record, java.util.Calendar does NOT implement Comparable in the
JDK 1.4.2.
Tom Tromey wrote:
Florian == Florian Weimer [EMAIL PROTECTED] writes:
Florian On a related note, is it possible to access the command line
Florian as an array of byte arrays?
Nope.
To elaborate. As far as I know, none of Sun's Java implementations since
(at least) JDK 1.1 have offered
Chris Burdess wrote:
It does have the same support, and more. It just does things slightly
differently. There isn't anything in the specification of
HttpURLConnection that states that it supports resources of arbitrary
length.
Nor is there anything in the specification that says that
Jeroen Frijters wrote:
Christian Schlichtherle wrote:
For my personal education: What's wrong about adding constructors?
It is a violation of the Sun license included with the API specification
-- you could argue about whether the license is valid or not, but that's
not the point, and
Mark Wielaard [EMAIL PROTECTED] writes:
On Fri, 2005-07-15 at 10:42 +1000, Stephen Crawley wrote:
Chris Burdess [EMAIL PROTECTED]:
The underlying library used by the GNU providers is called inetlib. It =
=20
provides a much lower-level API to IMAP and other network protocols. If=
=20
Chris Burdess [EMAIL PROTECTED]:
The underlying library used by the GNU providers is called inetlib. It
provides a much lower-level API to IMAP and other network protocols. If
you want performance, and you can live without a MIME framework, it may
be of interest to you.
This worries me
You wrote:
The problem is that we have public javax.mail API's that return class
instances from the internal package com.sun.mail.
Really?
My reading was that the javax.mail.Folder is clean. The problem is
that some key public methods com.sun.mail.imap.IMAPFolder do not have
corresponding
I stand corrected.
-- Steve
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Folks,
I've submitted a two-line patch to the Jikes project on SourceForge
that works around the problem which shown up when you use Jikes 1.22 to
compile against a Classpath class tree.
The symptom is that the compiler dies with an assertion error at
line 1110 of symbol.h in the IsInner
Mark,
On what platform have you seen this?
I'm running Fedora Core 4, and Jikes compiled from the 1.22 release
source tarball from SourceForge. Jikes was compiled on FC4 with the
GCC 4.0.x toolchain included therein.
Any idea which file/class triggers it? Or a workaround for our sources?
Mark,
But I worked around it by removing the +U from the kissme Makefile.
I'll try that.
Thanks,
-- Steve
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Folks,
Archie Cobbs wrote:
Andrew Haley wrote:
I'm only trying to make it at least theoretically possible for a VM
to use Classpath unmodified and still function properly.
To what end?
Here are a couple of reasons..
- It allows multiple VMs to share the same stock Classpath
Etienne,
Please take this discussion off the classpath mailing lists.
For the record, I would be quite happy for Kissme to be removed from the
distinguished list of JVMs that are mentioned in Classpath release
announcements. I really don't think this is an issue that is worth
getting worked up
Dalibor Topic [EMAIL PROTECTED]:
David P Grove wrote:
The license forces that plus proper academic credit (ie a citation) for
the benchmark suite, which personally I think is quite fair given how much
work was put into putting it together (much more than the typical academic
paper).
Folks,
We need to understand the reasoning behind the OMG's publication of the
files as copyrighted and unmodifiable. As I understand it (*), the
current mode of publication is, in part, a reaction to things that have
happened previously.
Historically, certain ORB vendors were in the habit
Dalibor,
You should be arguing with the OMG, not with me. On second thoughts,
that would be a mistake. The typical OMG representative is likely to
dismiss the kind of arguments you just made as idealistic claptrap.
If you want corporate types to listen to you, you have to talk their
language.
Do all classpath VMs have native code to load jar files? Does it make
sense to distribute a jar instead?
Kissme doesn't. It delegates loading from JAR files to Java code, which
could be problematic during the boostrap sequence.
I've no problems with Classpath using ./configure parameters to
[EMAIL PROTECTED] said:
In fact, the documentation for setCurrency() suggests that null is a
perfectly valid value for the currency attribute.
I'm not sure I'm talking about the right code ... but the JDK 1.5.0
javadoc for DecimalFormatSymbols.setCurrency(Currency) says that
a
[EMAIL PROTECTED] said:
If your VM does not support it: Can you tell me about the reasons and
the priority of implementing it?
Kissme's implementation of GetDirectBufferAddress() returns NULL.
The project doe not have enough developer cycles to address this at the
moment. Platform stability
[EMAIL PROTECTED] said:
The point is that every test has a known state, one of:
(a) don't even bother trying it (doesn't compile or we know it fails)
(b) it is a known failure (i.e., a Classpath bug)
(c) it should pass (i.e., if it fails, it must be a JVM bug)
(d) it should pass but there
Mark Wielaard [EMAIL PROTECTED] wrote:
I do note that kissme still uses a DefaultClassLoader based on that old
SystemClassLoader. Maybe Stephen can tell why he isn't using the new
ClassLoader.defaultGetSystemClassLoader() yet.
1) laziness, and
2) not reading classpath email properly;
Others that look promising simply don't work:
Kissme: http://kissme.sourceforge.net/
cvs instructions don't work, downloads are ancient.
Yes ... I need to create new tarballs.
But I don't understand your comment about the CVS instructions
not working. They are (AFAIK) the generic
Folks,
There has been a fair bit of discussion about Date-related bugs
recently. I'd like to draw your attention to the long-standing #9495
bug against java.util.GregorianCalendar which fails when you try
to convert a large +ve or -ve millisecond value to a Date.
There is a new(-ish) Mauve
[EMAIL PROTECTED] said:
I would like to make this new class public to do away with the
overhead (and initialization dependencies) of the security check, but
that would require some VM magic to make the class inaccessible from
untrusted code. Michael Koch (strongly) opposes this. How would you
Folks,
As of few days ago, the CVS version of Kissme supports JNI 1.2 apart from
the Invocation API. Some of the new methods are untested, but I'll be
addressing this in coming weeks.
-- Steve
___
Classpath mailing list
[EMAIL PROTECTED]
Hi,
I wrote:
I'm going to submit a Sun bug report against the InternalError
javadoc. It will suggest that either they change the javadoc wording
to match current practice, or they define a new xxxError exception to
be thrown for library internal errors.
I'm also going to submit a bug report
[EMAIL PROTECTED] said:
Dalibor Topic wrote:
Can't we just use assertions for things that should never happen?
In this case I think its better not to, because assertions may be
disabled in production builds.
Ah ... but we could avoid that by explicitly throwing AssertionError.
But my
[EMAIL PROTECTED] said:
As Andrew said; when the last non-daemon thread dies; the Sun JVM has
a really nice feature to throw a stacktrace of all threads using one
command (the EOF char; ctrl-\) if not present; please place that on a
feature request list somwhere :)
Thread stack dumping is
[EMAIL PROTECTED] said:
... But it is not clear, which VMs do support GUI stuff, or is
this not an issue any longer? At least Kissme, which works good with
Classpath states that it only runs console apps.
Kissme currently has no problems with the tiny GUI tests in the
Classpath testcase
Folks,
Over the weekend I fixed up the Mauve CollationElementIterator testcase.
This now fails in one subtest because it appears that RuleBasedCollator
or CollationElementIterator 'eats' a leading space in the input string to be
collated. (This behavior does not occur with the JDK 1.4.2
Hi Guilhelm,
Thanks for the info. Your numbers tend to confirm my suspicion that the
factor of 200 is a Kissme-specific problem.
In the meantime, I think I have come across a problem in Kissme's
implementation of the CONSTANT_STRING instruction that does some way
towards explaining this.
--
Folks,
I've just checked in a new version of the Mauve testcase for Unicode
character handling. This fixes previous problems that resulted in
huge numbers of test failures with the current version of Classpath.
[It turns out that they were partly because the testcase used an old
Unicode table,
Michael Koch [EMAIL PROTECTED] said:
I really wonder if this primitive script really works on some
non-linux platforms. I will commit an improved version later.
It doesn't necessarily work on linux platforms either. On my machine
at home, I have various versions of automake installed, and I
Archie Cobb wrote:
Etienne Gagnon wrote:
Build Process
=
Classpath is not meant to live on its own; it is either meant to be used
as a class library for a compiler (e.g. jikes), or as a class library for
a virtual machine (gcj, JikesRVM, SableVM, Kaffe, ...).
It
First impression was a bit strange; 70195 of 3581269 tests failed on Suns
JDK 1.4.2_02... seems like lots of tests copy-pasted but not finished.
IIRC, the bulk of the tests, (including the failing tests) are in a
single file that tries to exercise Unicode support. I looked it once,
and
Would it be correct to amend the API documentation, saying that correct
results cannot be expected for input coefficients that have no exact
representation in IEEE 754?
That would be reasonable IMO. I'm pretty sure that some of the QuadCurve2D
testcases fail with Sun's J2SE 1.4.2 on my Intel
Hi Mark,
[EMAIL PROTECTED] said:
As far as I have seen most VMs have their own System/Application
classloader. The SableVM developers were also rewriting it (to make
sure ProtectionDomains were set correctly). So I guess everybody works
around it instead of collaborating on the version in
[EMAIL PROTECTED] said:
A mauve test attached. Since I have got a write access to the mauve
CVS registry, I will add it to the registry. The test results shows
that Sun's implementation also seems to have something wrong.
If Sun's implementation (you don't say which JDK version!) is
Mark Wielaard [EMAIL PROTECTED] wrote:
On Fri, 2003-11-28 at 02:03, Stephen Crawley wrote:
The over-arching principle for Mauve testcases is that the behavior of
Sun's Java implementations is the gold standard for conformance
testing.
I don't agree. We should not create Mauve tests
Hi Patrik,
I just tried with a fresh classpath from CVS, but it doesn't work.
autoheader fails to create include/config.h.in and the rest follows. You
can see the results below.
OK, my memory was incorrect. This evening, I'll try and work out how it
used to work for me. (Fortunately, I
Mark Wielaard [EMAIL PROTECTED] wrote:
On Thu, 2003-10-23 at 19:52, Dalibor Topic wrote:
apparently the configure.in in CVs is broken. I tried the
aclocal; autoheader; automake; autoconf
routine as recommended in the HACKING document, but it doesn't work:=20
aclocal complains about
=20
Folks,
If all we have to do to keep GNU / FSF happy for now is to remove
the link to the OMG from the website, lets just do it. I hardly think
this is a major issue.
In the long term though, there is a bigger problem looming. At some
point, Classpath needs to support the org.omg.* classes.
David Holmes [EMAIL PROTECTED] wrote:
If you can't provide a valid implementation for any concrete method
that you are supposed to implement, then it seems quite unreasonable
of you to expect any inherited methods to work for you. I think it
quite reasonable for a method like putAll to expect
Jeroen Frijters wrote:
I'm certainly not throwing in the towel ;-) I think it should be an
error, but I can live with NYIException being an Exception, what I
cannot accept is (ab)using UnsupportedOperationException.
I still don't see any real problem with UnsupportedOperationException,
Jeroen Frijters wrote:
I'm certainly not throwing in the towel ;-) I think it should be an
error, but I can live with NYIException being an Exception, what I
cannot accept is (ab)using UnsupportedOperationException.
I still don't see any real problem with
Jeroen Frijters wrote:
Andrew Haley wrote:
My only argument was against subclassing Error, because the Java
specification strongly implies that the only reasonable thing to do
when receiving an Error is issue a disgnostic and die.
I agree. We should not be subclassing Error, or one of
So, my proposal is:
(1) Throw NotYetImplementedError extends Error (or LinkageError?)
(2) Document clearly that users of Classpath SHOULD NOT catch this
exception, but use System.getProperty(gnu.classpath.version) instead.
(3) Document, in the VM interface, that such property should be set,
I personally think that a Java application should not try to discover
the JVM/library version through an akward usage of exceptions/errors.
I personally disagree that it is awkward.
Many applications (including SableCC, I think) do things like:
try ...
catch(Exception e)
{...}
In
Stephen Crawley wrote:
If no user is allowed to catch this new error/exception, why are we going
to the bother of creating it in the first place??
So that, when a user runs his application on top of a Free jvm using
Classpath, he can identify clearly missing functionality (at run time
[EMAIL PROTECTED] said:
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).
That's a rather twisted interpretation of Sun's use of trademarks, IMO.
Another way of interpreting this is that Sun is
A few weeks ago, I wrote:
The Kissme in CVS and in the Kissme 0.0.31 release are currently
incompatible with the latest Classpath in CVS ...
Compatibility should be restored in a day or so ...
Last night I fixed the last major bug and checked in a large number of
changes to Kissme. I
Sascha,
So, should a java compiler accept the following?
// java.awt.HeadlessException
// extends java.lang.UnsupportedOperationException
// extends java.lang.RuntimeException
class Foo
{
void meth() throws java.awt.HeadlessException { }
}
class Bar
extends Foo
{
Unfortunately I also forgot to make a CVS tag when I released kissme
0.0.31.
... and I've checked in some bug fixes since 0.0.31 :-(
I think we can fix this though. For example, cvs rtag with the -D
option looks like it would do the trick. If that fails, we could
tag the head revisions,
BTW2: I think I'm close to getting Kissme to work with the new Thread
classes anyway.
I did CVS checkouts earlier and everything seems to work perfectly, are
your changes finished?
I'm surprised to hear that. I haven't checked in any of the relevant
Kissme changes yet!
-- Steve
Aaton Renn wrote:
This is probably a dumb question, but I re-freshed my Classpath CVS
and updated to kissme 0.31 and kissme isn't working. I get:
Couldn't preallocate OutOfMemoryError exception object
if I pass in any class argument (even for a bogus .class file)
This is not a dumb
Mark,
For the record, your 'GregorianCalendar.first' testcase runs without
any failures under Sun JDK 1.4.1.
This suggests to me that any failures you are seeing are not the
fault of your testcase!
-- Steve
___
Classpath mailing list
[EMAIL
I believe the kissme VM just uses the vm/reference version of Thread.
This is correct.
If the classpath implementation of vm/reference/java/lang/Thread.java
is redone as java/lang/Thread.java + vm/reference/java/lang/VMThread.java,
kissme should be changed to reflect this. This will entail
Hi Torsten,
I don't know if you did this deliberately, but your latest change
to java/net/PlainSocketImpl.java to implement the connect(addr,timeout)
method has clobbered an existing implementation checked in a few
hours earlier by Michael Koch on my behalf.
Your implementation ignores the
Hi Torsten,
The following patches are required to get the most recent version of
target_generic_file.h to compile. Can you please check and apply them
to the Classpath CVS?
[Hint for others: it is necessary to rerun autoheader, automake,
autoconf and ./configure after apply this patch.]
Torsten == Torsten Rupp [EMAIL PROTECTED] writes:
TorstenFixed missing JNI_JLONG_CONST* definitions (preliminary fix)
Torsten,
Another problem is that you need to add #include assert.h to a couple
of files. Without these, the shared library will contain an external
reference to an
Brian,
You wrote:
You can ignore the complaint, the macros are never hit unless
defined.
You are correct (I discovered ...)
If uncommenting that pattern_allow stuff works I'll do it,
Uncommenting the m4_pattern_allow calls works for me.
I think it would be a good idea to do this:
/usr/local/bin/jikes +F -bootclasspath '' -extdirs '' -sourcepath '' -classpath
..:../external/jaxp/source:../vm/current:.: -d . @classes
Found 1 semantic error compiling ../javax/swing/plaf/basic/BasicGraphicsUtils.java:
483. lineMetrics = font.getLineMetrics(text, frc);
Brian,
Your last change to configure.in has broken my build.
Specifically, you have commented out the following lines with dnl's
m4_pattern_allow([AM_PATH_GTK_2_0])
m4_pattern_allow([AM_PATH_GLIB_2_0])
and autoconf is now complaining at me that 'AM_PATH_GTK_2_0' and
Folks,
I resync'd mith the Classpath CVS (one minute ago), and now I get the
following compilation errors.
-- Steve
Found 1 syntax error in ../java/io/FileOutputStream.java:
---
88. ?
FYI: There are a number of Classpath patches on 'savannah' waiting
to be applied by someone with commit privilege.
1571 fix for java.math.BigDecimal.setScale()
1487 Bad Permission in ObjectInputStream.enableResolveObject
1519 Fix typo in java.io.ObjectInputStream
1532 Fix equals/hashcode
Stephen 1532 Fix equals/hashcode for DateFormat classes
This one looks fine to me. I assume this was discovered by running
some actual program? Otherwise I'd be surprised by this behavior.
Yes indeed. I wrote a test program to create and compare DateFormat
instances, and ran on
Michael wrote:
Am Sonntag, 8. Juni 2003 17:00 schrieb Stephen Crawley:
Michael,
Your recent changes included a change that gives compilation errors
in:
javax/swing/plaf/BorderUIResource.java
Jikes says that CompoundBorder does not provide the constructor
used by the inner
Michael,
Your recent changes included a change that gives compilation errors in:
javax/swing/plaf/BorderUIResource.java
Jikes says that CompoundBorder does not provide the constructor
used by the inner class CompoundBorderUIResource.
The following patch makes the compilation error go away.
Ingo,
You asked:
How can I generate '././include/config.h.in'
Run autoheader, as described in HACKING.
-- Steve
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Could some kind soul please apply the BigDecimal.setScale patch I
just submitted on behalf of Saket and Jerry?
-- Steve
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
All of the java.security tests are passing on Jikes RVM with the cvs head
of classpath mauve.
Folks,
I can confirm that there really is a problem running some of the Mauve
security testlets under the latest Kissme, Classpath and Mauve. It appears
to be a Kissme class loading problem,
[EMAIL PROTECTED] said:
kaffe 1.0.7 doesn't throw any exceptions but also doesn't write to the
file.
Kissme CVS+Classpath CVS correctly throws SecurityException then dumps
core.
gij from CVS gives the interesting:
Exception in thread main java.lang.ExceptionInInitializerError ***
Got
On Fri, 7 Mar 2003, Stephen Crawley wrote:
An unnecessary call to java.lang.Object.finalize() won't hurt anyone.
Be careful: IIRC we once had a bug in Wonka which made _every_ instance
appear to be finalizable, and the effect on performance was um, noticeable ...
Point taken. But my
Sascha Brawer wrote:
So, should a Java-to-Bytecode compiler emit a warning if a finalize()
implementation does not call super.finalize()? This might be a suggestion
for gcj, jikes, javac etc. Also, we might want to add a note to the
Classpath hacker's guide.
What about classes
Stephen Crawley wrote:
I'd say yes. A compiler cannot know what the target VM's implementation of
java.lang.Object.finalize() does, and hence whether calling it is necessary.
It can know that any *correct* implementation of Object.finalize is
a no-op, so there is no reason it call
IIRC all objects technicaly have finalizer. The question is which
objects have non-trivial finalizers. If (to allow changing class
hierarchies as above) you require all classes to contain:
public void finalize () { super.finalize(); }
The JLS spec calls that a trivial finalizer ...
Aaron M. Renn wrote:
Jeroen Frijters ([EMAIL PROTECTED]) wrote:
- FileOutputStream should not request read access, so the=20
modes should
be w and a
=20
Good observation. Have you actually tested the JDK to see what it
does in this situation? Is the file actually opened write
Mark Wielaard wrote:
I've been working on a new JVM and trying to figure out how
modify the vm/reference classpath classes into something that
this JVM particular can support.
Fun! Do you have specific needs that non of the current ones fullfill or
do you just like the challenge?
Archie,
You wrote:
It seems from a first look that these java.lang.Class methods which
are currently native:
[...]
could be implemented entirely in Java, by relying on these methods:
[...]
Would this work? It would save a lot of native code writing for JVM
implementors.
Bear in mind
After some digging in various RFCs I have written a (complete)
grammar (in BNF) for parsing URIs (I'll append the grammar at the end
of this message).
While the complete URI grammar looks a complex, a URI string typically
doesn't need to be fully parsed. You only need to fully parse the
Stephen Crawley [EMAIL PROTECTED] writes:
While the complete URI grammar looks a complex, a URI string typically
doesn't need to be fully parsed. You only need to fully parse the
components that are requested.
I think you are wrong in this, the URI parser should accept *only*
valid
I like this version much better. I have still just one problem with
the idea (not the implementation at this point). It would help me to
understand what you think of this counter proposal before proceeding.
As mentioned before privately, the extra functions a VM might want to
expose to
Third (and I hope final) take. This round I've done the following:
* added the JNI 1.4 methods in stead of placeholders
* removed the _JNINATIVEMETHOD #ifdef'ing. [This is no longer
necessary for Kissme, which now uses a different struct to
hold native methods internally.]
Stephen == Stephen Crawley [EMAIL PROTECTED] writes:
Stephen With that in mind, the attached classpath.diffs.gz files give my
Stephen revised proposal for changes to jni.h in Classpath. Basicly, the
Stephen changes allow the following:
I read this patch.
Stephen 1 They define
I tried Stuart Ballard's suggestion of putting all JNI calls EXCEPT
for the Kissme implemented ones int GC regions. It works.
With that in mind, the attached classpath.diffs.gz files give my
revised proposal for changes to jni.h in Classpath. Basicly, the
changes allow the following:
1
Stephen == Stephen Crawley [EMAIL PROTECTED] writes:
Stephen 3) Some other tweaking is required so that
Stephen classpath/include/jni.h can be #included by Kissme VM code.
Stephen (We need to disable the declaration of certain JVM
Stephen implementation-specific types as void
On Tue, Dec 03, 2002 at 11:49:56PM +1000, Stephen Crawley wrote:
[Besides, it is not clear that it matters much to anyone right now. The
current releases of Classpath, GCJ and Kissme all have JNI function
vectors that are incompatible with JNI 1.0. The fact that nobody noticed
until now
Stephen Crawley wrote:
Stephen Crawley wrote:
I understand this. Unfortunately it does not work for us at the moment
because Kissme's native methods do not obey the rules, and are hence
not GC safe.
How about adding the special code in *kissme*'s native methods
On Tue, Dec 03, 2002 at 07:05:46PM +, John Leuner wrote:
I don't see why we should add overhead to all JVMs because of a single
JVM that does not correctly implements JNI.
=20
It's not JNI that is the problem, it is the GC mechanism.
Which means Kissme has a flawed JNI design ...
Folks,
Summary: This email proposes some changes to Classpath to accomodate
Kissme. Could people with an interest in the Classpath native libraries
(specifically the JNI ones) please read this proposal, and post your
reactions.
Details:
Those of you have been following the Kissme mailing
On Mon, Dec 02, 2002 at 11:01:32PM +1000, Stephen Crawley wrote:
In theory, the fix is simple; perform all blocking syscalls from within
GC points. In practice, Kissme uses the Classpath native libraries for
Java I/O. Therefore, we must:
EITHER implement our own native I/O
Stephen Crawley wrote:
Those of you have been following the Kissme mailing list will know
that we've had a long-standing problem with Kissme garbage collection
and IO. In a nutshell, the Kissme garbage collector can only run
when all threads are within a GC point. Normal Java code
--=-PTIn8/GFVSUCYMLluSsI
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
1) Add a ./configure switch to enable some Kissme-specific JNI extensi=
ons.
=20
2) Add #ifdefs to classpath/include/jni.h to enable Kissme-specific
JNI functions at the end of
Daryl == Daryl Lee [EMAIL PROTECTED] writes:
Daryl Is there a preferred JVM to use? It seems reasonable to avoid
Daryl Sun's, but other than that, I don't have an opinion or a clue
Daryl which would be better.
Use in what way?
That is a very important question!
Which ones work
Daryl == Daryl Lee [EMAIL PROTECTED] writes:
Daryl configure.ac: required file `./install-sh' not found
Daryl configure.ac: required file `./mkinstalldirs' not found
Daryl configure.ac: required file `./missing' not found
Daryl Makefile.am: required file `./INSTALL' not found
Daryl
On Wed, 2002-11-27 at 16:29, Tom Tromey wrote:
Anthony, patch 620 (you submitted it a few weeks ago) restores
intern()ing of Locale fields. Is this important for performance?
I think so - but I don't have any proper evidence.
Intuition can be unreliable when deciding what to optimize,
I wrote:
I can confirm that increasing the heap size is causing segfaults :-(
For example, compiling kissme with -O0 and running the mauve regression
suite with --heap 50M is giving me segfaults in the garbage collector.
The GC is finding a bad OBREF in a static field.
I've fixed a Kissme
I wrote:
Mark wrote:
I still cannot process everything with Kissme since I am unable to set
the heap size with --heap (it will crash).
Ouch!! I'll take a look at that.
I can confirm that increasing the heap size is causing segfaults :-(
For example, compiling kissme with -O0 and
Kissme did throw a OutOfMemoryError when trying all the java. packages.
But taking a smaller subset seems to work fine. Do you have a japize
example classes/arguments/output file to which I can compare my results?
An OutOfMemoryError might indicate a problem in weak references, since
1 - 100 of 121 matches
Mail list logo
