Re: plans for classpath 0.08?

[Mark Wielaard]

Hi,

On Tue, 2004-03-02 at 00:09, David P Grove wrote:
> We're planning on releasing the next version of Jikes RVM in
> the next 1-2 weeks.  If classpath 0.08 was going to come out soon, we
> would probably stall  the Jikes RVM release a few days to wait for it.

We are a bit late with 0.08. FOSDEM took much time. But it was fun!
I prepare a release for Friday. Test it during the weekend. And release
on Monday. After that we should return to our three month schedule for
releases.

For 0.08 I have the following issues:
- The audit after the savannah compromise was never completely finished.
  (I do not expect to find anything, but would feel better if all code
   was gone over at most once. Will do this on Thursday and Friday.)
- make distcheck was broken because of newer tar versions.
  (Grzegorz found out what precisely went wrong so we can now fix this.)
- Paperwork for gnu.regexp was completed so I will import it this week.
  There are already some Mauve tests, more will follow. It works for the
  more simpler cases already (for example what the Eclipse 3.0M-builds
  need), but there is some work to be done to have a syntax-compatibly
  with java.util.regex. But that can wait till the next release.
- ServerSocket.accept() doesn't work when EINTR is returned by the
  system call. I think I know how to fix that. It prevents some network
  applications to work reliably at the moment.

Anything else?

If there are Classpath branches for particular VMs that have small fixes
then now is the time to get them into the main tree again!

Cheers,

Mark


signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Query on stacktrace management logic

[Archie Cobbs]

Steven Augart wrote:
> > I still need a hook to not get the stacktrace filled in for
> > OutOfMemoryError - though perhaps I can do something without requiring
> > allocation using a different approach.
> 
> In Jikes RVM, we override a few of Classpath's implementations; we 
> have our own Object.java and (relevant to your case) Throwable.java, 
> for instance.  Hope this helps.

In JC I've taken the approach of keeping the last little bit of heap
memory reserved for OOM exceptions. If an allocation fails, we set the
"out of memory" flag for that thread, then throw an OOM. Subsequent
allocations (while "out of memory" is set) are allowed to dip into the
reserved memory. Once the exception is fully constructed, we reset the
"out of memory" flag.

Finally, there is one global "stackless" exception created at VM startup
for each possible exception type that the VM itself throws. These are
used as a last resort (this idea is from SableVM), where "last resort"
means another exception of the same type is thrown while trying to
create the first exception (i.e., recursively thrown).

> The biggest ugliness here is that the version the rest of Classpath 
> sees is not the same one as will actually be loaded at run time.  One 
> day this will probably bite us when Classpath adds some new (Java 1.5 
> or 1.6?) method or field to a class we override before we do it 
> ourselves, and some other Classpath class uses the new method or field.

I've "overridden" a few of the non VMXXX classses and JC is installed
as an "overlay" on top of a stock classpath installation. This means that
the bootstrap classpath must always include "jc.zip" before "glibj.zip",
but on the positive side upgrading is easy.

FYI, when I started working with Classpath I tried to respect the
Foo-VMFoo split and not modify any Foo classes but eventually decided
that it was too costly. E.g., every loaded class already has a Class
object (I don't create them on-demand), but you double that number
if you also have a VMClass object for each class. Fortunately with
Classpath it's easy to go either way as things are pretty well
documented.

-Archie

__
Archie Cobbs  *CTO, Awarix*  http://www.awarix.com


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Free Java, the sequel

[Patrik Reali]

Although I'm pretty sure that everybody already read the articles, here's 
the sequel of the free java story from slashdot:

26 Feb: IBM Offers to Help Sun Open Up Java: 


27 Feb: Sun Agrees to Talk to IBM over Open Sourcing Java: 


Open letters seems to be quite trendy nowadays...

-Patrik


Patrik Reali
http://www.reali.ch/~patrik/


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Query on stacktrace management logic

[Chris Gray]

On Monday 01 March 2004 23:38, David Holmes wrote:
> Chris Gray wrote:
> > I found one gotcha with using a pre-allocated OutOfMemoryError :
> > if several threads throw OOME at the same time, the stack traces
> > can get mixed up.
>
> This is one of our issues too. With no stacktrace you can share an OOME
> instance with no problem and require no runtime allocation. With a
> stacktrace you need at least a per-thread OOME and pre-allocated stacktrace
> space. As it stands our OOME does have a stacktrace but its created at
> system startup when running out of memory is not an issue - but of course
> the stacktrace is meaningless for any actual circumstance where the OOME is
> thrown.
>
> We encounter OOME much more often than others might because we are dealing
> with RTSJ scoped memory areas - which introduces some added twists to
> things. :)

