Re: [RFC/PATCH] Invokedynamic API stubs
On 7 February 2011 20:01, Pekka Enberg penb...@cs.helsinki.fi wrote: On Mon, 2011-02-07 at 15:24 +0100, Dr Andrew John Hughes wrote: I guess I could keep it on my Github mirror until I have something concrete enough to be merged to trunk. I'd prefer to have it in HEAD as long as it's clearly marked as stubs (the NotImplementedException I mentioned) and there is work actively taking place. Then there's always the (slim) possibility someone else can work on it :-) That was my original thinking as well. Does the included patch look better to you? Mark, what do you think about this? Pekka In case nobody else has noticed : The package for JSR 292 is no longer java.dyn. It is java.lang.invoke http://blogs.sun.com/jrose/entry/jsr_292_formal_public_review Rob. From 81362427a842e815bfe354036cd4201ee781880a Mon Sep 17 00:00:00 2001 From: Pekka Enberg penb...@kernel.org Date: Thu, 3 Feb 2011 16:29:15 +0200 Subject: [PATCH] Invokedynamic API stubs This patch implements the work-in-progress invokedynamic API stubs described here: http://download.oracle.com/javase/7/docs/api/java/dyn/package-summary.html The classes don't do anything useful yet and don't even contain all the specified methods. Signed-off-by: Pekka Enberg penb...@kernel.org --- java/dyn/BootstrapMethod.java | 52 java/dyn/CallSite.java | 60 java/dyn/ClassValue.java | 45 + java/dyn/ConstantCallSite.java | 46 + java/dyn/InvokeDynamic.java | 49 +++ java/dyn/InvokeDynamicBootstrapError.java | 47 ++ java/dyn/Linkage.java | 45 + java/dyn/LinkagePermission.java | 56 ++ java/dyn/MethodHandle.java | 62 + java/dyn/MethodHandleProvider.java | 52 java/dyn/MethodHandles.java | 52 java/dyn/MethodType.java | 50 +++ java/dyn/NoAccessException.java | 47 ++ java/dyn/WrongMethodTypeException.java | 47 ++
Re: Review request for 6977034 Thread.getState() very slow
Hi Mandy,
On 6 December 2010 19:26, Mandy Chung mandy.ch...@oracle.com wrote:
Remi, Eamonn, Brian, David, Doug,
Thanks for the feedback.
I don't know if you welcome external feedback, but I'd like to point
out (if you're not already aware) that this change modifies the VM
interface.
While I'm cognisant of the reason for the change, my understanding of
the existing map mechanism is that it makes the JDK class library
independent of the underlying VM thread status values. The value of
Thread.threadStatus is opaque, with the mapping from VM thread status
being determined by the following VM interface functions (see
hotspot/src/share/vm/prims/jvm.h):
--
/*
* Returns an array of the threadStatus values representing the
* given Java thread state. Returns NULL if the VM version is
* incompatible with the JDK or doesn't support the given
* Java thread state.
*/
JNIEXPORT jintArray JNICALL
JVM_GetThreadStateValues(JNIEnv* env, jint javaThreadState);
/*
* Returns an array of the substate names representing the
* given Java thread state. Returns NULL if the VM version is
* incompatible with the JDK or the VM doesn't support
* the given Java thread state.
* values must be the jintArray returned from JVM_GetThreadStateValues
* and javaThreadState.
*/
JNIEXPORT jobjectArray JNICALL
JVM_GetThreadStateNames(JNIEnv* env, jint javaThreadState, jintArray values);
--
These two functions are used by the native method
sun.misc.VM.getThreadStateValues to setup the arrays which are then
used to initialise the map.
This change breaks this abstraction, and requires Thread.threadStatus
to be a JVM TI thread state (which happens to match Hotspot's internal
thread state). This change will therefore break any VM which does not
have an internal thread state based on JVM TI.
As far as I'm aware, IKVM and CACAO are currently the only other users
of OpenJDK (I'm also nearing completion of a port to JamVM).
Unfortunately, from looking at CACAO I can see that this change will
break it. It may also break IKVM, but I haven't checked. I, of
course, can modify the internal thread states of JamVM to be
compatible.
I'm CC'ing CACAO's mailing list and GNU Classpath so that affected
parties can be made aware of this change. As an aside, will there be
any later clean-up of the native method implementation and VM
interface?
Thanks,
Rob.
On 12/04/10 04:22, Eamonn McManus wrote:
Hi Mandy,
This test:
if ((threadStatus JVMTI_THREAD_STATE_RUNNABLE) == 1) {
is always false, since JVMTI_THREAD_STATE_RUNNABLE is 4. (NetBeans 7.0
helpfully flags this; I'm not sure if earlier versions do.)
Good catch. This explains why the speed up for RUNNABLE was not as high in
the microbenchmark measurement. Correcting it shows that Thread.getState()
gets 3.5X speed up on a thread in RUNNABLE state.
But, once corrected, I think you could use this idea further to write a much
simpler and faster method, on these lines:
public static Thread.State toThreadState(int threadStatus) {
if ((threadStatus JVMTI_THREAD_STATE_RUNNABLE) != 0) {
return RUNNABLE;
} else if ((threadStatus
JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER) != 0) {
return BLOCKED;
} else if ((threadStatus JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT)
!= 0) {
return TIMED_WAITING;
} else if ((threadStatus JVMTI_THREAD_STATE_WAITING_INDEFINITELY)
!= 0) {
return WAITING;
} else if ((threadStatus JVMTI_THREAD_STATE_TERMINATED) != 0) {
return TERMINATED;
} else {
return NEW;
}
}
I forgot to mention in the email that I implemented this simpler approach to
compare with the table lookup approach. There were no significant
difference. I now rerun with the corrected fix (checking != 0 rather than
== 1) and the table lookup approach is about 2-6% faster than the sequence
of tests approach.
I am also for the simpler approach but I post the table lookup approach as a
proposed fix to get any opinion on the performance aspect with that
approach.
Given that the Fork-Join framework doesn't depend on it, I will go for a
simpler approach (sequence of tests) and further tune its performance when
there is a use case requiring a perf improvement.
New webrev:
http://cr.openjdk.java.net/~mchung/6977034/webrev.01/
Can you review this version?
Thanks
Mandy
You could tweak the order of the tests based on what might be the relative
frequency of the different states but it probably isn't worth it.
Regards,
Éamonn
On 3/12/10 11:52 PM, Mandy Chung wrote:
Fix for 6977034: Thread.getState() very slow
Webrev at:
http://cr.openjdk.java.net/~mchung/6977034/webrev.00/
This is an improvement to map a Thread's threadStatus field to
Thread.State. The VM updates the Thread.threadStatus field directly at
state transition with the value as defined in JVM TI [1].
Re: Classpath IPP Logging
On 26 April 2010 11:23, Andrew Haley a...@redhat.com wrote: On 04/23/2010 06:26 PM, Andrew Haley wrote: Does anyone here have any idea how to turn on IPP logging in GNU Classpath? It's used like: logger.log(Component.IPP, Attribute: Name: + jobUri.getCategory() .getName() + Value: + jobUri.toString() + ); It would be very useful to enable this, but I just can't figure it out. Is there really no-one understands how to use Classpath's system logger, or is it that no-one reads this list any more? I still read this list, but unfortunately I know nothing about logging in GNU Classpath, or even what IPP is! A quick google search did turn this up, but I expect you aready know this: Logger for tracing - enable by passing -Dgnu.classpath.debug.components=ipp to the vm. http://www.docjar.org/docs/api/gnu/javax/print/ipp/IppPrintService.html Rob. Andrew.
JamVM 1.5.4 released
Hi, I'm pleased to announce the release of JamVM 1.5.4 (http://jamvm.org). Improvements include faster GC, updated JNI and the usual set of bug-fixes. The full list of changes are here: http://sourceforge.net/projects/jamvm/files/jamvm/JamVM%201.5.4/release_notes/view Happy New Year! Rob.
Re: JAM VM hangs after running for ~2 hours.
Hi, Quick reply: 1) You can get a dump of all the threads and their stack traces by sending SIGQUIT to the jamvm process (find the process ID via ps or top), e.g. kill -3 process ID JamVM will dump the thread state and continue. If you launched JamVM from a terminal you can also do Ctrl-\ in the terminal, which will send SIGQUIT. 2) Attach gdb to jamvm and inspect the threads, e.g.: gdb jamvm process ID list all threads with: info threads then, for each interesting thread: thread thread no bt 3) Run JamVM with strace This will dump information about every system call being executed. However, if it takes two hours to hang this will probably be far too much information. Rob. 2009/7/15 ragoel rag...@ipolicynetworks.com: Problem: JAM VM hangs after running for ~2 hours. There is no response from jetty (running on jamvm) at this time. The environment is: - the jam vm version is JamVM 1.5.3 - GNU Classpath version is 0.98 - the GNU Classpath is build by disabling the following things as they are not required by us: . /configure --disable-gtk-peer --disable-plugin --disable-gconf-peer --enable-tools - we are running jetty 6.1.8 using the jam vm. - we are connecting to the jetty (which is running on jamvm), through the browser (IE7) on port 8080, but there is no response from the server. - Our code runs fine when it is running jetty on sun jre 1.5. So it is certain that the problem is with the jamvm - the linux platform is: debian - After some analysis, it seems that there is some bug in the socket library of GNU Classpath due to which it stops responding after running for sometime. Queries: Basically we are not able to do anything when the JAMVM hangs, so could someone please tell me about how to debug the jamvm when it hangs i.e. - Is there any hook so that we can attach something to it, - Can we debug it remotely, - How to enable logging in it? - Any tool which can aid us in analyzing this problem further? We are stuck on this; please provide your valuable suggestions/resolutions for the same? -- View this message in context: http://www.nabble.com/JAM-VM-hangs-after-running-for-%7E2-hours.-tp24494239p24494239.html Sent from the Gnu - Classpath - General mailing list archive at Nabble.com.
Re: JAM VM hangs after running for ~2 hours.
P.S. JamVM has several tracing options, most of which need to be enabled at configuration time. Do ./configure --help to find out which ones are available. Then enable using --enable-traceX, e.g: ./configure --enable-tracethread --enable-tracealloc Rob. 2009/7/15 Robert Lougher rob.loug...@gmail.com: Hi, Quick reply: 1) You can get a dump of all the threads and their stack traces by sending SIGQUIT to the jamvm process (find the process ID via ps or top), e.g. kill -3 process ID JamVM will dump the thread state and continue. If you launched JamVM from a terminal you can also do Ctrl-\ in the terminal, which will send SIGQUIT. 2) Attach gdb to jamvm and inspect the threads, e.g.: gdb jamvm process ID list all threads with: info threads then, for each interesting thread: thread thread no bt 3) Run JamVM with strace This will dump information about every system call being executed. However, if it takes two hours to hang this will probably be far too much information. Rob. 2009/7/15 ragoel rag...@ipolicynetworks.com: Problem: JAM VM hangs after running for ~2 hours. There is no response from jetty (running on jamvm) at this time. The environment is: - the jam vm version is JamVM 1.5.3 - GNU Classpath version is 0.98 - the GNU Classpath is build by disabling the following things as they are not required by us: . /configure --disable-gtk-peer --disable-plugin --disable-gconf-peer --enable-tools - we are running jetty 6.1.8 using the jam vm. - we are connecting to the jetty (which is running on jamvm), through the browser (IE7) on port 8080, but there is no response from the server. - Our code runs fine when it is running jetty on sun jre 1.5. So it is certain that the problem is with the jamvm - the linux platform is: debian - After some analysis, it seems that there is some bug in the socket library of GNU Classpath due to which it stops responding after running for sometime. Queries: Basically we are not able to do anything when the JAMVM hangs, so could someone please tell me about how to debug the jamvm when it hangs i.e. - Is there any hook so that we can attach something to it, - Can we debug it remotely, - How to enable logging in it? - Any tool which can aid us in analyzing this problem further? We are stuck on this; please provide your valuable suggestions/resolutions for the same? -- View this message in context: http://www.nabble.com/JAM-VM-hangs-after-running-for-%7E2-hours.-tp24494239p24494239.html Sent from the Gnu - Classpath - General mailing list archive at Nabble.com.
Re: JAM VM gives the following exceptions:
Obviously something is trying to load the GTK AWT peers which you haven't built: Caused by: java.lang.UnsatisfiedLinkError: Native library `gtkpeer' not found (as file `libgtkpeer.so') in gnath at java.lang.Runtime.loadLibrary(Runtime.java:763) at java.lang.System.loadLibrary(System.java:670) at gnu.java.awt.peer.gtk.GtkToolkit.clinit(GtkToolkit.java:177) at java.lang.VMClass.forName(Native Method) at java.lang.Class.forName(Class.java:233) at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:583) Rob. 2009/7/15 ragoel rag...@ipolicynetworks.com: The environment is: - the jam vm version is JamVM 1.5.3 - GNU Classpath version is 0.98 - the GNU Classpath is build by disabling the following things as they are not required by us: . /configure --disable-gtk-peer --disable-plugin --disable-gconf-peer --enable-tools - we are running jetty 6.1.8 using the jam vm. - we are connecting to the jetty (which is running on jamvm), through the browser (IE7) on port 8080, but there is no response from the server. - Our code runs fine when it is running jetty on sun jre 1.5. So it is certain that the problem is with the jamvm - the linux platform is: debian - After some analysis, it seems that there is some bug in the socket library of GNU Classpath due to which it stops responding after running for sometime. The exceptions are: java.lang.IllegalArgumentException: channel already registered at gnu.java.nio.EpollSelectorImpl.register(EpollSelectorImpl.java:266) at java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:251) at java.nio.channels.SelectableChannel.register(SelectableChannel.java:114) at org.mortbay.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:488) at org.mortbay.io.nio.SelectorManager.doSelect(SelectorManager.java:166) at org.mortbay.jetty.nio.SelectChannelConnector.accept(SelectChannelConnector.java:124) at org.mortbay.jetty.AbstractConnector$Acceptor.run(AbstractConnector.java:537) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450) java.nio.channels.NotYetConnectedException at gnu.java.nio.SocketChannelImpl.write(SocketChannelImpl.java:240) at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:166) at org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:207) at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:693) at org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerator.java:566) at org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:910) at org.mortbay.jetty.AbstractGenerator$OutputWriter.flush(AbstractGenerator.java:731) at java.io.PrintWriter.flush(PrintWriter.java:244) at org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:221) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:985) at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:671) at org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:884) at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:855) at org.apache.jsp.template_jsp._jspService(org.apache.jsp.template_jsp:135) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:93) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:470) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:364) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:285) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:126) at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1056) at org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesRequestProcessor.java:261) at org.apache.struts.tiles.TilesRequestProcessor.processTilesDefinition(TilesRequestProcessor.java:237) at org.apache.struts.tiles.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.java:300) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:231) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:397) at
JamVM 1.5.3 released
Hi, I'm pleased to announce the release of JamVM 1.5.3 (http://jamvm.org). JamVM 1.5.3 is primarily a bug-fix release. It fixes issues seen while running Eclipse 3.4.2 and JRuby 1.2.0RC2, and adds some minor features. The full list of changes are here: http://sourceforge.net/project/shownotes.php?release_id=675892group_id=75148 Thanks, Rob.
Re: using Smack API with GNU Classpath
Hi Jan, 2009/2/16 Jan Pannecoeck j...@mgb-tech.com: Hello everyone, I'm a Java Developer and I'm working mainly with embedded devices. Now I'm running JamVM with GNU Classpath on an ARM processor. This is all working fine, and I didn't had any big problems until now... I'll try to explain my problem as good as possible, but if someone needs some more information, you can contact me ofcourse! So, I'm using the Smack API to get an XMPPConnection with my XMPPServer. This is working, but my CPU is running at 100%! I do have the same problem (CPU at 100%) when I try to run this java program on my desktop computer with JamVM and GNU Classpath. When I run it using Sun's JVM, the CPU load is around 0-1 %. I don't have any clue what this problem could be causing, I'm trying to find out what part of the Smack API is causing the problems, but at the moment I log-in to the server, the CPU jumps to 100%... Could this be caused by some encryption that's been used by Smack? Since the Smack API needs a KeyStoreType, I'm using the gkr type since that's the one supported by GNU Classpath... If anyone had this kind of problems before with GNU Classpath, or could solve my problem, this would be great!! Any help would be welcome since I'm quite stuck with this... What version of JamVM are you using? It's possible some code you're running is using the new concurrency API (JSR 166). In JamVM 1.5.1, park/unpark was incomplete and could use 100% CPU. This is fixed in 1.5.2. Rob. Kind regards, Jan
Re: using Smack API with GNU Classpath
Hi Jan, 2009/2/16 Jan Pannecoeck j...@mgb-tech.com: Hello Robert, I'm using JamVM 1.5.0 at the ARM and JamVM 1.4.5 at my desktop pc. Is the problem you described also in those versions, or only in the 1.5.1 version? Yes, the problem is in both 1.4.5 and 1.5.0 (JSR 166 support was added in 1.4.5, with an inefficient park/unpark implementation -- this has finally been replaced in 1.5.2). Rob. Thanks for your reply! Jan Robert Lougher wrote: Hi Jan, 2009/2/16 Jan Pannecoeck j...@mgb-tech.com: Hello everyone, I'm a Java Developer and I'm working mainly with embedded devices. Now I'm running JamVM with GNU Classpath on an ARM processor. This is all working fine, and I didn't had any big problems until now... I'll try to explain my problem as good as possible, but if someone needs some more information, you can contact me ofcourse! So, I'm using the Smack API to get an XMPPConnection with my XMPPServer. This is working, but my CPU is running at 100%! I do have the same problem (CPU at 100%) when I try to run this java program on my desktop computer with JamVM and GNU Classpath. When I run it using Sun's JVM, the CPU load is around 0-1 %. I don't have any clue what this problem could be causing, I'm trying to find out what part of the Smack API is causing the problems, but at the moment I log-in to the server, the CPU jumps to 100%... Could this be caused by some encryption that's been used by Smack? Since the Smack API needs a KeyStoreType, I'm using the gkr type since that's the one supported by GNU Classpath... If anyone had this kind of problems before with GNU Classpath, or could solve my problem, this would be great!! Any help would be welcome since I'm quite stuck with this... What version of JamVM are you using? It's possible some code you're running is using the new concurrency API (JSR 166). In JamVM 1.5.1, park/unpark was incomplete and could use 100% CPU. This is fixed in 1.5.2. Rob. Kind regards, Jan
Re: using Smack API with GNU Classpath
P.S. Unfortunately, to upgrade to 1.5.2, you'll also need to upgrade GNU Classpath to 0.98... Rob. 2009/2/16 Robert Lougher rob.loug...@gmail.com: Hi Jan, 2009/2/16 Jan Pannecoeck j...@mgb-tech.com: Hello Robert, I'm using JamVM 1.5.0 at the ARM and JamVM 1.4.5 at my desktop pc. Is the problem you described also in those versions, or only in the 1.5.1 version? Yes, the problem is in both 1.4.5 and 1.5.0 (JSR 166 support was added in 1.4.5, with an inefficient park/unpark implementation -- this has finally been replaced in 1.5.2). Rob. Thanks for your reply! Jan Robert Lougher wrote: Hi Jan, 2009/2/16 Jan Pannecoeck j...@mgb-tech.com: Hello everyone, I'm a Java Developer and I'm working mainly with embedded devices. Now I'm running JamVM with GNU Classpath on an ARM processor. This is all working fine, and I didn't had any big problems until now... I'll try to explain my problem as good as possible, but if someone needs some more information, you can contact me ofcourse! So, I'm using the Smack API to get an XMPPConnection with my XMPPServer. This is working, but my CPU is running at 100%! I do have the same problem (CPU at 100%) when I try to run this java program on my desktop computer with JamVM and GNU Classpath. When I run it using Sun's JVM, the CPU load is around 0-1 %. I don't have any clue what this problem could be causing, I'm trying to find out what part of the Smack API is causing the problems, but at the moment I log-in to the server, the CPU jumps to 100%... Could this be caused by some encryption that's been used by Smack? Since the Smack API needs a KeyStoreType, I'm using the gkr type since that's the one supported by GNU Classpath... If anyone had this kind of problems before with GNU Classpath, or could solve my problem, this would be great!! Any help would be welcome since I'm quite stuck with this... What version of JamVM are you using? It's possible some code you're running is using the new concurrency API (JSR 166). In JamVM 1.5.1, park/unpark was incomplete and could use 100% CPU. This is fixed in 1.5.2. Rob. Kind regards, Jan
[cp-patches] JamVM 1.5.2 released
Hi, I'm pleased to announce the release of JamVM 1.5.2 (http://jamvm.sourceforge.net). The codebase has generally been tidied up, several features have been implemented and quite a few bugs fixed. The full list of changes are here: http://sourceforge.net/project/shownotes.php?release_id=658505group_id=75148 Thanks, Rob. P.S. I'll update the project web page tomorrow...
Re: [cp-patches] FYI: GCC 4.3.3 build fix
Hi Andrew, 2009/2/4 Andrew John Hughes gnu_and...@member.fsf.org: This fixes a warning that causes a build failure when compiling with -Werror on GCC 4.3.3. ChangeLog: 2009-02-03 Andrew John Hughes ahug...@redhat.com * native/jni/native-lib/cpproc.c: (cpproc_forkAndExec): Handle return of chdir. A while ago, I made a similar change, but it broke process forking (easiest way to test is to run the Mauve harness). I tracked it down to the fact that it was exiting when chdir failed, which implies it fails in valid cases. I'm away from any Linux box of any kind at the moment, so I can't check any of this though... Thanks, Rob. -- 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: mauve tests hanging on jamvm
Hi Mark, Thanks for the report. I recently merged the development branch for JamVM 1.5.2 to main as it seemed stable. Looks like there's still some bugs :( I'll see if I can reproduce it here running Mauve... Thanks, Rob. 2008/12/15 Mark Wielaard m...@klomp.org: Sorry for the lame bug report. I haven't had time to investigate much. But I want to make sure I don't forget about this issue. On builder.classpath.org we run mauve against jamvm cvs. Since a couple of days it gets stuck. Apparently always at the same point, since the log always shows: PASS: java.awt.Choice.getSelected FAIL: java.awt.Choice.PaintTest line 70: [1] -- boolean passed to check was false At the time of the hang the process tree looks as follows: 12322 ?Ss22:21 SCREEN 12323 pts/1Ss 0:00 \_ /bin/bash 1946 pts/1S+ 0:00 | \_ /bin/sh /home/cpdev/bin/start-buildd 17667 pts/1S+ 0:00 | \_ /bin/sh /home/cpdev/Nightly/scripts/Everything 21881 pts/1S+ 0:00 | | \_ /bin/sh /home/cpdev/Nightly/scripts/Check 22523 pts/1S+ 0:00 | | \_ /bin/sh /home/cpdev/Nightly/scripts/Mauve 22541 pts/1S+ 0:00 | | \_ /bin/sh /home/cpdev/Nightly/scripts/Mauve 23109 pts/1S+ 0:00 | | \_ /bin/sh /usr/bin/xvfb-run jamvm Harness gnu.testlet -vm jamvm -showpasses -timeout 18 23120 pts/1S+ 0:00 | | \_ Xvfb :99 -screen 0 640x480x8 -nolisten tcp 23122 pts/1Sl+0:10 | | \_ jamvm Harness gnu.testlet -vm jamvm -showpasses -timeout 18 23128 pts/1Z+ 0:00 | | \_ [jamvm] defunct 23133 pts/1Sl+4:54 | | \_ jamvm RunnerProcess gnu.testlet -vm jamvm -showpasses -timeout 18 17671 pts/1S+ 0:03 | \_ tee Everything.log The scripts used can be found in mauve CVS: http://sourceware.org/cgi-bin/cvsweb.cgi/builder/?cvsroot=mauve kill -SIGQUIT 23122 gives: -- JamVM version 1.5.2-devel Full Thread Dump --- main 0x8079480 priority: 5 tid: 0xf7e35aa0 id: 1 state: RUNNABLE (6) at gnu.java.nio.VMChannel.read(Native method) at gnu.java.nio.VMChannel.read(VMChannel.java:159) at gnu.java.nio.FileChannelImpl.read(FileChannelImpl.java:232) at java.io.FileInputStream.read(FileInputStream.java:283) at java.io.FileInputStream.read(FileInputStream.java:254) at java.io.InputStreamReader.read(InputStreamReader.java:459) at java.io.BufferedReader.fill(BufferedReader.java:370) at java.io.BufferedReader.readLine(BufferedReader.java:469) at Harness.runTest(Harness.java:816) at Harness.runFolder(Harness.java:1307) at Harness.processFolder(Harness.java:1282) at Harness.processFolder(Harness.java:1260) at Harness.processFolder(Harness.java:1260) at Harness.processFolder(Harness.java:1260) at Harness.processTest(Harness.java:918) at Harness.runAllTests(Harness.java:725) at Harness.main(Harness.java:188) Thread-5 0x8555480 priority: 10 tid: 0xeb271bb0 id: 10 state: TIMED_WAITING (4) at java.lang.VMObject.wait(Native method) at java.lang.Object.wait(Object.java:528) at java.lang.Object.wait(Object.java:480) at Harness$TimeoutWatcher.run(Harness.java:1510) at java.lang.Thread.run(Thread.java:745) Thread-4 0x8302108 priority: 10 tid: 0xebbf7bb0 id: 9 state: TIMED_WAITING (4) at java.lang.VMObject.wait(Native method) at java.lang.Object.wait(Object.java:528) at java.lang.Object.wait(Object.java:480) at Harness$TimeoutWatcher.run(Harness.java:1510) at java.lang.Thread.run(Thread.java:745) Thread-2 0x82f08f0 priority: 5 tid: 0xec3f8bb0 id: 8 state: RUNNABLE (6) at gnu.java.nio.VMChannel.read(Native method) at gnu.java.nio.VMChannel.read(VMChannel.java:159) at gnu.java.nio.FileChannelImpl.read(FileChannelImpl.java:232) at java.io.FileInputStream.read(FileInputStream.java:283) at java.io.FileInputStream.read(FileInputStream.java:254) at java.io.InputStreamReader.read(InputStreamReader.java:459) at java.io.BufferedReader.fill(BufferedReader.java:370) at java.io.BufferedReader.readLine(BufferedReader.java:469) at Harness$ErrorStreamPrinter.run(Harness.java:1419) at java.lang.Thread.run(Thread.java:745) Thread-3 0x82e05f0 priority: 5 tid: 0xecbf9bb0 id: 7 state: TIMED_WAITING (4) at java.lang.VMThread.sleep(Native method) at java.lang.Thread.sleep(Thread.java:904) at java.lang.Thread.sleep(Thread.java:868) at Harness$InputPiperThread.run(Harness.java:1734) Thread-1 (daemon) 0x82cd310 priority: 5 tid: 0xed3fabb0 id: 6 state: TIMED_WAITING (4) at java.lang.VMObject.wait(Native method) at
Fwd: Missing ReleaseArrayElements
Hi, Sorry to nag about this, but it would be good to get this applied. Without it, the Swing Demo leaks like a sieve on JamVM :) Rob. -- Forwarded message -- From: Robert Lougher [EMAIL PROTECTED] Date: Fri, Oct 10, 2008 at 7:55 AM Subject: Missing ReleaseArrayElements To: classpath-patches [EMAIL PROTECTED] Hi, This fixes a missing ReleaseArrayElements in the GTK peer code (fixing a noticeable memory leak). Rob. Index: native/jni/gtk-peer/gnu_java_awt_peer_gtk_CairoGraphics2D.c === RCS file: /sources/classpath/classpath/native/jni/gtk-peer/gnu_java_awt_peer_gtk_CairoGraphics2D.c,v retrieving revision 1.26 diff -u -r1.26 gnu_java_awt_peer_gtk_CairoGraphics2D.c --- native/jni/gtk-peer/gnu_java_awt_peer_gtk_CairoGraphics2D.c 11 Sep 2007 09:48:49 - 1.26 +++ native/jni/gtk-peer/gnu_java_awt_peer_gtk_CairoGraphics2D.c 10 Oct 2008 06:44:01 - @@ -372,6 +372,7 @@ } gdk_threads_leave(); + (*env)-ReleaseLongArrayElements (env, java_fontset, fonts, 0); g_free(glyphs); }
[cp-patches] Missing ReleaseArrayElements
Hi, This fixes a missing ReleaseArrayElements in the GTK peer code (fixing a noticeable memory leak). Rob. Index: native/jni/gtk-peer/gnu_java_awt_peer_gtk_CairoGraphics2D.c === RCS file: /sources/classpath/classpath/native/jni/gtk-peer/gnu_java_awt_peer_gtk_CairoGraphics2D.c,v retrieving revision 1.26 diff -u -r1.26 gnu_java_awt_peer_gtk_CairoGraphics2D.c --- native/jni/gtk-peer/gnu_java_awt_peer_gtk_CairoGraphics2D.c 11 Sep 2007 09:48:49 - 1.26 +++ native/jni/gtk-peer/gnu_java_awt_peer_gtk_CairoGraphics2D.c 10 Oct 2008 06:44:01 - @@ -372,6 +372,7 @@ } gdk_threads_leave(); + (*env)-ReleaseLongArrayElements (env, java_fontset, fonts, 0); g_free(glyphs); }
Re: [cp-patches] Missing ReleaseArrayElements
Hi, I forgot to say that somebody needs to commit this, as I can't :) Thanks, Rob. On Fri, Oct 10, 2008 at 7:55 AM, Robert Lougher [EMAIL PROTECTED] wrote: Hi, This fixes a missing ReleaseArrayElements in the GTK peer code (fixing a noticeable memory leak). Rob.
Re: Problem in displaying swing components on ARM, using GNU Classpath and Cacao
Hi, On Wed, Oct 8, 2008 at 7:44 AM, Pavan Kumar Maddali [EMAIL PROTECTED] wrote: On 10/8/08, Christian Thalinger [EMAIL PROTECTED] wrote: On Wed, 2008-10-08 at 11:37 +0530, Pavan Kumar Maddali wrote: Yes, with the same version of CACAO and GNU Classpath the program is working fine on X86. On ARM, AWT is working fine, but swings components are not visible and the same problem is with java 2d. The problem is not with a specific swing or java 2d program, it is all swing and java 2d programs. It seems like some thing is missing which is required to paint swing components and java 2d. Is there any way to find out what is mssing or debug it? As it works on i386, I'd guess it's a bug in CACAO's ARM JIT compiler. Swing is using a lot of floating point variables and ARM has a number of different floating point units. Can you give me some details about your CPU? - Christian We are using ARM Cortex A8 cpu proccessor and the soft FPU is enabled. How to make GNU Classpath or Cacao realise that there is a soft FPU in the system? To eliminate problems with swing, etc. you could try a different VM (e.g. JamVM). If this works, it points to a problem with Cacao's JIT as twisti suggests. Rob. Thanks Regards MVN Pavankumar
Re: [Jamvm-general] More problems (Resources this time)
Hi,
On Fri, Aug 15, 2008 at 10:20 AM, Jon Senior [EMAIL PROTECTED] wrote:
-Original Message-
Jon, I'm sorry that I can't be very helpful, but I ran into very
similar problems.
I think if you search for my name in the JamVM or Classpath mailing lists,
you'll find some messages from me about this problem.
If I remember correctly, to get JamVM working, I had to unpack the
resources and put the top-level resource directory in the bootclasspath.
I seem to recall that someone (a JamVM or Classpath developer,
I don't remember which) said that they would look into it.
I don't know if anything ever came of it. Sure seems like a bug to me.
Let me know if you think I could supply any info to help you.
OK. The list of things that I have tried is as follows:
- Using -Xbootclasspath/a:glibj-sm.zip
This results in a failure to find the resource.
- Using -Xbootclasspath/a:.:glibj-sm.zip with the resource directory unzipped
into the current directory.
This results in the stack trace at the end of this email.
- Using -Xbootclasspath/a:./full with the entire (complete) Classpath
unzipped into the directory full.
This results in the stack trace at the end of this email.
- Using -Xbootclasspath/a:glibj.zip
This fails immediately with a ClassNotFoundException for java.lang.thread.
It's as if it's unable to find or open the full Classpath!
This does seem somewhat buggy, but I can't see why. I've looked through the
GNU Classpath source in an attempt to work out what's going on and I can't
see why it's trying to use FTP to open the resource. Neither can I work out
why JamVM won't work with the correct classpath when it's zipped, but will
work with my minimal version. I'm guessing there's some weird memory problems
there.
Any hints that you or anyone could offer would be greatly appreciated.
I notice that you're using -Xbootclasspath/a:... This appends the
entries to the end of the default bootclasspath; it does not replace
it. The existing entries in the bootclasspath will be searched
before the appended entries. Is it possible that classes/resources
are being picked up from different places?
To be sure of what is going on, it is probably better to replace the
bootclasspath using -Xbootclasspath:... Alternatively you can use
-Xbootclasspath/c:.. or -Xbootclasspath/v:... By default, the
bootclasspath is made up of two things. Where to find JamVMs VM
classes (normally in classes.zip) and where to find GNU Classpath's
classes (normally in glibj.zip), e.g:
/usr/local/jamvm/share/jamvm/classes.zip:/usr/local/classpath/share/classpath/glibj.zip
-Xbootclasspath:... replaces everything. -Xbootclasspath/v replaces
the VM classes location, leaving the default location of the GNU
Classpath classes, while -Xbootclasspath/c does the opposite ('v' for
VM classes, 'c' for Classpath or core classes!).
As to the general problem I'm afraid I'm not much use. I don't
actually run a huge amount of Java programs myself! I'm CC-ing this
to the GNU Classpath list in case somebody on there can help.
Rob.
java.nio.channels.UnresolvedAddressException
at gnu.java.nio.SocketChannelImpl.connect(SocketChannelImpl.java:160)
at gnu.java.net.PlainSocketImpl.connect(PlainSocketImpl.java:281)
at java.net.Socket.connect(Socket.java:454)
at java.net.Socket.connect(Socket.java:414)
at gnu.java.net.protocol.ftp.FTPConnection.init(FTPConnection.java:253)
at gnu.java.net.protocol.ftp.FTPConnection.init(FTPConnection.java:221)
at
gnu.java.net.protocol.ftp.FTPURLConnection.connect(FTPURLConnection.java:121)
at
gnu.java.net.protocol.ftp.FTPURLConnection.getInputStream(FTPURLConnection.java:165)
at java.net.URL.openStream(URL.java:737)
at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:733)
at java.util.ResourceBundle.tryBundle(ResourceBundle.java:481)
at java.util.ResourceBundle.tryBundle(ResourceBundle.java:550)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:400)
at java.util.Calendar.getBundle(Calendar.java:483)
at java.util.Calendar.init(Calendar.java:508)
at java.util.GregorianCalendar.init(GregorianCalendar.java:237)
at java.util.GregorianCalendar.init(GregorianCalendar.java:224)
at java.util.Calendar.getInstance(Calendar.java:612)
at java.util.Calendar.getInstance(Calendar.java:538)
at java.util.zip.ZipEntry.getCalendar(ZipEntry.java:225)
at java.util.zip.ZipEntry.setTime(ZipEntry.java:172)
at java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:222)
at com.gulfstreamsoftware.tdrouter.Controller.main(Controller.java:65)
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
Re: java.lang.TypeNotPresentException when using reflection
Hi, On Wed, Aug 13, 2008 at 6:20 PM, Tom Spencer [EMAIL PROTECTED] wrote: I have been attempting to use reflection, in particular to get the superclass of a particular class, but this seems to fail when using Classpath v0.97.2 with JamVM 1.5.0. I've investigated this and there's a bug in JamVMs handling of generic signatures (rather than returning the raw generic signature, slashes are replaced by dots, as in other class names; the dots are then converted to $). This is fixed in CVS HEAD. Instructions for checking it out can be found here: http://developer.berlios.de/cvs/?group_id=6545 Alternatively, apply the attached patch to natives.c. This has been generated against JamVM 1.5.0. I have found the following older forum posts, but neither have been that helpful in trying to diagnose the issue. http://developer.classpath.org/pipermail/classpath/2006-November/001605.html http://www.nabble.com/Error-in-resolving-java.util.Set-td9779444.html No idea how I missed these (especially the second post)! Let me know how you get on. Thanks, Rob. Thanks! Tom natives.c-patch Description: Binary data
Re: FW: Help a noob?
Hi, You could always try JamVM. It doesn't need javac to build, just a C compiler. It also supports MIPS32 (o32). The problem is, it has never been built or tested on IRIX. However, it's pretty portable, and as long as IRIX has pthreads and dlopen, etc. it should work with minor modifications. You will need to update configure.ac to recognise IRIX, and either create an os/irix directory by copying the linux implementation, or just use the linux directory directly, e.g: mipsel-*-irix) host_cpu=mips host_os=linux ;; I'm guessing here what the canonical host string is for IRIX/MIPS32. As a matter of interest, is IRIX/MIPS big or little endian? Thanks, Rob. On Wed, Aug 13, 2008 at 7:48 PM, Greene, Geoffrey N [EMAIL PROTECTED] wrote: Hooray! I got classpath installed (had to make a few mods) to the source code.. Now I'm on to cacao..which needs javac again... To build vm.zip Anyone got a way to get one for 0.99.2? -Original Message- From: David Daney [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 13, 2008 2:37 PM To: Christian Thalinger Cc: Greene, Geoffrey N; classpath@gnu.org Subject: Re: FW: Help a noob? Christian Thalinger wrote: On Wed, 2008-08-13 at 11:32 -0400, Greene, Geoffrey N wrote: OK, I've got the glibj.zip (thanks!) Compiling now. (had to modifify configure, because it was STILL trying to run javac.) I see your os is IRIX64 What about mips32? Any support for that? Yes, we also support MIPS32 (o32 and n32). FWIW, n32 is a 64bit ABI (although it is difficult to tell from its name) and as such cannot run on 32-bit mips machines. David Daney
Re: Trying to build classpath under AIX
Hi, See the earlier posts about building Classpath without Classpath. I use jikes, a native Java compiler to build an earlier non-generics version of Classpath (you need to do this as jikes is not 1.5 compatible). I then use this with JamVM to run ecj. As ecj is 1.5 compatible, this can be used to build the latest version of Classpath. With JamVM 1.5.1, compatible non-generics versions of Classpath are 0.92 or 0.93 (earlier versions of Classpath won't work). Both of these can be used to run ecj. I use a simple script to run ecj: #!/bin/sh exec /usr/local/jamvm/bin/jamvm -Xmx512m -Xms256m \ -cp path to ecj.jar \ org.eclipse.jdt.internal.compiler.batch.Main \ $@ Rob. On 5/9/08, Thorbjørn Ravn Andersen [EMAIL PROTECTED] wrote: Hi. I am trying to build jamvm+GNU Classpath under AIX 5.2 which unfortunately does only have Java 1.4, and I got stuck on building Classpath which requires Java 1.5 I tried playing around with the latest stable ecj.jar (and --disable-jni which I do not need) to get compilation going with that, but apparently it is not enough specifying the ecj.jar location. A shell script must be written and my plain attempt just to script a call to java -jar ecj.jar did not work out well. It misdetects which arguments the compiler supports- Perhaps it is an exit code thing. What is the recommended approach to get over this. I just need a headless version. Best regards, -- Thorbjørn
Re: Inconvertible types error in EnumSet.java
Hi Andrew, On 3/19/08, Andrew John Hughes [EMAIL PROTECTED] wrote: On 19/03/2008, Trevor Harmon [EMAIL PROTECTED] wrote: On Mar 18, 2008, at 12:51 PM, Andreas Tobler wrote: You need an ecj.tar What version of ecj do I need for the latest classpath? Is 3.1.2 good enough? 3.2 works for definite. I seem to recall 3.1.2 working but don't quote me on that. Give it a try, and let us know if it doesn't. and a working jamvm. Okay this is something that has confused me. classpath seems to have a dependency on jamvm, but jamvm seems to have a dependency on classpath. How is this not circular? It is circular. Such is life with Java (OpenJDK also needs a JDK to compile FWIW). To bootstrap, you can use gcj/gij to run ecj. Many distros (e.g. debian) ship with a native version of ecj that runs using gcj. With JamVM 1.5.1, etc. I've deliberately kept compatibility with Classpath-0.92 to break the dependency circle. On a machine with no Java VM or compiler installed: 1) Build or install Jikes 2) Build Classpath-0.92 using Jikes 3) Build JamVM 1.5.1 4) Use the resultant JamVM/Classpath to run ecj 5) Build Classpath-0.97.1 using ecj This relies on being able to build JamVM without a 1.5 compliant Java compiler. I do two things: 1) JamVM releases include a pre-built classes.zip containing JamVMs VM classes (if the source is changed classes.zip is rebuilt). This means no Java compiler is required to build a JamVM release. 2) JamVMs VM classes are not genericized. This means that even without the pre-built classes.zip JamVM can be installed using Jikes. This is useful for building the CVS version of JamVM on an otherwise bare machine. Thanks, Rob. P.S. Changing the subject, this is one of my concerns with the change to the VM interface for the new VM reflection classes. If JamVM moves to the new interface it breaks the ability to use JamVM/Classpath-0.92 as a bootstrap... Trevor -- Andrew :-) Document Freedom Day - March 26th http://documentfreedom.org 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: Inconvertible types error in EnumSet.java
Hi, On 3/19/08, Andrew John Hughes [EMAIL PROTECTED] wrote: Also, most distros should ship with old versions of Classpath and a VM so you should be able to use that to run ecj (it doesn't require 1.5 features, which is where the problem comes in). Likewise, you can build pre-0.95 versions of Classpath with a native compiler like Jikes. Unfortunately, no non-Java compilers managed to jump the fence to 1.5 :( Yes, any pre-0.95 version of Classpath should be OK to bootstrap a later version of Classpath using ecj. JamVM 1.5.1 is compatible with 0.92 and 0.93 which can be used for this purpose (there was no 0.94). I use GNU Classpath-0.92, as this is one I have available locally... When later versions of JamVM breaks compatibility with 0.92/0.93, you'll also have to download and build an older version to do the bootstrap (or any other compatible VM). It might be useful to have a list somewhere of GNU Classpath versions and a list of which VM/versions are compatible with it! Thanks, Rob. -- Andrew :-) Document Freedom Day - March 26th http://documentfreedom.org 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
JamVM 1.5.1 released
Hi, I'm pleased to announce the release of JamVM 1.5.1(http://jamvm.sourceforge.net). This is a minor-feature and bug-fix release. The full list of changes are here: http://sourceforge.net/project/shownotes.php?release_id=583302 Thanks, Rob. P.S. JamVM 1.0.0 was released 5 years ago today!
Re: [cp-patches] RFC: use helper method to clone char array in java.lang.String
Hi,
On 2/4/08, Ian Rogers [EMAIL PROTECTED] wrote:
Hi,
xalan performs 1.4 million char array clones per iteration of the normal
size DaCapo benchmark. All of the character array clones are coming from
java.lang.String. The attached patch changes the use of char[].clone
(which maps to java.lang.Object.clone) to a helper method that allocates
the character array and then array copies from the source to the new
array. On the Jikes RVM I get the following performance results from 10
iterations of DaCapo using the large data set size:
current java.lang.String using char[].clone:
run 1: 99157ms
run 2: 98700ms
run 3: 97927ms
patched java.lang.String using the helper routine:
run 1: 97710ms
run 2: 97406ms
run 3: 96762ms
The speed up is between 0.22% and 1.2%. Do people think using the helper
is a sensible change?
I would like to see evidence that this is a win, or at least has no
slowdown on other VMs (i.e. it is VM independent). I think it would
be inappropriate if it was only to address implementation issues in
JikesRVM. For example, why is the helper faster than clone? Surely
all clone() should be doing is an alloc and then an arraycopy?
Rob.
Thanks,
Ian
--- java/lang/String.java 2008-01-23 09:01:02.0 +
+++ java/lang/String.java 2008-02-04 13:43:02.0 +
@@ -1284,6 +1284,13 @@
return new String(newStr, 0, newStr.length, true);
}
+ private static char[] cloneCharArray(char[] src)
+ {
+char[] copy = new char[src.length];
+VMSystem.arraycopy(src, 0, copy, 0, src.length);
+return copy;
+ }
+
/**
* Replaces every instance of a character in this String with a new
* character. If no replacements occur, this is returned.
@@ -1303,7 +1310,7 @@
break;
if (i 0)
return this;
-char[] newStr = (char[]) value.clone();
+char[] newStr = cloneCharArray(value);
newStr[x] = newChar;
while (--i = 0)
if (value[++x] == oldChar)
@@ -1450,7 +1457,7 @@
// Now we perform the conversion. Fortunately, there are no
multi-character
// lowercase expansions in Unicode 3.0.0.
-char[] newStr = (char[]) value.clone();
+char[] newStr = cloneCharArray(value);
do
{
char ch = value[x];
@@ -1504,7 +1511,7 @@
// Now we perform the conversion. Fortunately, there are no
// multi-character lowercase expansions in Unicode 3.0.0.
-char[] newStr = (char[]) value.clone();
+char[] newStr = cloneCharArray(value);
do
{
char ch = value[x];
@@ -1557,7 +1564,7 @@
i = count;
if (expand == 0)
{
-char[] newStr = (char[]) value.clone();
+char[] newStr = cloneCharArray(value);
while (--i = 0)
{
char ch = value[x];
@@ -1642,7 +1649,7 @@
i = count;
if (expand == 0)
{
-char[] newStr = (char[]) value.clone();
+char[] newStr = cloneCharArray(value);
while (--i = 0)
{
char ch = value[x];
@@ -1731,7 +1738,7 @@
public char[] toCharArray()
{
if (count == value.length)
- return (char[]) value.clone();
+ return cloneCharArray(value);
char[] copy = new char[count];
VMSystem.arraycopy(value, offset, copy, 0, count);
Re: Quality control and FOSS rant
Hi, I've nothing to add to the defense of GNU Classpath beyond what Roman and Andrew have already said. Instead I'd like to point out that Andy Tripp isn't new to this, and nobody should waste any more time: http://www.javalobby.org/java/forums/t53790.html Rob.
Happy New Year
Hi, Wishing everybody a Happy New Year. Hopefully this will be the year where people will realise that a community developed Java is better than an open-sourced, but closed process, Java :) Rob.
JamVM/Classpath on iPhone
Hi All, The list has been a bit quiet of late, so in case anybody is interested, here's some screen dumps of JamVM/Classpath running on an iPhone : http://homepage.mac.com/robert.lougher/ This shows the usual HelloWorld, and a couple of screenshots running Jetty, a Java-based web application server. This is running in about 20MB, and is using 39 threads. To follow the discussion leading up to this see: https://sourceforge.net/forum/forum.php?thread_id=1866438forum_id=256481 My thanks to everybody who experimented with this, Rob.
Re: [Jamvm-general] JamVM/Classpath on iPhone
HI Serge, On 11/21/07, Serge Sozonoff [EMAIL PROTECTED] wrote: Hi Robert, Thats very cool, thanks for that. I understand the CPU in the iPhone also has Jazelle support. Yes, it does, and it would be great to get it working (the CPU is a Samsung S5L8900 containing an ARM 1176JZF core). The problem is, as far as I'm aware, the details are not public so it will need to be reverse-engineered. As the register-set is shared it may even require kernel support. It's really unfortunate that companies can't help open-source projects better, especially as they're beginning to use so much of it. Thanks, Rob. Thanks, Serge Robert Lougher wrote: Hi All, The list has been a bit quiet of late, so in case anybody is interested, here's some screen dumps of JamVM/Classpath running on an iPhone : http://homepage.mac.com/robert.lougher/ This shows the usual HelloWorld, and a couple of screenshots running Jetty, a Java-based web application server. This is running in about 20MB, and is using 39 threads. To follow the discussion leading up to this see: https://sourceforge.net/forum/forum.php?thread_id=1866438forum_id=256481 My thanks to everybody who experimented with this, Rob. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Jamvm-general mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jamvm-general
Re: Cannot create system class loader (JamVM1.5.0/Classpath0.96.1/MonteVista PPC)
Hi, On 11/6/07, Bregitte Pracht [EMAIL PROTECTED] wrote: I posted this to jamvm-general, but thought I'd post this here as well, in case it is a classpath problem... I'd appreciate any help on the issue. I've just replied on jamvm-general. It doesn't sound like a jamvm issue (Classpath's .so's are missing). It sounds like a simple installation issue. Rob. Thanks! -b. -
Re: [Jamvm-general] Cannot create system class loader (JamVM1.5.0/Classpath0.96.1/MonteVista PPC)
Hi Bregitte, On 11/6/07, Bregitte Pracht [EMAIL PROTECTED] wrote: Hi Rob, Thanks for the response. My system is not a fat/vfat filesystem; symbolic links are fully supported and present for other applications. I have attached the complete build output for classpath. It's a gzip file. OK, I've had a quick look. It looks like you're doing a staging install (i.e. where you install it in a different place to where it finally will be)? The interesting lines are: libtool: install: warning: remember to run `libtool --finish /usr/local/classpath/lib/classpath' From a little googling it appears that libtool can have problems with this, as paths are hard-coded : http://www.mail-archive.com/[EMAIL PROTECTED]/msg09218.html I suggest either trying the suggestions in the mail, or installing in place (i.e. make install, and not make install DESTDIR=xxx) and then removing afterwards. Problem is, this will require root access to install in /usr/local on the build machine. Hope this helps, Rob. Thank you for looking into this! Regards, Bregitte On 11/6/07, Robert Lougher [EMAIL PROTECTED] wrote: Hi Bregitte, On 11/6/07, Bregitte Pracht [EMAIL PROTECTED] wrote: I have cross-compiled JamVM1.5.0 and Gnu Classpath 0.96.1 for the HardHat PowerPC platform (MonteVista). I used these configure options for classpath: --enable-jni, --disable-gtk-peer, --disable-gconf-peer, --disable-plugin, --disable-Werror, --with-javac. The --with-javac options is set to point to Sun's JDK1.6/2 javac binary. Of course --host and --build are set as appropriate for cross-compilation. For jamvm I used the --host and --build configure options as appropriate for cross-compilation. I also used the --with-classpath-install-dir option to point to the classpath installation. Those options look OK to me... When I try to test this out with a simple hello-world test program and I get the following error: Cannot create system class loader Exception occurred while printing exception (java/lang/NoClassDefFoundError) Original exception was java/lang/UnsatisfiedLinkError I searched thejamvm-general email archives. In there was a posting that is somewhat similar. The resolution was to enable-jni. I have it enabled. Looking at my /usr/local/classpath/lib/classpath directory, I don't have any so files, but I have la files. Yes, this is the problem. The .so files contain the code for JNI native methods which Classpath loads when it initialises, and they're not there (so JamVM can't find them). I assume the problem is that so files need to be created, but I am not sure why they are not being built nor what I should do to get them to build. Are you using a fat/vfat filesystem? Copying Classpath onto a fat/vfat filesystem doesn't work because it uses symbolic links which aren't supported by fat/vfat. Please see problem (2) from this email for solutions : http://www.nabble.com/Fwd%3A-Problems-bulding-classpath-0.93-on-ARM5-tf4588154.html#a13096515 If you're not using vfat/fat, send the make and make install output from classpath to me and I'll see if I can work out what's happening. Rob. Does anyone have any idea what I may be doing wrong? Thanks! -b. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Jamvm-general mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jamvm-general
Re: JamVM 1.5.0 The First In Line released
Hi Twisti, On 10/30/07, Christian Thalinger [EMAIL PROTECTED] wrote: On Mon, 2007-10-29 at 20:38 +, Robert Lougher wrote: Hi, I'm pleased to announce the release of JamVM 1.5.0 The First In Line (http://jamvm.sourceforge.net). This release includes the new inline-threaded interpreter (a.k.a super-instructions) and a full port Finally! :-) Yes, it took a while! How's the new GC coming along? ;-) Rob. P.S. Next step getting JamVM to run with OpenJDK. Hmmm. I wonder who's been working on that, and who's code I can look at? :) - twisti
[cp-patches] Re: Still Problem with GNU-Classpath 0.96.1 on StrongARM
Hi, On 10/23/07, Robert Schuster [EMAIL PROTECTED] wrote: Hi, Robert Lougher schrieb: Hi Vladimir, On 10/23/07, Vladimir Nikolov [EMAIL PROTECTED] wrote: Hi, I have still problems to compile the GNU-Classpath 0.96.1 on the StrongARM machine. Once again, I would like to use it together with the JamVM 1.4.5, since both support now Java Annotations and Generics. If I understand this[0] page right EABI is not supported on StrongARM CPUs ... at least not with custom GCC patches. Yes, ARMv4 doesn't have the bx instruction. However, I I didn't know it required a gcc patch. Interestingly, the patch is at odds with the ARM APCS, which recommends bx instructions be subject to a relocation directive, and be replaced at link time. Rob. Regards Robert [0] - http://wiki.debian.org/ArmEabiPort
[cp-patches] Re: Still Problem with GNU-Classpath 0.96.1 on StrongARM
On 10/24/07, Robert Lougher [EMAIL PROTECTED] wrote: Hi, On 10/23/07, Robert Schuster [EMAIL PROTECTED] wrote: Hi, Robert Lougher schrieb: Hi Vladimir, On 10/23/07, Vladimir Nikolov [EMAIL PROTECTED] wrote: Hi, I have still problems to compile the GNU-Classpath 0.96.1 on the StrongARM machine. Once again, I would like to use it together with the JamVM 1.4.5, since both support now Java Annotations and Generics. If I understand this[0] page right EABI is not supported on StrongARM CPUs ... at least not with custom GCC patches. Yes, ARMv4 doesn't have the bx instruction. However, I I didn't know it required a gcc patch. Interestingly, the patch is at odds with the ARM APCS, which recommends bx instructions be subject to a relocation directive, and be replaced at link time. Rob. On re-reading my reply I think I need to clarify. The ARM APCS has provisions for ARMv4, including StrongARM. If ifs recommendations are followed, it is compatble with the standard. Rob. ARM APCS: http://www.arm.com/pdfs/aapcs.pdf Regards Robert [0] - http://wiki.debian.org/ArmEabiPort
Re: Still Problem with GNU-Classpath 0.96.1 on StrongARM
On 10/23/07, Robert Schuster [EMAIL PROTECTED] wrote: Hi, Robert Lougher schrieb: Hi Vladimir, On 10/23/07, Vladimir Nikolov [EMAIL PROTECTED] wrote: Hi, I have still problems to compile the GNU-Classpath 0.96.1 on the StrongARM machine. Once again, I would like to use it together with the JamVM 1.4.5, since both support now Java Annotations and Generics. If I understand this[0] page right EABI is not supported on StrongARM CPUs ... at least not with custom GCC patches. The ARM APCS has provisions for ARMv4, including StrongARM. If its recommendations are followed, it is compatble with the standard. Rob. ARM APCS: http://www.arm.com/pdfs/aapcs.pdf Regards Robert [0] - http://wiki.debian.org/ArmEabiPort -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHHmT1G9cfwmwwEtoRCBkBAJ0fhXqvxr85+mCZATa6iI/EG/qSqACfQ1Ys NQz7ozXrW+EJQW1Pz9YPR3c= =5heR -END PGP SIGNATURE-
Re: Still Problem with GNU-Classpath 0.96.1 on StrongARM
Hi Vladimir, On 10/23/07, Vladimir Nikolov [EMAIL PROTECTED] wrote: Hi, I have still problems to compile the GNU-Classpath 0.96.1 on the StrongARM machine. Once again, I would like to use it together with the JamVM 1.4.5, since both support now Java Annotations and Generics. Here are some informations about the current configuration I use: - StrongARM-110 (v4l) (233 MHz, 256 MB RAM) - Linux Version 2.6.18y, GCC Version 4.1.2, Debian 4.1.1-21 First of all, I'm sorry you're seeing so many problems. One thing you do not mention is whether your ARM machine is using OABI or EABI. Recent distributions of ARM Linux have moved to EABI, and programs that do not handle this will not work correctly. BTW, I get the impression that you're running all of this on the ARM as host, rather than cross-compiling. Can you run your ARM gcc like this: gcc -E -dM - /dev/null This will show all the predefined macros. If your ARM system is configured to use EABI, there should be __ARM_EABI__ somewhere in that. Now the problem. JamVM = 1.4.5 does not support EABI! Of course, even if you are using EABI, I don't know if this is the cause of the error below (it is an assertion failure in GNU Classpath JNI code), but it could be... I have since added EABI support to JamVM, and this is available via CVS : http://developer.berlios.de/cvs/?group_id=6545 Normally, a distribution of JamVM comes with its Java-classes pre-compiled (to stop bootstrap issues). The CVS tree does not contain this. You will either need to install Jikes on the ARM system to build them, or prepare a distribution on another machine with jikes, ecj or gcj available : ./autogen.sh make dist Hope this helps, Rob. 2.) make - produces the following error: Making all in lib make[1]: Entering directory `/home/vladimir/code/src/vm/classpath-0.96.1/lib' true top_builddir=.. top_srcdir=.. /bin/sh ./gen-classlist.sh standard Adding java source files from srcdir '..'. Adding java source files from VM directory ../vm/reference /usr/bin/ecj -1.5 -warn:-deprecation,serial,typeHiding,unchecked,unused,varargsCast -proceedOnError -bootclasspath '' -classpath ../vm/reference:..:../external/w3c_dom:../external/sax:../external/relaxngDatatype:../external/jsr166:.:: -d . @classes jamvm: mprec.c:107: _Jv_Balloc: Assertion `i 16' failed. make[1]: *** [compile-classes] Aborted make[1]: Leaving directory `/home/vladimir/code/src/vm/classpath-0.96.1/lib' make: *** [all-recursive] Error 1 Does anyone have any ideas? Best regards, Vladimir
Re: [cp-patches] FYI: Allow ecj to work via com.sun.tools.javac.Main
Hi, On 10/17/07, Michael Koch [EMAIL PROTECTED] wrote: It would be great if cacao (or any another free runtime) puts the according symlinks in some configurable place like /usr/lib/jvm/java-$JAVAVERSION-$NAME in addition to the normal install into into the $PREFIX (normally /usr in distros). Something like: /usr/lib/jvm/java-1.5.0-jamvm /usr/lib/jvm/java-1.5.0-jamvm/bin /usr/lib/jvm/java-1.5.0-jamvm/lib /usr/lib/jvm/java-1.5.0-jamvm/jre /usr/lib/jvm/java-1.5.0-jamvm/jre/bin /usr/lib/jvm/java-1.5.0-jamvm/jre/lib ? Rob. Cheers Michael
Re: [cp-patches] FYI: Allow ecj to work via com.sun.tools.javac.Main
Hi Michael, On 10/17/07, Michael Koch [EMAIL PROTECTED] wrote: On Wed, Oct 17, 2007 at 07:14:05PM +0100, Robert Lougher wrote: Something like: /usr/lib/jvm/java-1.5.0-jamvm /usr/lib/jvm/java-1.5.0-jamvm/bin /usr/lib/jvm/java-1.5.0-jamvm/lib /usr/lib/jvm/java-1.5.0-jamvm/jre /usr/lib/jvm/java-1.5.0-jamvm/jre/bin /usr/lib/jvm/java-1.5.0-jamvm/jre/lib In general yes, but this should be all directories with needed links inside, not the directories being symlinked itself. This would make it much more flexible for distros. Yes, of course :) Anybody see any problems with making a symlink from rt.jar to glibj.zip, i.e. /usr/lib/jvm/java-1.5.0-jamvm/lib/rt.jar - /usr/local/classpath/share/classpath/glibj.zip ? Probably a stupid question, but as far as I'm aware (I'm at work and can't look), glibj.zip doesn't have a manifest or index file, but the META-INF directory is optional in the Jar file format... This could be done during install, as long as Classpath was already installed. Thanks, Rob. Cheers, Michael
Re: [cp-patches] FYI: Allow ecj to work via com.sun.tools.javac.Main
Hi Michael, On Wed, Oct 17, 2007 at 07:44:21PM +0100, Robert Lougher wrote: Anybody see any problems with making a symlink from rt.jar to glibj.zip, i.e. /usr/lib/jvm/java-1.5.0-jamvm/lib/rt.jar - /usr/local/classpath/share/classpath/glibj.zip ? Probably a stupid question, but as far as I'm aware (I'm at work and can't look), glibj.zip doesn't have a manifest or index file, but the META-INF directory is optional in the Jar file format... This could be done during install, as long as Classpath was already installed. Yes, I see currently no reason against this. Great! I'll see if I can get this done for the next release (which has been ready for a month, but something always crops up at the last minute!). Thanks, Rob. Cheers, Michael
Re: Issues with rl.jar
Hi, On 10/15/07, Larry Suto [EMAIL PROTECTED] wrote: Hi, I am using gnu-classpath 0.95 with jamvm and the Oracle rl.jar and am getting this error: sh-2.05b# /usr/local/jamvm/bin/jamvm -cp . -jar rl.jar -p RL ***NATIVE LIB OPEN /usr/local/classpath/lib/classpath/libjavanio.so ***NATIVE LIB OPEN /usr/local/classpath/lib/classpath/libjavaio.so ***NATIVE LIB OPEN /usr/local/classpath/lib/classpath/libjavalang.so java.lang.ClassNotFoundException: oracle/rules/rl/session/CommandLine at java.lang.VMClass.forName(Native Method) at java.lang.Class.forName (Class.java:233) at jamvm.java.lang.JarLauncher.main(JarLauncher.java:46) Has anyone verified that gnu-classpath 0.94 works with rl.jar Not that I know of. If I was looking at this, this is what I would do: 1) Try it on Sun's VM, to check that you can rl.jar in the way that you're doing. 2) If that works, unpack the rl.jar file using jar xvf rl.jar 3) Look to see if oracle/rules/rl/session/CommandLine.class exists 4) If if does exist, something strange is going on. 5) If it doesn't, it may be that the manifest file is setting up classpath using a Class-Path header 6) If it is, try adding the contents to the classpath on the jamvm command line. Rob.
Re: Problems bulding classpath 0.93 on ARM5
Hi, On 10/8/07, Christian Thalinger [EMAIL PROTECTED] wrote: On Mon, 2007-10-08 at 01:42 -0700, Larry Suto wrote: Hi I am trying to get classpath .93 compiled for a Marvell ARM5 processor.I can compile in the scratchbox crosscompile environment without any problems...but if copy the classpath files over to the native environmentI get this error from jamvm sh-2.05b# ./gjar Cannot create system class loader Exception occured while printing exception (java/lang/NoClassDefFoundError)... Original exception was java/lang/UnsatisfiedLinkError Can you run JamVM with -verbose:jni to see which native method is failing? - twisti Could you also provide details of how you configured/built JamVM and Classpath? In general, there are two common problems people have when cross-compiling JamVM : 1) They configure JamVM/Classpath on the host to install in one place, and then copy the files to somewhere else on the target. This doesn't work, because JamVM builds at compile time default boot class and library paths based on where it was configured to be installed. By default, JamVM is installed in /usr/local/jamvm, and Classpath /usr/local/classpath. You can change the place using --prefix=xxx when running configure. If you also move Classpath, you need to tell JamVM this by using the --with-classpath-install-dir=xxx configure option (this should be set to the --prefix value you gave to Classpath's configure). You can also override the defaults at runtime, e.g. jamvm -Xbootclasspath:/path/to/JamVMs/classes.zip:/path/to/Classpaths/glibj.zip -Dgnu.classpath.boot.library.path=/path/to/Classpaths/lib/dir ... 2) Copying Classpath onto a fat/vfat formatted device. When Classpath is built, libtool creates library names with version numbers in them, and creates symbolic links for shorter forms (from memory) : libX.so.0.0.0 libX.so.0 - libX.so.0.0 libX.so - libX.so.0 The problem is fat/vfat does not support symbolic links, so the short forms are lost when Classpath is copied onto it. Either: a) For each library in .../classpath/llib/classpath rename libX.so.0.0.0 to libX.so or, b) Use tar and the -h option to follow the sybolic links. However, this will create 3 versions of each library when you unpack, so you should delete the libX.so.0, and libX.so.0.0 versions. Hope this helps, Rob.
Re: Problems bulding classpath 0.93 on ARM5
Hi Larry,
On 10/8/07, Larry Suto [EMAIL PROTECTED] wrote:
Thanks for the infoI am compiling with the defaults and when I copy the
files over to the target I am placing them in a linux filesystem at the
default locations and then I nfs mount it to the target and the I chroot .
in the mounted directory so it seems like I have the files in the default
location
I tried the override and it seems like it went further:
./jamvm
-Xbootclasspath:/usr/local/jamvm/share/jamvm:/usr/local/classp
ath/share/classpath
-Dgnu.classpath.boot.library.path=/usr/local/classpath/lib/c
lasspath Test
Exception occurred while VM initialising.
java/lang/NoClassDefFoundError: java/lang/Thread
No, java.lang.Thread is the first class JamVM attempts to load, so
it's failed almost immediately. It looks like you've specified the
bootclasspath wrong... Have a look in /usr/local/jamvm/share/jamvm
and /usr/local/classpath/share/classpath. The classes should be in
classes.zip and glibj.zip. This needs to be specified (i.e.
-Xbootclasspath:/usr/local/jamvm/share/jamvm/classes.zip:/usr/local/classpath/share/classpath/glibj.zip).
But this is irrelevant. By using chroot the classes should look like
they're in the right place anyway.
My guess would be that JamVM is finding the library correctly, but a
dependency is failing, so the dlopen fails. You'll need to add a
debug printf to discover the cause.
In jamvm/src/os/linux/os.c
change:
void *nativeLibOpen(char *path) {
return dlopen(path, RTLD_LAZY);
}
to
void *nativeLibOpen(char *path) {
void *ret;
printf( NATIVE LIB OPEN %s\n, path);
ret = dlopen(path, RTLD_LAZY);
if(ret == NULL)
printf(DLOPEN FAILED %s\n, dlerror());
return ret;
}
Also, when running the test, please add -verbose -verbose:jni this
will indicate whether JamVM is finding the boot classes, and what JNI
methods it's trying to call.
Rob.
for jamvm I use ./configure
for classpath I use ./configure --with-jikes --enable-jni --disable-gtk-peer
--disable-gconf-peer --disable-plugin
On 10/8/07, Robert Lougher [EMAIL PROTECTED] wrote:
Hi,
On 10/8/07, Christian Thalinger [EMAIL PROTECTED] wrote:
On Mon, 2007-10-08 at 01:42 -0700, Larry Suto wrote:
Hi I am trying to get classpath .93 compiled for a Marvell ARM5
processor.I can compile in the scratchbox crosscompile environment
without any problems...but if copy the classpath files over to the
native environmentI get this error from jamvm
sh-2.05b# ./gjar
Cannot create system class loader
Exception occured while printing exception
(java/lang/NoClassDefFoundError)...
Original exception was java/lang/UnsatisfiedLinkError
Can you run JamVM with -verbose:jni to see which native method is
failing?
- twisti
Could you also provide details of how you configured/built JamVM and
Classpath?
In general, there are two common problems people have when
cross-compiling JamVM :
1) They configure JamVM/Classpath on the host to install in one place,
and then copy the files to somewhere else on the target. This doesn't
work, because JamVM builds at compile time default boot class and
library paths based on where it was configured to be installed.
By default, JamVM is installed in /usr/local/jamvm, and Classpath
/usr/local/classpath. You can change the place using --prefix=xxx
when running configure. If you also move Classpath, you need to tell
JamVM this by using the --with-classpath-install-dir=xxx
configure
option (this should be set to the --prefix value you gave to
Classpath's configure).
You can also override the defaults at runtime, e.g.
jamvm
-Xbootclasspath:/path/to/JamVMs/classes.zip:/path/to/Classpaths/glibj.zip
-Dgnu.classpath.boot.library.path=/path/to/Classpaths/lib/dir
...
2) Copying Classpath onto a fat/vfat formatted device.
When Classpath is built, libtool creates library names with version
numbers in them, and creates symbolic links for shorter forms (from
memory) :
libX.so.0.0.0
libX.so.0 - libX.so.0.0
libX.so - libX.so.0
The problem is fat/vfat does not support symbolic links, so the short
forms are lost when Classpath is copied onto it.
Either:
a) For each library in .../classpath/llib/classpath rename
libX.so.0.0.0 to libX.so
or,
b) Use tar and the -h option to follow the sybolic links. However,
this will create 3 versions of each library when you unpack, so you
should delete the libX.so.0, and libX.so.0.0 versions.
Hope this helps,
Rob.
Re: fdlibm patch
On 9/27/07, Christian Thalinger [EMAIL PROTECTED] wrote: On Thu, 2007-09-27 at 19:26 +0200, Robert Schuster wrote: Hi, the OE guys still keep this little patch. Does anyone know if it is correct and should be applied? On ARM, soft floating point and the VFP coprocessor use pure endian doubles rather than the original mixed endian doubles. The comment implies __VFP_FP__ should be defined when __SOFTFP__ is defined. However, the change implies the comment is wrong because it's unlikely it would have been changed for the hell of it. I'd be inclined to play on the safe side and check for either. This is what I do in similar places in JamVM : #if defined(__VFP_FP__) || defined(__SOFTFP__) Rob. Hmm, maybe Michael knows... --- classpath/native/fdlibm/ieeefp.h.orig 2006-04-14 22:33:09.0 -0400 +++ classpath/native/fdlibm/ieeefp.h2006-04-14 22:41:46.0 -0400 @@ -13,7 +13,7 @@ byte ordering was big or little endian depending upon the target. Modern floating-point formats are naturally ordered; in this case __VFP_FP__ will be defined, even if soft-float. */ -#ifdef __VFP_FP__ +#ifdef __SOFTFP__ #ifdef __ARMEL__ #define __IEEE_LITTLE_ENDIAN #else - twisti
Re: Name Service Crashes on ARM-Linux
Hi, JamVM uses its own optimised routines for handling the calling convention on ARM (os/linux/arm/callNative.S). This was written back in 2003. From browsing, it appears that a new ARM calling convention is gainining ground called EABI (E for embedded). This is substantially different, and requires the stack and doubleword quantities to be 8-byte aligned (stacked, and within even-numbered registers). I haven't been able to find a definate answer whether the gumstix is configured to use EABI. Assuming your ARM cross-compiler is called arm-linux-gcc, do: arm-linux-gcc -E -dM - /dev/null This will show all the predefined macros. If it's configured to use EABI, there should be __ARM_EABI__ somewhere in that. If it is, you will have to use libffi. This library provides a standard generic way for handling calling conventions. It can be used with JamVM by adding --enable-ffi to the configure line. This will configure JamVM to use libffi instead of its own routines. Most other VMs rely on libffi for calling native methods so JamVM wouldn't be odd in requiring it. JamVM, however, provided its own routines as an optimisation. Depending on how much time I have over the next week I will investigate writing a new set of routines to handle EABI. Rob. On 8/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Quoting Audrius Meskauskas [EMAIL PROTECTED]: Adam Smola wrote: # java gnu.classpath.tools.giop.NameService Error: Please use --help for options. Alignment trap: not handling instruction ececa102 at [4008bde8] Unhandled fault: alignment exception (0x813) at 0xbea8bff4 That is not a java error. Java code would print the stack trace on failure. This seems a native code problem. Some ideas for the original poster. (1) execute jamvm with -verbose option (might be able to see what jamvm is trying to do when error occurs) (2) recompile jamvm with debug options in jamvm.mk, in particular there is an option --debug-dll iirc. (3) build strace and run jamvm within strace (extremely verbose output, might give some useful info at the point of failure) HTH Robert Dodier
Re: [Jamvm-general] LocaleInformation not found, Classpath 0.95 + JamVM 1.4.5
Hi Robert, Have you a simple testcase which can reproduce this? If you have, I'll have a look at it. BTW, I remember implementing stuff in the VM to get resources from the boot class loader, so resource loading is probably using a different path when you use -Xbootclasspath/p:/tmp... Rob. On 8/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Andrew, Thanks for your reply. I don't have a stack trace, but I have determined that the problem originates from ResourceBundle.tryBundle(String, ClassLoader) which returns null instead of locating resources within glibj.zip. Due to that various exceptions are thrown later (e.g. date, number, and currency formats are messed up). tryBundle first tries to load LocaleInformation_foo as a class. That must fail because glibj.zip contains .properties files for locale information, not classes. Then tryBundle tries to find the corresponding .property file, but it is not found then tryBundle returns null. As a workaround, I have found tryBundle can find the locale information by (1) unpacking the resources directory from glibj.zip into, say, /tmp, and (2) calling JamVM with -Xbootclasspath/p:/tmp . (I unpacked all of the resources directory; there are other resources aside from locale information which need to be located, otherwise exceptions are thrown.) So it appears that the problem is related to locating properties files (maybe all non-class files? dunno) within glibj.zip. Incidentally the glibj.zip I am using was created by unpacking glibj.zip as created by make, erasing the swing directories, and repacking glibj.zip via fastjar, the same program used by make to create the original. I am working on a device with limited memory, and saving the 1 M or so which swing occupies is important. Yes, I did set --without-x and disabled various graphics related options in classpath.mk. Thanks for any information anyone has about this problem. Robert Dodier - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Jamvm-general mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jamvm-general
Re: Name Service Crashes on ARM-Linux
Hi, Can you run with -verbose:jni? This will show resolution of native methods. I suspect that it is crashing when it calls a native method within Classpath. There maybe something odd happening with the networking code on the Gumstix, but I also faintly recall reading something about issues with loading shared libraries on the Gumstix. I'll do a google and see if it turns anything up. Rob. On 8/14/07, Adam Smola [EMAIL PROTECTED] wrote: Hello All, I am trying to get the Classptah Name Service Running on a Gumstix Computer (ARM-Linux). I am using Classpath 0.90 JamVM 1.4.2. Commands/errors are as follows: Command: # java gnu.classpath.tools.giop.NameService Error: Please use --help for options. Alignment trap: not handling instruction ececa102 at [4008bde8] Unhandled fault: alignment exception (0x813) at 0xbea8bff4 Illegal instruction If I run JamVM in verbose mode I am seeing a bunch of linking and loading and it is crashing out when it goes to link/load java/net/Inet/SocketAddress: [Linking class java/net/InetSocketAddress] Illegal instruction Any ideas? -Adam
Re: J2SE compliant RE for Arm Linux
Hi, Park and unpark are empty stubs, but everything else should be implemented... If anybody can tell me what park/unpark should do, I'll implement them too! Rob. On 6/27/07, Christian Thalinger [EMAIL PROTECTED] wrote: On Wed, 2007-06-27 at 12:47 +0200, Christian Thalinger wrote: java.lang.UnsatisfiedLinkError: putObject I'll implement the missing sun.misc.Unsafe functions and get back to you. Hi! I've implemented putObject and park (only an empty stub, like jamvm). If more is missing, let me know. - twisti
Re: [SPAM?] Re: gnu classpath with sun java vm
Hi Michel, It's obvious from the output below that you haven't just done ./configure ! Could you give the options you gave, or better still send me (and not the list) your config.log? From the looks of it, you've disabled use of libffi (on by default on AMD64). This is needed for calling native methods, and without this you will get the missing symbols below. Rob. On 4/26/07, Michel Brabants [EMAIL PROTECTED] wrote: Hello all, it took a while, but here is my compile-error (using gcc 4.1.2): config.status: creating lib/sun/Makefile config.status: creating lib/gnu/classpath/Makefile config.status: creating src/config.h config.status: src/config.h is unchanged config.status: linking ./src/arch/x86_64.h to src/arch.h config.status: executing depfiles commands Making all in src make[1]: Entering directory `/home/michel/archlinux-packages/jamvm/src/jamvm-1.4.5/src' make all-recursive make[2]: Entering directory `/home/michel/archlinux-packages/jamvm/src/jamvm-1.4.5/src' Making all in os make[3]: Entering directory `/home/michel/archlinux-packages/jamvm/src/jamvm-1.4.5/src/os' Making all in linux make[4]: Entering directory `/home/michel/archlinux-packages/jamvm/src/jamvm-1.4.5/src/os/linux' Making all in x86_64 make[5]: Entering directory `/home/michel/archlinux-packages/jamvm/src/jamvm-1.4.5/src/os/linux/x86_64' make[5]: Nothing to be done for `all'. make[5]: Leaving directory `/home/michel/archlinux-packages/jamvm/src/jamvm-1.4.5/src/os/linux/x86_64' make[5]: Entering directory `/home/michel/archlinux-packages/jamvm/src/jamvm-1.4.5/src/os/linux' make[5]: Nothing to be done for `all-am'. make[5]: Leaving directory `/home/michel/archlinux-packages/jamvm/src/jamvm-1.4.5/src/os/linux' make[4]: Leaving directory `/home/michel/archlinux-packages/jamvm/src/jamvm-1.4.5/src/os/linux' make[4]: Entering directory `/home/michel/archlinux-packages/jamvm/src/jamvm-1.4.5/src/os' make[4]: Nothing to be done for `all-am'. make[4]: Leaving directory `/home/michel/archlinux-packages/jamvm/src/jamvm-1.4.5/src/os' make[3]: Leaving directory `/home/michel/archlinux-packages/jamvm/src/jamvm-1.4.5/src/os' make[3]: Entering directory `/home/michel/archlinux-packages/jamvm/src/jamvm-1.4.5/src' /bin/sh ../libtool --tag=CC --mode=link gcc -march=x86-64 -Os -pipe -m3dnow -ftree-vectorize -o jamvm jam.o libcore.la -lffi -lz -ldl -lm -lpthread gcc -march=x86-64 -Os -pipe -m3dnow -ftree-vectorize -o jamvm jam.o ./.libs/libcore.a -lffi -lz -ldl -lm -lpthread ./.libs/libcore.a(dll.o): In function `callJNIWrapper': dll.c:(.text+0x6b): undefined reference to `callJNIMethod' ./.libs/libcore.a(dll.o): In function `lookupLoadedDlls': dll.c:(.text+0x840): undefined reference to `nativeExtraArg' collect2: ld returned 1 exit status make[3]: *** [jamvm] Error 1 make[3]: Leaving directory `/home/michel/archlinux-packages/jamvm/src/jamvm-1.4.5/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/michel/archlinux-packages/jamvm/src/jamvm-1.4.5/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/michel/archlinux-packages/jamvm/src/jamvm-1.4.5/src' make: *** [all-recursive] Error 1 == ERROR: Build Failed. Aborting... Thank you and greetings, Michel Op Friday 20 April 2007, schreef [EMAIL PROTECTED]: Hello all, I'll try to show you the compile-error with jamvm. I just wanted to get it working ... and hoped it worked with sun's vm, which I already had installed. I'll also list the resourc-bundle-error. Maybe I4ll try the cacoa-vm. Thank you and greetings, Michel [EMAIL PROTECTED] wrote: Hello, I compiled the latest stable gnu classpath with as vm, the java-vm from Sun, because I'm getting a compile-error trying to compile the latest jamvm. I'm using an x86-64-machine. What compile errors do you get with Jamvm? Thanks Phillip
Re: gnu classpath with sun java vm
Hi, BTW, what was the compile-error with JamVM? Rob. On 4/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, I compiled the latest stable gnu classpath with as vm, the java-vm from Sun, because I'm getting a compile-error trying to compile the latest jamvm. I'm using an x86-64-machine. When trying to start gappletviewer, I get a missing resource-bundle-error. Now, I saw that the resource-bundles are inside glibj.zip. I added this zip-file to the Xbootclasspath-parameter of the gappletviewer, but then I get a stackoverflow-error. Is there any way I can get the applet-support to work with the java-vm from Sun? Thank you and greetings, Michel
Re: Method.invoke() on a non-public class from another package
Hi Mark, On 4/8/07, Mark Wielaard [EMAIL PROTECTED] wrote: On Sun, 2007-04-08 at 12:53 +0200, Christian Thalinger wrote: Grrr, I hate this access checks. I'll try to fix that _again_. This seems to be pretty subtle and we found multiple runtimes (jamvm, cacao, gcj and kaffe at least) that seem to get this wrong. ... So when Method.invoke() is called on an method member of an object which class type isn't public then it should only be allowed to successfully call the method if the caller is in the same package. Strangely enough, I _did_ fix this in JamVM 1.4.4, but then removed the checks again in JamVM 1.4.5! http://cvs.berlios.de/cgi-bin/viewcvs.cgi/jamvm/jamvm/src/reflect.c.diff?r1=1.9r2=1.10 If I remember the reason for removing it again was that it broke some stuff. I had a quick look at cacao and gcj, and found they didn't do the check, and not having the time at that point to look into it properly just backed the change out. I'll see if I can find what broke. Thanks, Rob. P.S. The extra checks also checked class access for reflection access to fields in addition to methods... Cheers, Mark
Re: Method.invoke() on a non-public class from another package
Hi, On 4/8/07, Robert Lougher [EMAIL PROTECTED] wrote: Hi Mark, On 4/8/07, Mark Wielaard [EMAIL PROTECTED] wrote: On Sun, 2007-04-08 at 12:53 +0200, Christian Thalinger wrote: Grrr, I hate this access checks. I'll try to fix that _again_. This seems to be pretty subtle and we found multiple runtimes (jamvm, cacao, gcj and kaffe at least) that seem to get this wrong. ... So when Method.invoke() is called on an method member of an object which class type isn't public then it should only be allowed to successfully call the method if the caller is in the same package. Strangely enough, I _did_ fix this in JamVM 1.4.4, but then removed the checks again in JamVM 1.4.5! http://cvs.berlios.de/cgi-bin/viewcvs.cgi/jamvm/jamvm/src/reflect.c.diff?r1=1.9r2=1.10 If I remember the reason for removing it again was that it broke some stuff. I had a quick look at cacao and gcj, and found they didn't do the check, and not having the time at that point to look into it properly just backed the change out. I'll see if I can find what broke. Yes, answering my own post :) Anyway, I've found what it broke and my original analysis. After putting this in, BeanShell GUI stopped working with JamVM. This was found during 0.93 testing: http://www.mail-archive.com/classpath@gnu.org/msg13811.html I did an original analysis, where I tracked it down to the extra reflection checks. Of course, I could have been wrong, and I've not rechecked this. At the time I just decided to remove the checks... Date: Thu, 7 Dec 2006 02:16:44 + From: Robert Lougher [EMAIL PROTECTED] To: Mark Wielaard [EMAIL PROTECTED] Subject: Re: Re: 0.93 branch created In-Reply-To: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_Part_25035_17595680.1165457804811 References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] --=_Part_25035_17595680.1165457804811 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Mark, I've spent some time looking at this. From what I can see, there's an attempt to invoke via reflection the method getValue on an Object of type java.util.Hashtable$HashEntry. The invoke is from class bsh.Reflect. The method getValue is defined in class java.util.AbstractMap$BasicMapEntry. The problem is that although method getValue is public, the class java.util.AbstractMap$BasicMapEntry is package-private. When JamVM does a method invoke, it checks that the class that defined the method is accessible, and given that, that the method is also accessible. The class access check fails, and an IllegalAccessException is thrown, which is converted to the UndeclaredThrowableException. The reason that Cacao works is that its reflection code does not do the class access check. If I remove the class access check in JamVM the UndeclaredThrowableException no longer gets thrown. The reason I put the class access check in is to fix some reflection tests. The attached simple reflection test throws an IllegalAccessException on both JamVM and Suns VM (to run do jamvm/java test). If I remove the class access check, the method invoke wrongly succeeds. I don't know where the problem lies. The class java.util.Hashtable$HashEntry is private, so I don't know if bsh.Reflect should have a reference anyway. Anyway, I can't do any more investigation tonight, as it's late! Thanks, Rob.
Re: Method.invoke() on a non-public class from another package
Hi Twisti, On 4/8/07, Christian Thalinger [EMAIL PROTECTED] wrote: On Sun, 2007-04-08 at 23:00 +0100, Robert Lougher wrote: Anyway, I've found what it broke and my original analysis. After putting this in, BeanShell GUI stopped working with JamVM. This was found during 0.93 testing: http://www.mail-archive.com/classpath@gnu.org/msg13811.html I did an original analysis, where I tracked it down to the extra reflection checks. Of course, I could have been wrong, and I've not rechecked this. At the time I just decided to remove the checks... Hmm, I don't get an exception with that when I revert my cacao patch... Still searching for my bugger. Did you test with the 0.95 branch? I've retested with the patch reverted (on JamVM) and Classpath-0.93. The exception occurs as before with both bsh-1.3.0 and bsh-2.0b2. However, it doesn't occur with Classpath CVS HEAD... Rob. - twisti
Re: Method.invoke() on a non-public class from another package
Hi Andrew, On 4/8/07, Andrew Haley [EMAIL PROTECTED] wrote: Robert Lougher writes: Anyway, I've found what it broke and my original analysis. After putting this in, BeanShell GUI stopped working with JamVM. This was found during 0.93 testing: ... I don't know where the problem lies. The class java.util.Hashtable$HashEntry is private, so I don't know if bsh.Reflect should have a reference anyway. Can you try this again, but with bsh 2.0 ? I've been having a lot of problems with bsh, all of which went away when I upgraded to 2.0. I can't be certain without knowing exactly what's changed, but it looks like the problem has been fixed somewhere between Classpath-0.93 and now. With the extra reflection checks, Classpath CVS HEAD works with both bsh 1.3.0 and 2.0(b2), but both throw the exception with Classpath-0.93... Thanks, Rob. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
Re: Method.invoke() on a non-public class from another package
Hi, On 4/9/07, Robert Lougher [EMAIL PROTECTED] wrote: Hi Andrew, On 4/8/07, Andrew Haley [EMAIL PROTECTED] wrote: Robert Lougher writes: Anyway, I've found what it broke and my original analysis. After putting this in, BeanShell GUI stopped working with JamVM. This was found during 0.93 testing: ... I don't know where the problem lies. The class java.util.Hashtable$HashEntry is private, so I don't know if bsh.Reflect should have a reference anyway. Can you try this again, but with bsh 2.0 ? I've been having a lot of problems with bsh, all of which went away when I upgraded to 2.0. I can't be certain without knowing exactly what's changed, but it looks like the problem has been fixed somewhere between Classpath-0.93 and now. With the extra reflection checks, Classpath CVS HEAD works with both bsh 1.3.0 and 2.0(b2), but both throw the exception with Classpath-0.93... Had a quick look, and in Classpath-0.93 java.util.AbstractMap contains a class BasicMapEntry which implements getValue(). BasicMapEntry is package-private. This isn't accessible outside the package. In CVS HEAD, this has changed and java.util.AbstractMap contains a class SimpleEntry which implements getValue(). SimpleEntry is public. Obviously, this is accessible... Rob. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
JamVM 1.4.5 released
Hi, I'm pleased to announce the release of JamVM 1.4.5 (http://jamvm.sourceforge.net). This release adds support for Annotations, sun.misc.Unsafe (JSR-166), and a full port to the mipsel architecture. Several other features have also been added and quite a few bugs fixed. The full list of changes are here: http://sourceforge.net/project/shownotes.php?release_id=483964 The release will also be mirrored on BerliOS in the next few days. Thanks, Rob.
Re: [cp-patches] FYI: Add Enum.finalize()
Hi, FYI, JamVM does something similar. All objects effectively have a finalizer because java.lang.Object implements an empty finalizer, so if a VM didn't do something, _all_ objects would need finalization. JamVM therefore records a class as having a finalizer only if it has overridden the one in java.lang.Object. The assumption is that it will only provide it's own finalizer if it actually has something to do, so the code currently doesn't check if it is empty or not. I will add this check. Rob. On 12/21/06, Christian Thalinger [EMAIL PROTECTED] wrote: On Wed, Dec 20, 2006 at 10:28:13AM +0100, Christian Thalinger wrote: On Wed, Dec 20, 2006 at 09:34:29AM +0100, Mark Wielaard wrote: Interesting. Even though Enums should never be initialized by hand this is something a garbage collector should be aware of. Do garbage collectors already handle empty finalize() methods as if there was no finalizer? In CACAO we currently search for a finalizer method and add it if one is found. We don't check if there is actually code in it. But we set the finalizer for java.lang.Object to NULL, which means we actually don't have any finalizers in subclasses. The case, where an empty finalizer is given in a subclass, isn't handled yet. I'll change that. - twisti
java.lang.management.ThreadInfo
Hi, While implementing the ThreadMXBean stuff in JamVM I noticed a couple of problems with the ThreadInfo class. The first constructor will throw NullPointerExceptions if the lock or lockOwner is null (which it will be if the thread isn't blocked), and in several accessors the BLOCKED state check should be negated (in fact, they can be removed, as the values are right anyway). I've attached a patch. Any chance this could be fixed for 0.93? Thanks, Rob. ThreadInfo.java-patch Description: Binary data
Re: Anyone pondering HotSpot+Classpath?
Of course, the reverse is also possible, i.e. open source runtimes working with the JDK class libraries. This doesn't even need the release of the class-library source to happen. The HotSpot source reveals all that is needed to implement the interface. From brief looking at the interface, I would say it would be easier for an open-source runtime to use the JDK class library than for Classpath to use HotSpot. In particular, reflection handling seems to be largely done outside the VM. Rob. On 11/14/06, Sven de Marothy [EMAIL PROTECTED] wrote: Yup, I've been pondering that since they announced their plans. I'd even suggested to Webmink that I'd like to see Hotspot released early for that reason. I wouldn't take credit for the fact - but it seems I got what I asked for. (In fact it seems it's playing out such that I'm getting exactly what I asked for :)) Anyway, yes, I think we defininitely want to get CP working with HotSpot as soon as possible. I also think that we should move to make our VM interfaces compatible as soon as possible. That is, unless it turns out that their VM interface is absolutely horrible. (Or we could chose to support both) /Sven
JamVM 1.4.4 released
Hi, I'm pleased to announce the release of JamVM 1.4.4 (http://jamvm.sourceforge.net). This release adds the JNI Invocation API and additional Java 1.5 support. Several other features have also been added and quite a few bugs fixed. The full list of changes are here: http://sourceforge.net/project/shownotes.php?release_id=460573 The release will also be mirrored on BerliOS this evening. Thanks, Rob.
Build failure on Mac OS X
Hi, I tried building the lastest distcheck on Mac OS X last night (first time in a while). The build trivially failed in two files: native/jni/java-net/gnu_java_net_VMPlainSocketImpl.c native/jni/java-nio/gnu_java_nio_VMChannel.c The type uint32_t is undefined. This is easily fixed by including stdint.h. Thanks, Rob.
Re: Re: [cp-patches] RFC: GtkButtonPeer fix
Any details on how to reproduce it? Is it 100% reproducible? Send some details and I'll have a look at it. Rob. On 10/18/06, Tania Bento [EMAIL PROTECTED] wrote: Hey, Upon further inspection, it turns out that this is a bug in jamvm. Sorry, Tania On Wed, 2006-10-18 at 16:36 -0400, Tania Bento wrote: Hey, This patch fixes a segmentation fault caused when the button's label was null. Can someone kindly comment on or approve this patch? Thanks, Tania 2006-10-18 Tania Bento [EMAIL PROTECTED] *native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkButtonPeer.c: (gtkSetLabel): Prevented a segmentation fault.
Re: Signals, sockets and threads
On 10/18/06, Robert Schuster [EMAIL PROTECTED] wrote:
do
{
ret = cpnio_accept (fd, (struct sockaddr *) addr, alen);
}
while (ret == -1);
if (ret == -1)
{
if (EWOULDBLOCK != tmp_errno EAGAIN != tmp_errno)
JCL_ThrowException (env, java/net/SocketException, strerror
(tmp_errno));
}
return ret;
tmp_errno is an int which is set to 0 in the beginning.
Obvious point. The check at the end of the loop is completely
redundant as you can never exit the loop with ret == -1.
You only want to loop if it was an EINTR but no Java-interrupt.
Currently this code loops for all errors apart from Java-interrupt.
This is wrong. For example it will enter a never-ending loop if
accept returned EBADF, i.e. if the socket had closed for some reason.
A non-blocking socket will also spin while there was no connection
present.
Rob.
Re: Jboss/Java1.5 on HPPA in linux
Hi, On 10/16/06, Trevor Glen [EMAIL PROTECTED] wrote: Tom Tromey wrote: Trevor == Trevor Glen [EMAIL PROTECTED] writes: Trevor Has anyone had any luck with a 1.5 vm and/or classpath on a Trevor hppa linux box? What VM are you using? gcj. jam and cacao don't support hppa and I didn't much luck at all with sable and kaffe (ie, it wouldn't even start). As long as your platform has libffi support (which I guess it must have if it has gcc) a JamVM port consists of simply defining a couple of macros for compare and swap and memory barriers (see src/arch/ e.g. powerpc.h). You'll also need a null platform directory in src/os/linux -- this can be based on the x86_64 one, which is almost empty as the x86_64 port also relies on libffi. If you're willing to test JamVM I should be able to knock up a quick port fairly quickly. The macros required are pretty-standard, so I'll be able to find something to base them on easily. To help do this, can you let me know the output of uname -a? Perhaps also the contents of /proc/cpuinfo. Also, do you know if hppa is little or big-endian? Thanks, Rob. Cheers, Trev -- Trevor Glen Sarugo Pty Ltd Email: [EMAIL PROTECTED] Web: http://www.sarugo.net/
Re: native methods in inner classes (long)
Hi, On 9/20/06, Jeroen Frijters [EMAIL PROTECTED] wrote: Raif S. Naffah wrote: 1. do VMs handle differently native method names depending on whether they are defined in an inner class or not? No, at the VM and JNI level there is no difference between inner and outer classes. It is simply a matter of name mangling, which is fully defined in the JNI specification. It really is kind of embarassing that we've all had the same bugs in this ;-) Yes, it is embarassing, especially as I thought I'd implemented that part of the JNI spec pretty well :) Looking at it again shows it specifically mentions handling of underscore (_), semi-colon, open bracket ([) and forward-slash, and the escape sequence for general unicode characters. It doesn't explicitly state the need to handle $, which is probably why we all missed it... Anyway, I'll check a patch in for JamVM tonight. Thanks, Rob. Regards, Jeroen [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6257087
Re: Re: native methods in inner classes (long)
On 9/20/06, Robert Lougher [EMAIL PROTECTED] wrote: Anyway, I'll check a patch in for JamVM tonight. Committed... Rob.
Re: Re: [cp-patches] RFC: PR Classpath/28664 - GNU MP based BigInteger (compressed)
Hi, Try commenting out the code in the function: setDoublePrecision() located in jamvm/src/os/linux/i386/init.c This changes the precision of the FPU to 64 bits from extended 80-bit precision which is the Linux default. This is necessary to completely conform to the Java specification. See http://www.vinc17.org/research/extended.en.html for a bug report on various OS VMs. GMP appears to be very sensitive to the compiler used. I would guess it would also produce wrong results if the processor mode was changed. Perhaps cacao does not do this. Can you also try the test given in the above page? Thanks, Rob. On 9/3/06, Raif S. Naffah [EMAIL PROTECTED] wrote: hello Robert, On Sunday 03 September 2006 15:26, Robert Lougher wrote: Hi, What architecture were you running JamVM on? here is the uname related lines in my jamvm config.log: uname -m = i686 uname -r = 2.6.17-1.2174_FC5smp uname -s = Linux uname -v = #1 SMP Tue Aug 8 16:00:39 EDT 2006 cheers; rsn
Re: [cp-patches] RFC: PR Classpath/28664 - GNU MP based BigInteger (compressed)
Hi, What architecture were you running JamVM on? Rob. On 9/3/06, Raif S. Naffah [EMAIL PROTECTED] wrote: hello all, the attached patch adds support for GNU MP in BigInteger if/when configured. 2006-09-03 Raif S. Naffah [EMAIL PROTECTED] PR Classpath/28664 * INSTALL: Added documentation about GNU MP. * configure.ac: Add support for configuring GNU MP. * native/jni/Makefile.am: Include java-math directory if required. * native/jni/java_math/.cvsignore: New file. * native/jni/java_math/Makefile.am: Likewise. * native/jni/java_math/java_math_BigInteger.c: Likewise. * native/jni/java_math: New folder. * include/java_math_BigInteger.h: New file. * java/math/BigInteger.java: Added support for native methods. * gnu/classpath/Configuration.java.in (WANT_NATIVE_BIG_INTEGER): New field. this was tested with current CVS head and cacao trunk (updated to revision 5285). Mauve tests for BigInteger, and crypto classes (gnu.testlet.java.security and gnu.testlet.javax.crypto) all pass with cacao but systematically, almost half of them, fail with jamvm (latest CVS head). a couple of more Mauve tests will be added soon, and another couple will be updated. Mark, would you be kind as to have a look at this before i commit? finally, thanks for Mark and Dalibor for their help and advice. cheers; rsn
Re: Running JOnAS 4.7.4 that uses 1.5 features
Hi, On 8/9/06, Gary Benson [EMAIL PROTECTED] wrote: Audrius Meskauskas wrote: JOnAS also failed to load the JacORB CORBA implementation via our org.omg classes. Despite our ObjectCreator.forName searches the thread context class loader and then walks through the stack, trying the class loader of every class there, the jacorb.jar is still missing in the path of all tried loaders (I have checked with the .toString() method of our class loader - is lists all files in the path). I have no idea from where the JacORB classes should be loaded (the jacorb.jar itself is present in JOnAS distribution). I think I hit something similar in the never-released Fedora JOnAS: I had to write a little a hack to ram jacorb.jar onto the classpath. I suspect we're missing something in the way we deal with endorsed classes. Cheers, Gary Can you check JOnAS's startup scripts to see whether it is setting java.endorsed.dirs on the command line passed to the VM? If it is, the contents of the directory (or directories) should be added to the bootclasspath, and loaded via the boot loader. However, as Christian pointed out last week, JamVM 1.4.3 doesn't support java.endorsed.dirs. This is now fixed, and is available from anonymous CVS (jamvm.berlios.de). Instructions are here: http://developer.berlios.de/cvs/?group_id=6545 The modulename is jamvm. Thanks, Rob.
Re: jboss-4.0.4
Hi Twisti, On 7/31/06, Christian Thalinger [EMAIL PROTECTED] wrote: On Mon, 2006-07-31 at 13:55 +0200, Stephan Michels wrote: I don't know if it is related to your problem, but the too many open files thing reminds me of this bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25760 Ahh, I can remember that bug. Hmm, probably. Hard to tell, as CACAO does not have class GC and I can't run jboss with jamvm. Does any other VM have class GC? I've never tried to run JBoss with JamVM. Can you give a quick summary of what you're trying to run so that I can have a go myself? Remember, I know _nothing_ about JBoss! Thanks, Rob. TWISTI
Re: jboss-4.0.4
Hi Twisti, On 7/31/06, Christian Thalinger [EMAIL PROTECTED] wrote: On Mon, 2006-07-31 at 13:50 +0100, Robert Lougher wrote: I've never tried to run JBoss with JamVM. Can you give a quick summary of what you're trying to run so that I can have a go myself? Remember, I know _nothing_ about JBoss! Who does :-) Well, just download the latest release (4.0.4.GA), unpack it, change to jboss-4.0.4.GA/bin and run it like: $ JAVA_HOME=/home/twisti/tmp/jamvm ./run.sh I set up myself a little fakejdk in /home/twisti/tmp/jamvm, means, I made a java symlink to jamvm. That's it. Thanks a lot. I've downloaded it and I'll try tonight... Rob. TWISTI
Re: jboss-4.0.4
Hi, No, but it doesn't look difficult to implement. If I understand it correctly it seems to be as simple as just prepending the value of java.endorsed.dirs to the bootpath? Rob. On 7/31/06, Christian Thalinger [EMAIL PROTECTED] wrote: On Mon, 2006-07-31 at 14:06 +0200, Christian Thalinger wrote: Ahh, I can remember that bug. Hmm, probably. Hard to tell, as CACAO does not have class GC and I can't run jboss with jamvm. Does any other VM have class GC? The bug showed with jamvm is already in bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27710 I suspect it's something with endorsed dirs. Robert, does jamvm support that? I guess not... No, but it doesn't look difficult to implement. If I understand it correctly it seems to be as simple as just prepending the value of java.endorsed.dirs to the bootpath? Hopefully it should be available in CVS soon... Thanks, Rob. TWISTI
Re: jboss-4.0.4
On 7/31/06, Robert Lougher [EMAIL PROTECTED] wrote: On 7/31/06, Christian Thalinger [EMAIL PROTECTED] wrote: On Mon, 2006-07-31 at 19:04 +0100, Robert Lougher wrote: No, but it doesn't look difficult to implement. If I understand it correctly it seems to be as simple as just prepending the value of java.endorsed.dirs to the bootpath? Well, nearly. You have to scan the directories, if any, for zip/jar files and prepend them too. Yes. I realised that each dir will contain potentially many jars, and that these are what must be prepended just after I posted. Sods law! I guess you do this in cacao and this is what lets you start up jboss. Sorry to keep on spamming, but do you look in a default location if java.endorsed.dirs is unset? The RI does, but this assumes you've got a JRE-like directory structure. Time to put jamvm into it's own directory... Rob. Thanks, Rob. TWISTI
Re: jboss-4.0.4
On 7/31/06, Christian Thalinger [EMAIL PROTECTED] wrote: On Mon, 2006-07-31 at 19:04 +0100, Robert Lougher wrote: No, but it doesn't look difficult to implement. If I understand it correctly it seems to be as simple as just prepending the value of java.endorsed.dirs to the bootpath? Well, nearly. You have to scan the directories, if any, for zip/jar files and prepend them too. Yes. I realised that each dir will contain potentially many jars, and that these are what must be prepended just after I posted. Sods law! I guess you do this in cacao and this is what lets you start up jboss. Thanks, Rob. TWISTI
Re: Hello:Interested in classpath
Hi David, Let me know if you any questions regarding the packaging of JamVM. I'll be pleased to help as this is something that's needed doing for a while... Rob. On 7/18/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Dalibor, Christian, Andrew, Thanks for pointing out the wiki! I will try out gcj and CACAO after I am done with JamVM ;) David Fu. On Mon, Jul 17, 2006 at 10:55:20AM +0900, [EMAIL PROTECTED] wrote: Hi Christian, Dalibor, sandbox.nihonsoft.org is a standard i386(32-bit) machine. There is no problem with running firecat with Kaffe, except the slow execution speed. SableVM has some sort of problem with the chaining of classloaders, and the server socket dies after a few minutes. I think these problems are specific to the VM, and not GNU Classpath. I have tried JamVM a bit, and it seems to be ok too(except the way it is packaged is not like a JDK). I think while some problems are trivial, others are not. But overall we are getting closer to being able to use Free Runtimes in production;) David Fu. Cool, thanks for the update. You could also try using gcj to natively compile firecat. See http://gcc.gnu.org/wiki/How%20to%20BC%20compile%20with%20GCJ for details. Don't forget to pass gcj -O3 for the best effect. :) cheers, dalibor topic On Sun, 2006-07-16 at 09:33 +0900, [EMAIL PROTECTED] wrote: Hi Mark, firecat runs on Kaffe 1.1.7(GNU Classpath 0.90) with no problems, except for performance(I tried to use it for running sandbox.nihonsoft.org, but it turned out to be too slow.). SableVM was ok, but due to changes in firecat's classloading structure, it does not work anymore. I am planning to get JamVM working for the next release(probably need to change the startup script, and create some wrappers to make JamVM look like a JDK). What architecture is sandbox.nihonsoft.org? I wonder why SableVM was ok, but not kaffe. TWISTI
Re: diffie-hellman problem
Hi, On 6/28/06, Christian Thalinger [EMAIL PROTECTED] wrote: On Tue, 2006-06-27 at 21:27 +1000, Raif S. Naffah wrote: found the problem; should be able to check-in a fix within the next 48h. Very cool! Thanks for the quick fix. Does this Sun demo now work for you? It does not throw the exception anymore, but it hangs here with 0% cpu: snip Shared secrets are the same Return shared secret as SecretKey object ... DES in ECB mode recovered text is same as cleartext DES in CBC mode recovered text is same as cleartext jamvm crashes on my x86_64, so I don't know if that's a cacao bug. Any chance you could provide some details? Thanks, Rob. TWISTI
Re: JamVM 1.4.3 released
Hi Mark, On 5/30/06, Mark Wielaard [EMAIL PROTECTED] wrote: Hi Robert, On Mon, 2006-05-22 at 03:47 +0100, Robert Lougher wrote: I'm pleased to announce the release of JamVM 1.4.3 (http://jamvm.sourceforge.net). This release adds heap compaction Nice one! I was just going through a classpath bootstrap with eclipse (http://developer.classpath.org/mediation/ClasspathHackingWithEclipse) and suddenly realized that memory usage stayed constant even though I had just installed the CDT through the update manager and did a full checkout and build of classpath. Previous jamvm releases often required me to shutdown and restart eclipse in between, but this release happily lets me go on with hacking. Thanks for the positive feedback! My tests show that JamVM should now need less heap (in some cases much less memory, i.e. 3x less). In particular, JamVM should now be able to run some applications which used to run out of memory (e.g. gjdoc). I'd be really interested to hear if some people are now able to do things which they previously couldn't. Thanks, Rob. Thanks! Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEfH3lxVhZCJWr9QwRAj6FAJ4iUret9vjhJUq5CckQ9E4ocpLa6QCfUpbc IEqMR83XkTcpXIgoB//eSjU= =O1nA -END PGP SIGNATURE-
Re: [Jamvm-general] Javavm segmentation fault
Hi Dikran, No, it is not possible to use JamVM with the class library provided with Blackdown Java (a port of Suns VM). This is because some classes (such as Object and Thread) are tightly integrated with the VM. JamVM isn't compatible with the Blackdown versions, and as they're not open source I am not able (nor do I have any wish to) make JamVM work with them... Regarding your second question, I'm not really familiar with javax.imageio. I'm therefore CC'ing this message to the Classpath mailing list in the hope that someone will pick up on it there... Rob. On 5/25/06, Dikran Hovagimian [EMAIL PROTECTED] wrote: Hi Rob, I am not sure who to turn to with the following problem. I am trying to use JamVM in an AWT environment. It seems that I have to put a lot of runtime files. I installed gnu-classpath 0.91 and all the required gtk libs. Now, javax.imageio is failing on reading a PNG image. I added the imagemagick libraries but that did not help either. I have 2 questions: 1) Is it possible to use JamVM as a replacement for blackdown jvm while keeping everything else? 2) How can one use JamVM to in an AWT environment and use javax.imageio with it? Please direct me to the proper place/person if I am bothering you too much. Thanks in advance, Dikran Hovagimian - Original Message - From: Robert Lougher [EMAIL PROTECTED] To: Dikran Hovagimian [EMAIL PROTECTED] Cc: JamVM Hackers [EMAIL PROTECTED] Sent: Tuesday, May 23, 2006 12:01 AM Subject: Re: [Jamvm-general] Javavm segmentation fault Hi, Have you tried JamVM 1.4.3 which was released late Sunday night? If this still crashes I will need to investigate it. If you have gdb, do: script gdb jamvm (in gdb) handle SIGUSR1 nostop pass print run -verbosegc -verbose classname output... CRASH? get a backtrace bt quit ^D send the typescript file to me... Rob. On 5/23/06, Dikran Hovagimian [EMAIL PROTECTED] wrote: Hi Rob, Any news as to why I am seeing a crash? Could it be a simple compilation error on my part? I really want to try JamVM but I can't run it. Thanks, Dikran Hovagimian - Original Message - From: Robert Lougher [EMAIL PROTECTED] To: Dikran Hovagimian [EMAIL PROTECTED] Sent: Sunday, May 21, 2006 6:18 AM Subject: Re: [Jamvm-general] Javavm segmentation fault Hi, Thanks for the report. Can you provide some details of your environment, i.e. operating system, processor, gcc version, etc.? Also did you give any options to configure? Rob. On 5/21/06, Dikran Hovagimian [EMAIL PROTECTED] wrote: I just started using javavm. I started from scratch and compiled javavm 1.4.2 and classpath (tried 0.20 0.90). When I run javavm I get the following segmentation fault. javavm -verbose MyClass [Loaded java/lang/Object from /usr/local/classpath/share/classpath/glibj.zip] [Linking class java/lang/Object] [Loaded java/io/Serializable from /usr/local/classpath/share/classpath/glibj.zip] [Linking class java/io/Serializable] [Loaded java/lang/Class from /usr/local/classpath/share/classpath/glibj.zip] [Linking class java/lang/Class] [Loaded java/lang/Runnable from /usr/local/classpath/share/classpath/glibj.zip] [Linking class java/lang/Runnable] ... [Linking class gnu/java/nio/channels/FileChannelImpl] [Loaded java/lang/Runtime from /usr/local/classpath/share/classpath/glibj.zip] [Linking class java/lang/Runtime] [Loaded gnu/classpath/VMStackWalker from /usr/local/share/jamvm/classes.zip] [Linking class gnu/classpath/VMStackWalker] [Loaded java/lang/VMRuntime from /usr/local/share/jamvm/classes.zip] [Linking class java/lang/VMRuntime] Segmentation fault Any help is greatly appreciated as I am interested in deploying this into an application that we want to roll out soon. Thanks in advance, Dikran Hovagimian --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=kkid0709bid3057dat1642 ___ Jamvm-general mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jamvm-general
JamVM 1.4.3 released
Hi, I'm pleased to announce the release of JamVM 1.4.3 (http://jamvm.sourceforge.net). This release adds heap compaction and additional Java 1.5 support. Several other features have been implemented and several bug-fixes have also been made. The full list of changes are here: http://sourceforge.net/project/shownotes.php?release_id=418830 The release will also be mirrored on BerliOS and CVS updated when BerliOS is back online (it is down at the moment). Thanks, Rob. P.S. I'd like to thank Michael Koch for the reflection class signers support.
Re: JamVM 1.4.3 released
Hi, I meant to say I'd like to thank Michael Koch for the reflection class _generic signature_ support. It's late :) Rob. On 5/22/06, Robert Lougher [EMAIL PROTECTED] wrote: Hi, I'm pleased to announce the release of JamVM 1.4.3 (http://jamvm.sourceforge.net). This release adds heap compaction and additional Java 1.5 support. Several other features have been implemented and several bug-fixes have also been made. The full list of changes are here: http://sourceforge.net/project/shownotes.php?release_id=418830 The release will also be mirrored on BerliOS and CVS updated when BerliOS is back online (it is down at the moment). Thanks, Rob. P.S. I'd like to thank Michael Koch for the reflection class signers support.
Re: [cp-patches] RFC: local (unix-domain) sockets
Hi, I'd be inclined to have a look at the code produced with and without the workaround. The easiest way I find to do this is to temporarily hack the Makefile and add a -S onto the CFLAGS. Touch the file and remake, leaving the assembler in the .o file (of course the link will now fail). This way you don't have to worry about include paths, -Ds, etc. Alternatively you can get a dissassembly in gdb with x/i local_bind... Rob. P.S. What version of JamVM were you using? I kinda get worried when I see pointers changing, as the CVS version updates pointers (heap compaction) but this isn't an object reference... On 4/14/06, Casey Marshall [EMAIL PROTECTED] wrote: On Apr 13, 2006, at 5:48 PM, Tom Tromey wrote: Casey == Casey Marshall [EMAIL PROTECTED] writes: Casey This isn't really related, but compiling this code with GCC 4.0.1 on Casey Darwin/x86 introduces a potentially serious problem. In the Casey `localBind' JNI function, I am doing this: Casey So, my question is, is this a known problem with GCC? If so, is there Casey any way to work around it? Whenever I see a cast these days, I think that there must be an aliasing bug. But if there's one in this code, I don't see it. Offhand I don't recall hearing of a bug like this. The cast got me thinking, because GetStringUTFChars returns `const char *', and I'm trying to keep the code -Werror clean, so I cast it to `char *'. Changing everything to `const char *' in both the JNI function and the `local_bind' function does nothing, though. My workaround so far is to add this to `local_bind': static int foo = 0; ... if (foo) fprintf (stderr, bind %p\n, addr);
Re: Free JVM on Macintel
Hi, On 3/20/06, Casey Marshall [EMAIL PROTECTED] wrote: On Mar 20, 2006, at 2:07 PM, Christian Thalinger wrote: On Mon, 2006-03-20 at 13:51 -0800, Casey Marshall wrote: Hi, Are any free VMs currently supported on OS X for Intel (natively)? Alternatively, if there's a concise description on what's needed to support jamvm or cacao (function call ABI hacks, I'd assume), I'd be happy to hack on it. I think it's quite easy (at least for me) to port cacao to i686- darwin. The ABI is the same as on linux, AFAIK. I did blindly try the i386-linux ABI support in jamvm, but that was hitting some weird SIGILL. Here's a modified version of the ABI for linux/i386. It now maintains the darwin/i386 alignment constraints. Of course, it is untested on darwin/i386, but it works on linux/i386 (stricter alignment doesn't matter). So, all you should need to do it copy src/os/linux/i386 to src/os/darwin/i386 and replace dll_md.c. Let me know how you get on. Rob. dll_md.c Description: Binary data
Re: Free JVM on Macintel
Hi Casey, On 3/21/06, Casey Marshall [EMAIL PROTECTED] wrote: This gets Hello, world to work :-) I'll try some more things, and let you know what I see. Great! Thanks for letting me know. Rob. P.S. Can you let me know what uname -p gives? On Linux the autoconf host triple gives i686 (or whatever uname -m returns) rather than i386 as on Open/Free BSD (uname -p).
Re: [cp-patches] Re: RFC: gdkpixbuf looking vs main gdk lock
Hi Mark, On 3/20/06, Mark Wielaard [EMAIL PROTECTED] wrote: Hi, Done. If you have a scroll mouse please try out WW2D with Cacao (I didn't get it working with jamvm yet, which seems to crash after loading jawt). What version of JamVM are you using (i.e. is it CVS or a released version)? Can you give details as to how to reproduce? Thanks, Rob.
Re: Free JVM on Macintel
On 3/20/06, Casey Marshall [EMAIL PROTECTED] wrote: On Mar 20, 2006, at 2:07 PM, Christian Thalinger wrote: On Mon, 2006-03-20 at 13:51 -0800, Casey Marshall wrote: Hi, Are any free VMs currently supported on OS X for Intel (natively)? Alternatively, if there's a concise description on what's needed to support jamvm or cacao (function call ABI hacks, I'd assume), I'd be happy to hack on it. I think it's quite easy (at least for me) to port cacao to i686- darwin. The ABI is the same as on linux, AFAIK. I did blindly try the i386-linux ABI support in jamvm, but that was hitting some weird SIGILL. My understanding is that the Darwin-i386 ABI is very similar to the SYSV ABI, with some alignment changes. I did something like this for MIPS some time ago, so I'm no stranger to this stuff. Most open-source VMs just rely on libffi to do the nasty calling-convention stuff. Therefore, if libffi is supported on your os/architecture it's already done. JamVM's a bit different in that it used to always use a handcoded routine to construct the call-frame on each os/cpu as this tends to be much faster. You've obviously found the linux/i386 one... But to ease porting of JamVM it can now also use libffi. So, at least with JamVM you have two choices : 1) code the calling-convention by hand for darwin/i386. It's not difficult, as i386 passes everything on the stack. As you said, it's probably alignment stuff, so the linux code should work with some minor mods. 2) Just use libffi. As Andrew Pinksi says it's ported, all you need to do is have an empty platform init.c in darwin/i386, and use --enable-ffi when configuring JamVM. Apple tends to have good documentation, so it shouldn't be too hard to find the differences. Somebody else has also asked me to support Intel Macs, so I'll see if I get time to look at it this week. However, testing will be difficult, as I don't have an Intel Mac, and I don't intend to buy one :) Rob. IIRC we don't have anything like a porting guideline. I could tell you what to do, or give me access to a box and you get a port in a half day, probably... :-) It's a laptop, and as such moves around the Bay Area a lot. A little description (look at this code/do something similar for your CPU/ABI) would help.
FOSDEM: slides from JamVM talk
Hi, Roman has kindly uploaded the slides from my talk to the Wiki (see http://developer.classpath.org/mediation/Fosdem2006). Thanks, Rob. P.S. There's one obvious mistake on slide 2. The release date of JamVM 1.4.2 should be 2006 not 2005!
Re: [cp-patches] JamVM stopped working today
Hi, Thanks for the replies. I didn't fancy doing a complete checkout over a 3G/GPRS datacard :) Rob. On 1/16/06, Lillian Angel [EMAIL PROTECTED] wrote: On Mon, 2006-01-16 at 18:22 +, David Gilbert wrote: Hi All, JamVM stopped working for me today - I get this error when I try to run the SimpleTestHarness in Mauve: $ jamvm -classpath . gnu.testlet.SimpleTestHarness -file StyleConstantsTests.txt -verbose -debug Cannot create system class loader Exception occured while printing exception (java/lang/NoClassDefFoundError)... Original exception was java/lang/UnsatisfiedLinkError Any hints? Bearing in mind that I don't like any of this low-level stuff... I am getting this too. The build is broken. I rolled back my repository to sunday using cvs up -D 01/15/2006. Use cvs up -A when you want to update your repository to the current version when the build is working again. Lillian ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: Using a workspace-based VM in Eclipse
Hi, On 22 Dec 2005 12:34:42 -0700, Tom Tromey [EMAIL PROTECTED] wrote: To do this, follow the wiki instructions to check out and build Classpath and Cacao (as always, this VM is chosen because all the needed build bits are in its cvs repository... hint to the other VM developers). Hint taken. The necessary files are now in JamVM's cvs repository. This is your patch with a couple of changes by Raif that adds the .cvsignore files and adds an Autogen Builder to create, among other things, the configure script. Rob. Once that is done, check out the fakejdk project from :pserver:[EMAIL PROTECTED]:/cvs/rhug, module 'fakejdk'. (This ought to auto-build, but if not, apply the usual Clean hack.) This just makes a little project consisting of symlinks -- it is a huge hack. Now, go to Window-Preferences-Java-Installed JREs and choose 'Add...' to add a new one. I named mine Cacao. For the JRE home directory, choose $workspace/fakejdk. Then turn off Use default system libraries and you can edit the Source attachment of the new JRE to point to the classpath directory in the workspace. Once this is done you can pick this JRE for launchers, or to build other projects against. This is nice because it means these projects don't have to necessarily depend on Classpath -- there is a layer of indirection, so you can build and run them against the system VM if you prefer to do that, without modifying the shared build setup. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Security manager problem
Hi, On 12/6/05, Gary Benson [EMAIL PROTECTED] wrote: Anthony Green wrote: It's been a long time since I've read anything about this kind of stuff, but my understanding is that you simply wrap things like this up in a AccessController.doPrivileged(), since the access control context of the bootstrap or system class loader will permit file I/O. That's interesting, as I was just looking at an some code in an AccessController.doPrivileged() that was doing security checks. Perhaps JamVM's AccessController.doPrivileged() is not in fact doing anything. What version of JamVM are you using? As far as I'm aware, JamVMs implementation of VMAccessController is complete (it was provided by Casey Marshall, if I remember correctly). I've made some recent changes to the native method that obtains the stack, so it _could_ have broken in 1.4.1. Do you have a testcase? Thanks, Rob. Cheers, Gary ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: memory behavior to expect with gjdoc-0.7.6
Hi, On 12/5/05, Mark Wielaard [EMAIL PROTECTED] wrote: Hi Frederick, On Sun, 2005-12-04 at 21:26 -0500, Frederick C Druseikis wrote: I'm using gjdoc-0.7.6 to test a new port of JamVM-1.4.1 + classpath-0.19 on OpenBSD. I'm trying to get gjdoc to do all the classpath documentation. gjdoc makes a lot of progress (it's outputting stuff), but blows off by hitting an upper memory limit. My question is this: Should I expect that gjdoc will need to use 1GB per process virtual memory? How big? (This may be transparently satisfied on Linux; on OpenBSD I have to recompile the kernel. Bummer.) Running gjdoc over all of GNU Classpath at once is pretty memory intensive. I don't have a setup at this moment using jamvm. But a natively compiled (with gcj) gjdoc seems to have a top virtual memory usage of just above 300MB. So 1GB seems a bit much. But try generating documentation first of just one or two subpackages to see if that works. Could you also run JamVM with -verbose:gc and send me the output? I've never ran gjdoc myself, but I'll have a look at running it to see what happens on my setup. Thanks, Rob. Cheers, Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBDlD2+xVhZCJWr9QwRAmEzAKCnq+9RsN5f/gjR2W5g4hBCNn3stgCgmiz4 zHjDNYYTionk4l3SDIIAGuY= =r/+u -END PGP SIGNATURE- ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: memory behavior to expect with gjdoc-0.7.6
Hi, On 12/5/05, Mark Wielaard [EMAIL PROTECTED] wrote: Hi Fred, On Mon, 2005-12-05 at 12:32 -0500, [EMAIL PROTECTED] wrote: Could you also run JamVM with -verbose:gc and send me the output? Attached. Thanks. This seems to point out two things: 1) There is a huge allocation (2MB+): GC: Alloc attempt for 2209016 bytes failed. at this point in the code: // REVIEW: Using max instead of average may allocate a very large // buffer. Maybe we should do something more efficient? int remaining = in.remaining (); int n = (int) (remaining * maxBytesPerChar ()); ByteBuffer out = ByteBuffer.allocate (n); I believe that REVIEW note gives us a hint :) 2) JamVM has fragmented its heap so much that it cannot allocate such a block of data even though there is enough space in total: GC: Largest block is 2087448 total free is 778822576 out of 943718392 (82%) Or am I reading the output incorrectly? This is what I was afraid of. JamVM doesn't use handles so compaction is a non-trivial exercise. However, I'd like to analyse the gc output myself, but I don't seem to have been sent it... Rob. Cheers, Mark ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: memory behavior to expect with gjdoc-0.7.6
On 12/5/05, Robert Lougher [EMAIL PROTECTED] wrote: Hi, On 12/5/05, Mark Wielaard [EMAIL PROTECTED] wrote: Hi Fred, On Mon, 2005-12-05 at 12:32 -0500, [EMAIL PROTECTED] wrote: Could you also run JamVM with -verbose:gc and send me the output? Attached. Thanks. This seems to point out two things: 1) There is a huge allocation (2MB+): GC: Alloc attempt for 2209016 bytes failed. at this point in the code: // REVIEW: Using max instead of average may allocate a very large // buffer. Maybe we should do something more efficient? int remaining = in.remaining (); int n = (int) (remaining * maxBytesPerChar ()); ByteBuffer out = ByteBuffer.allocate (n); I believe that REVIEW note gives us a hint :) 2) JamVM has fragmented its heap so much that it cannot allocate such a block of data even though there is enough space in total: GC: Largest block is 2087448 total free is 778822576 out of 943718392 (82%) Or am I reading the output incorrectly? This is what I was afraid of. JamVM doesn't use handles so compaction is a non-trivial exercise. However, I'd like to analyse the gc output myself, but I don't seem to have been sent it... On second thoughts, it may have been rejected by gmail if the attachment was too big (how big was it?). Could you try compressing it (if it wasn't)? Thanks, Rob. Rob. Cheers, Mark ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: memory behavior to expect with gjdoc-0.7.6
Hi, On 12/5/05, Robert Lougher [EMAIL PROTECTED] wrote: Hi, On 12/5/05, Mark Wielaard [EMAIL PROTECTED] wrote: 2) JamVM has fragmented its heap so much that it cannot allocate such a block of data even though there is enough space in total: GC: Largest block is 2087448 total free is 778822576 out of 943718392 (82%) Or am I reading the output incorrectly? This is what I was afraid of. JamVM doesn't use handles so compaction is a non-trivial exercise. However, I'd like to analyse the gc output myself, but I don't seem to have been sent it... If I remember correctly, gcc/gij uses the Boehm GC? This doesn't do compaction either, but it does maintain different size free-lists, enabling it to use an approximate best fit algorithm. JamVMs allocator uses a next-fit allocation strategy -- the rationale here is to try and keep objects created together in time close together in the heap, as objects tend to die together as well (and locality of reference means it may exhibit better cache behaviour). However, it's obviously performing appallingly here. I'll have a look at changing the allocation strategy and see if it improves things. Thanks, Rob. Cheers, Mark ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
JamVM 1.4.0 released
Hi, I'm pleased to announce the release of JamVM 1.4.0 (http://jamvm.sourceforge.net). This release adds support for Soft/Weak/Phantom references, along with GC-optimisations, and several bug-fixes. The full list of changes are here: http://sourceforge.net/project/shownotes.php?release_id=372551 Thanks, Rob. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: JamVM does not startup
Hi Isabella, I'll take this off-line. Rob. On 11/18/05, Isabella Thomm [EMAIL PROTECTED] wrote: Hello! I am new to this, so sorry about this simple question and it probably does not fit in here, but I'd be glad to solve this problem: I have installed classpath 0.19, as described, (configure, make, make install...), and then jamVM 1.3.3 (configure with the --with-classpath-install-dir option, make etc.) and I get the following error, while trying to execute a simple with java compiled program: Error initialising VM (initialiseMainThread). I have set the CLASSPATH variable to the glibj.zip file and the LD_LIBRARY_PATH to the classpath/lib/classpath directory. It's a configuration problem, I guess, maybe some wrong file is taken. I am using Debian unstable. Isabella ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: example programs
Hi, On 10/6/05, theUser BL [EMAIL PROTECTED] wrote: An other point is about the JamVM: I think, the property of java.vendor.url is wrong. There stand http://gnu.classpath.org; But this side don't exists. There existing only http://www.classpath.org; and http://www.gnu.org/software/classpath/; Yes, it's wrong (well spotted). I'll correct it in CVS and it'll be in the next release. Thanks, Rob. Greatings theuserbl ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: JamVM 1.3.3 released
Hi, The problem is you're trying to build on AMD64. This is the only platform which needs libffi. On my AMD64 system I've installed libffi from the distribution, and configure has no problems in finding this. From your message you've compiled libffi yourself. I guess it's in a non-standard place and so configure can't find it. I've no idea how to make configure find it, beyond putting it where configure expects. Disabling libffi with --disable-ffi won't work because AMD64 requires it (and it's the only platform which has it enabled by default). I will make configure bomb out on AMD64 in this case. Anybody know how to get configure to find it? If not, I'll look at it tonight. Rob. On 9/15/05, theUser BL [EMAIL PROTECTED] wrote: I have tested it - to compile - and become errors. At first I tried this: [EMAIL PROTECTED]:~/z/jamvm-1.3.3 ./configure --prefix=$HOME/jamvm checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes [...] checking for inflate in -lz... yes checking for ffi_call in -lffi... no configure: error: cannot find libffi [EMAIL PROTECTED]:~/z/jamvm-1.3.3 After that Error I tried to set LD_LIBRARY_PATH to the path where my compiled libffi is. But it don't helped. There comes the same error, that it wasn't found. So I have given in: [EMAIL PROTECTED]:~/z/jamvm-1.3.3 ./configure --prefix=$HOME/jamvm -disable-ffi checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk [...] config.status: creating lib/gnu/classpath/Makefile config.status: linking ./src/arch/x86_64.h to src/arch.h config.status: executing depfiles commands [EMAIL PROTECTED]:~/z/jamvm-1.3.3 That works. But if I tried to compile it: [EMAIL PROTECTED]:~/z/jamvm-1.3.3 make Making all in src make[1]: Entering directory `/home/patrick/z/jamvm-1.3.3/src' Making all in os make[2]: Entering directory `/home/patrick/z/jamvm-1.3.3/src/os' Making all in linux [...] gcc -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE=\jamvm\ -DVERSION=\1.3.3\ -DTHREADED=1 -DDIRECT=1 -DUSE_CACHE=1 -DHAVE_LIBPTHREAD=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIBZ=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DUSE_ZIP=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DHAVE_ENDIAN_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_LOCALE_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_STRTOL=1 -DHAVE_SETLOCALE=1 -DHAVE_LC_MESSAGES=1 -I. -I. -DINSTALL_DIR=\/home/patrick/jamvm\ -DCLASSPATH_INSTALL_DIR=\/usr/local/classpath\ -g -O2 -c `test -f 'direct.c' || echo './'`direct.c source='dll_ffi.c' object='dll_ffi.o' libtool=no \ depfile='.deps/dll_ffi.Po' tmpdepfile='.deps/dll_ffi.TPo' \ depmode=gcc3 /bin/sh ../depcomp \ gcc -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE=\jamvm\ -DVERSION=\1.3.3\ -DTHREADED=1 -DDIRECT=1 -DUSE_CACHE=1 -DHAVE_LIBPTHREAD=1 -DHAVE_LIBM=1 -DHAVE_LIBDL=1 -DHAVE_LIBZ=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DUSE_ZIP=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DHAVE_ENDIAN_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_LOCALE_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_STRTOL=1 -DHAVE_SETLOCALE=1 -DHAVE_LC_MESSAGES=1 -I. -I. -DINSTALL_DIR=\/home/patrick/jamvm\ -DCLASSPATH_INSTALL_DIR=\/usr/local/classpath\ -g -O2 -c `test -f 'dll_ffi.c' || echo './'`dll_ffi.c gcc -g -O2 -o jamvm alloc.o cast.o class.o dll.o excep.o execute.o hash.o interp.o jam.o jni.o lock.o natives.o reflect.o resolve.o string.o thread.o utf8.o zip.o properties.o direct.o dll_ffi.o os/linux/x86_64/libnative.a os/linux/libos.a -lz -ldl -lm -lpthread dll.o(.text+0x8e): In function `callJNIWrapper': /home/patrick/z/jamvm-1.3.3/src/dll.c:322: undefined reference to `callJNIMethod' dll.o(.text+0x809): In function `lookupLoadedDlls': /home/patrick/z/jamvm-1.3.3/src/dll.c:350: undefined reference to `nativeExtraArg' collect2: ld returned 1 exit status make[2]: *** [jamvm] Fehler 1 make[2]: Leaving directory `/home/patrick/z/jamvm-1.3.3/src' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/home/patrick/z/jamvm-1.3.3/src' make: *** [all-recursive] Fehler 1 [EMAIL PROTECTED]:~/z/jamvm-1.3.3 I have also used
Re: GNU Classpath and JVMs
Hi, From the new versions, which use 0.17 or 0.18, I can either not compile it or it (like JamVM), or it have problems with AWT and Swing (IKVM). And a CVS-version of Kaffe I have not tried. But Kaffe 1.1.5 don't run Swing programs on my computer. JamVM _does_ work with Classpath-0.18. The latest version is usually at most broken for a couple of days whever a new snapshot of Classpath is made. You can now also get JamVM from CVS, and I intend to ensure that this is current with Classpath CVS. So when a new Classpath snapshot is made, the CVS version of JamVM should work, even if the latest released version doesn't (which was the case last week). In your case the problem is a configuration issue on your machine regarding libffi which is stopping JamVM building. Rob. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
JamVM 1.3.3 released
Hi, I'm pleased to announce the release of JamVM 1.3.3 (http://jamvm.sourceforge.net). This release adds ports to AMD64 and PowerPC64 and a couple of other minor features/bug-fixes. The full list of changes are here: http://sourceforge.net/project/shownotes.php?release_id=356099 Thanks, Rob. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [Jamvm-general] JamVM and Eclipse
Hi Robert,
Thanks for giving everything a test. I'll have a look at the PATH
issue once I've got a new release out. JamVM 1.3.2 won't work with
the latest Classpath snapshot now that 0.18 has been released so I
need to do this ASAP! It's basically releasing the CVS version, but I
need to put in a fix for a library naming change on Max OS X...
Rob.
On 9/7/05, Robert Schuster [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
as you can see in the Eclipse section of our showcase page[0] running the IDE
with JamVM still needs a small kludge:
PATH=.:${PATH} ./eclipse -consoleLog -debug -vm jamvm -vmargs -mx256m
I wonder why the PATH thing is necessary and whether this is a bug in our
class
library or JamVM. I used Classpath and JamVM from CVS for this, my machine
runs
Gentoo x86 and Eclipse is 3.1 RC5 (yeah its an older version).
It may be of interest that I can run Eclipse this way too:
jamvm -mx256m -jar startup.jar
or
jamvm -xm256m -jar /home/rob/tmp/native-eclipse/eclipse-3.1/./startup.jar
(which
is what the starter program does)
and it works without problems.
cu
Robert
[0] -
http://developer.classpath.org/mediation/ClasspathShowcase#head-77e64cc6893026805e96c751a32012d79dd93e4f
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFDHjcqG9cfwmwwEtoRAim9AKCfvOc4oWdOC80q8PtmdvrkGpojtQCgkTIn
pc+LKtjBdlA7LizQbJfcLUg=
=/YNt
-END PGP SIGNATURE-
---
SF.Net email is Sponsored by the Better Software Conference EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile Plan-Driven Development * Managing Projects Teams * Testing QA
Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf
___
Jamvm-general mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jamvm-general
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
