Thread: [Sablevm-developer] Re: [Fwd: I would like to help]
Brought to you by:
egagnon
Menu
▾
▴
sablevm-developer
|
From: Grzegorz B. P. <ga...@de...> - 2004-03-27 18:00:44
|
W li=B6cie z sob, 27-03-2004, godz. 11:23, Etienne Gagnon pisze:=20 > Based on what I saw at your website, I would like to begin with > helping in porting the existing source code to cygwin. In this > context, I would like to know who the contact point is, and > what the current status is. Hello Kamesh, I am very happy to answer to your email. Cc:ing sablevm-developer mailing list, as this is probably the best place to discuss SableVM development-related topics. Status of cygwin port: * We have some code that once worked [1], and the changes in SableVM sources were minimal * We completly disabled signals usage in SableVM. As far as I know Cygwin has some minimal support for signals, not sure how good, so maybe we should just auto-disable signals when cygwin is detected? * We had to compile shared library of libffi by hand as cygwin gcc provided only static library, and, I think, we also had to copy the headers, because they were not available from cygwin. Fixing this problem and forwarding patches upstream (to Cygwin) would be important part of the port because that would later allow other people to "just compile" SableVM on cygwin, which is not possible now. * We disabled GTK+/AWT in sablevm-classpath, because we did not have recent-enough GTK+. It could have changed sice then. You need at least 2.2.x version, and it has to be shared library too. * Under Cygwin a shared library can not open itself. libsablevm.so does this, so we had to code a workaround. We store addresses of funtions inside libsablevm.so and then we search them instead of asking libtool to do this work for us. This code is already written, is working and all it needs is merge with our development version called "staging". On the "tools that you use". You need Subversion to access our code repository (though You can also use last daily snapshot tar archive as your starting point, see http://devel.sablevm.org/shot ). Subersion nicely compiles under cygwin, but maybe you'd be able to find binary packages (I was not, a few months ago). They would need to be quite recent though. Windows version will not be good, because it'd use dos-style CR/LF as line ends so most probably you would not even be able to compile such a file under cygwin. [1] The URL to the repository with cygwin port is this: svn://svn.sablevm.org/developers/mlord/sandbox/sablevm-staging You can use this command to see the changes from the original sablevm: svn diff -r 1204:1272 svn://svn.sablevm.org/developers/mlord/sandbox/sablevm-staging |less > Please let me know if there are any other tasks that I can > lend a hand with. We are surely interested in Cygwin port. Other that this - we are also looking for somebody willing to prepare .rpm (or even lsb-rpm) packages of SableVM (and then doing binary releases if possible)... I guess you might have seen this page already: http://devel.sablevm.org/wiki/TODO It contains a few suggested topics. It's all up to you :-) Hope this helps, Grzegorz B. Prokopski --=20 Grzegorz B. Prokopski <ga...@de...> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/WhySableVM |
|
From: Etienne M. G. <eti...@uq...> - 2003-01-06 22:04:32
|
First of all, I wish a happy new year 2003 to everyone. This seems to be a local reference leak in Classpath... The JNI specification says that a VM automatically reserves at least 16 local references. To use additional references, the EnsureLocalCapacity() JNI function is available and shoould be called. See: http://java.sun.com/products/jdk/1.2/docs/guide/jni/jni-12.html#EnsureLocalCapacity A VM is *NOT* required to provide any more than 16 native references, by default, and can halt abruptly by calling FatalError() if it cannot create more locals. [OK, there's a note about backward compatibility, but my understanding is that this is for the JDK, not for every possible VM]. SableVM is simply strict in its implementation of the JNI spec (which simplifies local reference management a little). In fact, by aborting as it does, SableVM is helping to detect weaknesses in the Classpath native library. I personally think that this sould be filed as a bug against Classpath, instead. But, maybe I'll add a configure option to enable growing the local ref frame automatically. It shouldn't take more than 10 lines of code and would make Archie happy;-) Etienne On Mon, Jan 06, 2003 at 11:16:53AM -0800, SourceForge.net wrote: > Bugs item #663270, was opened at 2003-01-06 11:16 > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=105523&aid=663270&group_id=5523 > > Category: Execution Problem > Group: SableVM > Status: Open > Resolution: None > Priority: 5 > Submitted By: Archie Cobbs (archiecobbs) > Assigned to: Nobody/Anonymous (nobody) > Summary: [jni: fatal error (Local reference capacity exceeded)] > > Initial Comment: > I'm trying to run an application that uses Soot. If I > try to process > too many classfiles at once, I get this error plus a > core dump: > > [jni: fatal error (Local reference capacity exceeded)] > > This makes SableVM suddenly look like a "toy" Java VM when > we know it's really better than that :-) > > SableVM should handle this situation more gracefully, > even if > it means an 'escape' mechanism that's slower than normal or > whatever. > > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=105523&aid=663270&group_id=5523 > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Sablevm-bugs mailing list > Sab...@li... > https://lists.sourceforge.net/lists/listinfo/sablevm-bugs -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Archie C. <ar...@de...> - 2003-01-07 06:00:06
|
Etienne M. Gagnon wrote: > This seems to be a local reference leak in Classpath... The JNI > specification says that a VM automatically reserves at least 16 local > references. To use additional references, the EnsureLocalCapacity() > JNI function is available and shoould be called. > > See: > http://java.sun.com/products/jdk/1.2/docs/guide/jni/jni-12.html#EnsureLocalCapacity > > A VM is *NOT* required to provide any more than 16 native references, > by default, and can halt abruptly by calling FatalError() if it cannot > create more locals. [OK, there's a note about backward compatibility, > but my understanding is that this is for the JDK, not for every > possible VM]. > > SableVM is simply strict in its implementation of the JNI spec (which > simplifies local reference management a little). Ah, I didn't realize that there was a limit... the last time I read that spec was a few years ago before there was one! :-) This is something very basic though. It turns out that it only depends on the number of command line arguments, you don't even have to execute any application Java. For example: $ sablevm asdf sadf asdf sad sadf sadf adsf sdf asdf asdf asdf asfd asdf [jni: fatal error (Local reference capacity exceeded)] This is probably something to do with the way "sablevm" uses the invocation interface to start things up. As it stands, you can't give sablevm more than 12 command line arguments (including the main() class name). Cheers, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com |
Thanks for helping keep SourceForge clean.
X