On the bright side, it does make it more likely that the OOM problem will be 
confined to one thread.

One OOME per thread, allocated at thread creation time, should be safe.  
Ensuring that one can always find memory "somewhere" to store a stack trace 
is left as an exercise for the reader (and the answer is likely to be 
VM-specific).

Chris
 

-- 
Chris Gray  /k/ Embedded Java Solutions
Embedded & Mobile Java, OSGi  http://www.kiffer.be/k/
[EMAIL PROTECTED]  +32 3 216 0369


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Announcement: ew release of gcjwebplugin

[Michael Koch]

Hi lists,


I have just releast a new version of gcjwebplugin, 0.1.2. This version 
includes some more build system fixes and the start of a java console.

It works with Mozilla 1.7a and GCC trunk CVS (3.4.0 branch works 
probably too but I havent prooved yet). The only missing things in 
libgcj are: Missing security audit and AWT/Swing implementation.

You can found a tarball at my site here:
http://www.konqueror.de/gcjwebplugin/gcjwebplugin-0.1.2.tar.gz


Have fun with it.

Michael



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

RE: Query on stacktrace management logic

[David Holmes]

Steven Augart wrote:
> In Jikes RVM, we override a few of Classpath's implementations; we
> have our own Object.java and (relevant to your case) Throwable.java,
> for instance.  Hope this helps.
>
> The biggest ugliness here is that the version the rest of Classpath
> sees is not the same one as will actually be loaded at run time.  One
> day this will probably bite us when Classpath adds some new (Java 1.5
> or 1.6?) method or field to a class we override before we do it
> ourselves, and some other Classpath class uses the new method or field.

Right. We try to abide by the XXX vs. VMXXX split and not customise any
class that isn't specifically listed as being VM-specific. So far we've only
had to override System to change the initialization sequence, but the
further we get the more classes we want to be able to customise outside the
normal set. :( This isn't great from a maintenance perspective as I'd like
to be able to just 'cvs up' the latest classpath and having everything just
work. That said, our support of RTSJ will mandate a number of library
changes to make more of the core classes "async exception" safe in the face
of the potential memory access errors that the RTSJ scoped-memory and
no-heap threads introduce.

We do ensure that we compile all the classpath classes against our
customised versions though, to ensure compatability. And I should point out
that at present we only use a subset of Classpath.

Cheers,
David Holmes



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Query on stacktrace management logic

[Steven Augart]

David Holmes wrote:
Chris Gray wrote:

I found one gotcha with using a pre-allocated OutOfMemoryError :
if several threads throw OOME at the same time, the stack traces
can get mixed up.


This is one of our issues too. 
Here's our approach:

if (VM.debugOOM || Options.verbose >= 5)
  VM.sysWriteln("triggerCollection(): About to try \"new 
OutOfMemoryError()\"");
MM_Interface.emergencyGrowHeap(512 * (1 << 10));  // 512K 
should be plenty to make an exn
OutOfMemoryError oome = new OutOfMemoryError();
MM_Interface.emergencyGrowHeap(- (512 * (1 << 10)));
if (VM.debugOOM || Options.verbose >= 5)
  VM.sysWriteln("triggerCollection(): Allocated the new 
OutOfMemoryError().");
throw oome;

Of course, we have the advantage of not targeting the embedded space.

--Steve Augart

--
Steven Augart
Jikes RVM, open source Research Virtual Machine:
http://oss.software.ibm.com/jikesrvm
Office: +1 914/784-6743
T.J. Watson Research Center, IBM
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Query on stacktrace management logic

[Steven Augart]

David Holmes wrote:
I still need a hook to not get the stacktrace filled in for
OutOfMemoryError - though perhaps I can do something without requiring
allocation using a different approach.
In Jikes RVM, we override a few of Classpath's implementations; we 
have our own Object.java and (relevant to your case) Throwable.java, 
for instance.  Hope this helps.

The biggest ugliness here is that the version the rest of Classpath 
sees is not the same one as will actually be loaded at run time.  One 
day this will probably bite us when Classpath adds some new (Java 1.5 
or 1.6?) method or field to a class we override before we do it 
ourselves, and some other Classpath class uses the new method or field.

--Steve Augart

--
Steven Augart
Jikes RVM, open source Research Virtual Machine:
http://oss.software.ibm.com/jikesrvm
Office: +1 914/784-6743
T.J. Watson Research Center, IBM
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath