sablevm-developer Mailing List for SableVM (Page 28)
Brought to you by:
egagnon
Menu
▾
▴
sablevm-developer — SableVM developer mailing list
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(27) |
Aug
(22) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(30) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(32) |
Oct
|
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(69) |
Sep
(10) |
Oct
(31) |
Nov
(15) |
Dec
(58) |
| 2003 |
Jan
(33) |
Feb
(81) |
Mar
(85) |
Apr
(24) |
May
(15) |
Jun
(14) |
Jul
(6) |
Aug
(9) |
Sep
(101) |
Oct
(59) |
Nov
(142) |
Dec
(34) |
| 2004 |
Jan
(107) |
Feb
(164) |
Mar
(181) |
Apr
(96) |
May
(81) |
Jun
(71) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Grzegorz P. (D. D. <ga...@de...> - 2004-01-16 08:38:06
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Thu, 15 Jan 2004 22:57:46 -0500
Source: sablevm
Binary: libsablevm1 sablevm libsablevm1-dev
Architecture: source all i386
Version: 1.0.9+svn20040115-1
Distribution: unstable
Urgency: low
Maintainer: Grzegorz Prokopski (Debian Developer) <ga...@de...>
Changed-By: Grzegorz Prokopski (Debian Developer) <ga...@de...>
Description:
libsablevm1 - Free implementation of JVM second edition - library
libsablevm1-dev - Free implementation of JVM secon edition - development files
sablevm - Free implementation of Java Virtual Machine (JVM) second edition
Changes:
sablevm (1.0.9+svn20040115-1) unstable; urgency=low
.
* Completly new and improved version. Uses NEW GNU Classpath. We're
pulling from SVN, but don't worry - it's much better than old 1.0.9.
* SableVM debian package is now native, so look at upstream changelog.
Files:
203477f44d20a8b646c87a65ed66a244 864 interpreters optional sablevm_1.0.9+svn20040115-1.dsc
cc2e44a9c0d0e5f4a1ac09a19fffe8c8 546754 interpreters optional sablevm_1.0.9+svn20040115-1.tar.gz
48ddc45c45403d8a7099fe619d87812c 32512 interpreters optional sablevm_1.0.9+svn20040115-1_i386.deb
17c0bf5714409115db38a234576b2160 154604 libs optional libsablevm1_1.0.9+svn20040115-1_i386.deb
87d44a3ee85626237a03fd2f6be5f689 22030 libdevel optional libsablevm1-dev_1.0.9+svn20040115-1_all.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAB5zZcxjwiKS4/ekRAngGAJ9P71OSESpmt2A53RWkeRYA6D1H7ACgsdgo
nhkaE01IVxgweL5wQdvatZg=
=RTmr
-----END PGP SIGNATURE-----
Accepted:
libsablevm1-dev_1.0.9+svn20040115-1_all.deb
to pool/main/s/sablevm/libsablevm1-dev_1.0.9+svn20040115-1_all.deb
libsablevm1_1.0.9+svn20040115-1_i386.deb
to pool/main/s/sablevm/libsablevm1_1.0.9+svn20040115-1_i386.deb
sablevm_1.0.9+svn20040115-1.dsc
to pool/main/s/sablevm/sablevm_1.0.9+svn20040115-1.dsc
sablevm_1.0.9+svn20040115-1.tar.gz
to pool/main/s/sablevm/sablevm_1.0.9+svn20040115-1.tar.gz
sablevm_1.0.9+svn20040115-1_i386.deb
to pool/main/s/sablevm/sablevm_1.0.9+svn20040115-1_i386.deb
|
|
From: Grzegorz B. P. <ga...@de...> - 2004-01-15 22:15:02
|
W liście z czw, 15-01-2004, godz. 15:36, Etienne Gagnon pisze: > At least, we know that SableVM works under Cygwin. It's just the licensing > that causes problems (cygwin = GPL). Not really. Fortunatelly there are exceptions ;-) Please see: http://www.cygwin.com/faq/faq_8.html "Cygwin is currently available for proprietary use only through a proprietary-use license. Please see http://www.redhat.com/software/cygwin/ for more information about the Red Hat Cygwin Product. In accordance with section 10 of the GPL, Red Hat, Inc. permits programs whose sources are distributed under a license that complies with the Open Source definition to be linked with libcygwin.a without libcygwin.a itself causing the resulting program to be covered by the GNU GPL. This means that you can port an Open Source(tm) application to cygwin, and distribute that executable as if it didn't include a copy of libcygwin.a linked into it. Note that this does not apply to the cygwin DLL itself. If you distribute a (possibly modified) version of the DLL you must adhere to the terms of the GPL, i.e., you must provide sources for the cygwin DLL." As far as I can read it means that as long as the user fetches the cygwin.dll himself and we don't distribute it with SableVM - we can safely provide SableVM binaries compiled for Cygwin w/o falling under the GPL. The funny question now would be whether you could run closed-source programs on such SableVM. It smells like we had this dicussion a few times already ;-) ... after a while ... I mostly agree with Etienne's above statment. Cheers, Grzegorz B. Prokopski -- Grzegorz B. Prokopski <ga...@de...> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org |
|
From: David <db...@CS...> - 2004-01-15 21:26:27
|
> Speaking of hardware, I'd appreciate your opinion here: >=20 > I am seriously evaluating purchase of an oldish (6-7 years old) Mac, li= ke > Apple Power Macintosh 7300 200MHz, 64MB RAM, 2GB HDD... Apparently UQAM > sells such hardware for ~40$. Hi, I don't know much about Mac hardware itself, my iBook acquired ~16 months= ago is my first one. But I think for 40$ it is worth it. > (Yes, it's twice cheaper than Pentium of same params!) It is usually difficult to compare the actual CPU but you may find this info interesting: My PowerPC 750FX (G3) @ 700MHz runs SableVM interpreters slightly faster = than my AMD Athlon @ 1200MHz for the SPECjvm98. Both with Debian and 256MB RAM. >=20 > According to the informations I found here: > http://www.apple-history.com/noframes/body.php?page=3Dgallery&model=3D7= 300 > it had 604e CPU. >=20 > Question: Would SableJIT work with that?=20 Yes, it should. PowerPC architecture is quite standard. I am using this documentation which cover several PowerPC, including yours. http://www-3.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF778= 525699600719DF2 Any diff in the instructions sets occur at the supervisor (i.e. instructions only usable by the kernel and mostly related to mem management). The only exception is the G4 (an implementation by Motorola). Motorola added extra instructions called Altivec. These are not part of the standard PowerPC architecture and are not used by SableJIT. Any CPU specific instructions or information (can take advantage of known cache block size on ppc) will be optional and specified at static compile time. > Or: what would be minimal hardware specs that you'd recommend for > a PPC porting machine? (I don't really know ppc/mac world too well). >=20 From http://www.debian.org/ports/powerpc/ it seems that Debian powerpc port started also with a 604e @ 200MHz! Note: Unlike PCs that still use 16-bit BIOS code instructions dating from ~1980. Apple changed a few times how Mac boots. So in the boot documentation Mac are refered to old world, new world or OpenFirmware terms depending on how to boot. The new booting software is OpenFirmware (~BIOS). I am almost sure that Linux can boot on pre-OpenFirmware machine without problem. However, I think that OS X requires OpenFirmware (this would explain why they say up to 9.1) but see below. Also note that some *BSD or other PowerPC OS, mostly recently port may support only OpenFirmware machine. > I guess there's no way OS X could run on such hardware :-) Note: Probably cannot boot directly. However, there is this nice software call Mac-on-Linux that allows Mac OS X to be run at same time even on non-Mac hardware. It like an open source VMWare for PowerPC if you want. Note to Linux/intel users: No it does not work on Linux intel PCs. The fact says: "In short, MOL should run on any PowerPC hardware (with the except of 601-based systems)." So, yes with Mol. OS X is quite graphical and heavy so it could be quite slow... It is also possible to run OS X without Apple GUI like any other Unix systems. Also, nothing stops you from installing X11/WindowMaker etc. It is only a Unix system with a nice GUI. Note, without OS X native interface, cannot run graphical apps that use this interface libraries. Not many people run the pure system. David --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Etienne G. <gag...@uq...> - 2004-01-15 20:44:38
|
Chris Pickett wrote: > ...I'd like to hear what Etienne thinks about all this > recent discussion, if he has a bit of time :). Etienne thinks that we need more man/woman-power. It's all fine to dream up all these beautiful ports and projects, but we need somebody(ies) to actually be in charge of doing it. This(ese) person(s) would have the final say about which tools would be best to do a native Windows port. At least, we know that SableVM works under Cygwin. It's just the licensing that causes problems (cygwin = GPL). Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Chris P. <chr...@ma...> - 2004-01-15 19:56:36
|
>Yes, this is problably the goal. > >One advantage on Windows though if SableVM and Classpath implementation >becomes quite would be to bundle SableVM with open source browsers such >as Mozilla. MS Windows do not come pre-installed with Java (though I >think there was a MS vs Sun case). > >But this could be a long term goal. > > > > >>And maybe here lies the beauty of this. All these "mediating layer" >>solutions are like watering down the solution. To get to the real >>stuff, to really say: "We have it *really* ported to MS Win" means >>to use maximum of Microsoft tools: OS, Compiler, all Environment. >> >> > >Yes. Agree. > > > > WfSU is an emulation / mediation layer just like Cygwin and MinGW, and is based on some BSD (recent Slashdot discussion). I think we've already established that. I don't think that using an MS compiler is necessary for a real native port, because it's not actually a part of the operating system. Microsoft Office isn't part of Windows, neither should be Internet Explorer. Perhaps if compiler tools came with the OS that would be one thing, but they don't. It's been possible since 1.4 to build Mozilla for Windows using free software (in particular gcc) -- and I think many people consider it a "native" port. Although, the gcc port is tier-3 and not tier-1. Finally, one of the features of SableVM is that it is POSIX compliant, which is supposed to make it portable. We want to minimize the amount of architecture / OS-dependent code if we're going to argue that it's really portable. Personally, I am writing some stuff that works directly with pthreads, and it's unlikely that I'll want to port it to Windows if pthreads is not available. I think that getting a Java plugin for Mozilla working would be great as well. If (I'm dreaming here) Mozilla one day shipped with support for SableVM and Classpath on all platforms, that would be a fantastic thing. Personally I think getting a *n*x Java plugin for Mozilla going is a more important task than getting a Windows port and later plugin working, because (a) as a whole I think everybody would rather if Windows wasn't actually necessary for any reason -- which it would become if we had a Windows port (yes, I use Windows 2000, so I recognize that all this might sound hypocritical, but I don't develop under Windows, and I use as much free Windows software as possible), and (b) getting the plugin working in a browser seems more likely to increase the developer and user base than porting it to Windows. I think that Windows users by nature don't care if the VM they are using is free or not, so just because it's available under Windows wouldn't make such a big difference. But a plugin for Mozilla under Linux could be important for several people. I don't know -- I'm just offering some thoughts here. I'm not proposing that I personally be the one to make the port, so really I'm not trying to argue against anyone. I'm just wary of getting locked in to depending on non-free software (even though WSfU is apparently going to cost $0 soon). I think before using WSfU it's worth convincing ourselves that MinGW and pthreads for Win32 is not feasible, and before using a native compiler and process support convince ourselves that we wouldn't be better off using an emulation layer. It might well be that if we were to attempt "native" support, that rather than rip out the entire threading and locking code in SableVM, we might end up writing our own internal emulation layer, to maintain portability, and for all intents and purposes this could be the same as using WSfU or pthreads for Win32. And that would be pretty silly -- it would be better to fix pthreads for Win32 to do what we need it to (we can't fix WSfU, nor is Microsoft likely to care about any problems). Okay, see you. I'm pretty busy now until Feb. 8th, so I might disappear a little again. I'd like to hear what Etienne thinks about all this recent discussion, if he has a bit of time :). Cheers, Chris > > |
|
From: Grzegorz B. P. <ga...@de...> - 2004-01-15 19:14:22
|
On Thu, 2004-01-15 at 11:24, David Bélanger wrote: > > > Maybe what we should ask ourselves is what is the goals with > > > SableVM/Windows we are actually trying to achieve. > > Exactly. Though it's not too obvious what the goal could be. As with > > many ports that nobody is using (are there any SableVM alpha users? ;-) > Well, if someone happens to have a alpha machine, there is not too many VM > available for that platform... Yes, probably. I checked and apparently you could get an alpha for 100$. But personally I'd rather be interested in gettin an ARM because apparently it's used in many embedded platforms. I haven't seen any offers though (at least where I looked). > If we consider OS X, we will probably never have OS X non-programmers end-users. > Java is one of the main languages for OS X, the other being objective C. > So Java is pre-installed, optimized for that system and is probably kept > quite up to date. > > However, as the developer/research-base increases, we may have a few OS X > developers. Currently, I use it mostly as a testing platform. Speaking of hardware, I'd appreciate your opinion here: I am seriously evaluating purchase of an oldish (6-7 years old) Mac, like Apple Power Macintosh 7300 200MHz, 64MB RAM, 2GB HDD... Apparently UQAM sells such hardware for ~40$. (Yes, it's twice cheaper than Pentium of same params!) According to the informations I found here: http://www.apple-history.com/noframes/body.php?page=gallery&model=7300 it had 604e CPU. Question: Would SableJIT work with that? Or: what would be minimal hardware specs that you'd recommend for a PPC porting machine? (I don't really know ppc/mac world too well). I guess there's no way OS X could run on such hardware :-) > One advantage on Windows though if SableVM and Classpath implementation > becomes quite would be to bundle SableVM with open source browsers such > as Mozilla. MS Windows do not come pre-installed with Java (though I > think there was a MS vs Sun case). Yes, you won't find java in out-of-the-box windows anymore. > But this could be a long term goal. Having a mozilla java plugin is IMO very important for the users, not only on windows. There have been quite many cases I've seen where people asked/looked for info about "mozilla + sablevm". I'd certainely be interested in helping a person who would like to try developing such an extension of SableVM. What makes it even more interesting - this seems to be pretty well documented field (i.e. there are docs at Mozilla web pages), unless I seriusly missed something. Cheers, Grzegorz B. Prokopski |
|
From: David <db...@CS...> - 2004-01-15 16:24:50
|
> > Maybe what we should ask ourselves is what is the goals with > > SableVM/Windows we are actually trying to achieve. > Exactly. Though it's not too obvious what the goal could be. As with > many ports that nobody is using (are there any SableVM alpha users? ;-) Well, if someone happens to have a alpha machine, there is not too many V= M available for that platform... If we consider OS X, we will probably never have OS X non-programmers end= -users. Java is one of the main languages for OS X, the other being objective C. So Java is pre-installed, optimized for that system and is probably kept quite up to date. However, as the developer/research-base increases, we may have a few OS X developers. Currently, I use it mostly as a testing platform. > one of possible goals is to _show_ that it's possible and maybe even > feasible to use our software on different platform. For *n*x platforms > it's rather trivial and has been showed many times already (thought man= y > of the ports could use some polishing of corner cases). Yes, this is problably the goal. One advantage on Windows though if SableVM and Classpath implementation becomes quite would be to bundle SableVM with open source browsers such as Mozilla. MS Windows do not come pre-installed with Java (though I think there was a MS vs Sun case). But this could be a long term goal. > And maybe here lies the beauty of this. All these "mediating layer" > solutions are like watering down the solution. To get to the real > stuff, to really say: "We have it *really* ported to MS Win" means > to use maximum of Microsoft tools: OS, Compiler, all Environment. Yes. Agree. David --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Grzegorz B. P. <ga...@de...> - 2004-01-15 03:31:57
|
W liście z śro, 14-01-2004, godz. 17:53, David Bélanger pisze: > First, note that I am not a Windows programmer like most of us. > It may be better to have some Windows programmer comment on what > would be better. /me used to program with Borland C++ and OWL (Object Windows Library) Though it was long ago and you'd better not make too big conclusions based on that. > Maybe what we should ask ourselves is what is the goals with > SableVM/Windows we are actually trying to achieve. Exactly. Though it's not too obvious what the goal could be. As with many ports that nobody is using (are there any SableVM alpha users? ;-) one of possible goals is to _show_ that it's possible and maybe even feasible to use our software on different platform. For *n*x platforms it's rather trivial and has been showed many times already (thought many of the ports could use some polishing of corner cases). But to get SableVM running under Windows, in a manner that would make this experience available to non-developers, is not that trivial. And maybe here lies the beauty of this. All these "mediating layer" solutions are like watering down the solution. To get to the real stuff, to really say: "We have it *really* ported to MS Win" means to use maximum of Microsoft tools: OS, Compiler, all Environment. > I doubt there would be very very little interest for SableVM for end users. > They are much more likely to download a more complete commercial VM. So > we are aiming at developers/researchers here, at least for now. > > I saw several open source project with a Windows version go with a native > Windows port using MS programming tools such as Visual C++. Yes, that's a direction that I'd also like to see explored. Cheers, Grzegorz B. Prokopski -- Grzegorz B. Prokopski <ga...@de...> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org |
|
From: Grzegorz B. P. <ga...@de...> - 2004-01-15 03:11:35
|
W liście z śro, 14-01-2004, godz. 19:20, Chris Pickett pisze: > Actually, I'm sorry. To use pthreads for win32, using MinGW to build, > you need to distribute an extra pthreads dll as well, but my > impression is that the overhead is much less than for the cygwin dll > and it is "closer" to a native port. I don't know about the detailss If you build w/ cygwin you have to distribute at least also cygwin1.dll and probably a bunch of other cyginw libs for the libs that SableVM uses (cygltdl.dll, cygpopt.dll, cygffi.dll, cygsablevm.dll and gnu classpath) because there's no easy way to build a static version of sablevm (and we don't really want to). As for Mingw - I haven't tried it so there's not much of non-obvious things I can say. > of this WSfU thing at all. It seems that no matter what, some > emulation is needed somewhere, unless you want to re-write SableVM to > use Win32 thread stuff (not fun) -- so a truly "native" port isn't > exactly feasible (it would be an option if we did not need pthreads). As for other possibilites - a real native port to Windows has been discussed too (not here though). I also used to think of it as a bit insane and maybe overcomplicated thing, but after seeing how it all went with cygwin, I am sure it's possible. As for WSfU (all the time, I feel like unfolding this abbrv. in a very non-parlamentary manner ;-) I just wanted to point out this possibility. It may cost 99$ today but given the pressure Linux is imposing on M$ I won't be at all surprised if they make it 0$ soon. And I bet it's less than they want for VC++ ? (I don't know the prices though) Obviously - "there's more than one way to do it", and yes - we're talking about Windows ;-) I am not going to argue which approach is the best before we set up some goal of such port which would give us criteria of judgement. I was merely suggesting what interesting possibilities can be explored. Cheers, Grzegorz B. Prokopski [ BIIIIG CUT ] PS: Chris, David, *, could you please remove the unneeded stuff from replies and, when feasible, write replies rather _under_ previous msgs than consequently on top of them? We don't want to look lika an AOL discussion group ;-)) (no offence) -- Grzegorz B. Prokopski <ga...@de...> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org |
|
From: Chris P. <chr...@ma...> - 2004-01-15 00:19:12
|
Actually, I'm sorry. To use pthreads for win32, using MinGW to build, you need to distribute an extra pthreads dll as well, but my impression is that the overhead is much less than for the cygwin dll and it is "closer" to a native port. I don't know about the detailss of this WSfU thing at all. It seems that no matter what, some emulation is needed somewhere, unless you want to re-write SableVM to use Win32 thread stuff (not fun) -- so a truly "native" port isn't exactly feasible (it would be an option if we did not need pthreads). Chris Pickett wrote: > I think that we should not include non-free dependencies, including > non-free programming tools (gcc is available with MinGW, so I don't > see exactly why MSVC++ would be necessary). > > This email makes clear the difference between Cygwin and MinGW -- and > makes a good argument for MinGW because you get a truly native > application at the end (no cygwin.dll is required). > > http://lists.cs.utk.edu/pipermail/lors/2002-December/000440.html > > So ... MinGW + pthreads for win32 sounds like it would work, and > indeed Christian Roy made some progress on that front. Are there > other system things besides pthreads that SableVM needs that aren't > available for Win32? > > Cheers, > Chris > >>Hi, >> >>First, note that I am not a Windows programmer like most of us. >>It may be better to have some Windows programmer comment on what >>would be better. >> >>Maybe what we should ask ourselves is what is the goals with >>SableVM/Windows we are actually trying to achieve. >> >>Also, we need to think about the dependencies. Do we want to depend on >>Cygwin that is freely available, on WSfU (I think required to run even >>compiled binaries, correct me if I'm wrong...) or not having any running >>dependencies. There are also, build dependencies. If we do a native >>port using MS Visual C++ and other tools, then developers are required >>to buy them. Though it is likely they already had a copy. I got a free >>copy from MS at a presentation... The WSfU >>is advertised at US$99 on the web site, though the beta version >>freely available. >> >>I doubt there would be very very little interest for SableVM for end users. >>They are much more likely to download a more complete commercial VM. So >>we are aiming at developers/researchers here, at least for now. >> >>I saw several open source project with a Windows version go with a native >>Windows port using MS programming tools such as Visual C++. >> >> >>David >> >> >>On Tue, Jan 13, 2004 at 09:28:14PM -0500, Grzegorz B. Prokopski wrote: >> >> >>>Hi! >>> >>>I just went over this site >>>http://story.news.yahoo.com/news?tmpl=story&u=/cmp/20040112/tc_cmp/17300376 >>> >>>In short M$ is firing up their own, improved, proprietary cygwin4m$win >>>called "Windows Services for Unix". Disregarding for this moment the >>>moral aspect of using it - why bother with "native" port to Windows [*] >>>when we can probably pretty much "just use" these WSfU (or WS4U). >>> >>>Even if their "up to 90% compliance" is marketing catch - I belive that >>>with rather minimal dependencies of SableVM porting it to this "new >>>platform" might be even easier than the (silently already done) >>>Cygwin port. >>> >>>Just a thought - anybody interested? >>> >>> Grzegorz B. Prokopski >>> >>>[*] This is with assumption that WSfU suck much less than usual windows >>>devel tools. I haven't tried WSfU them so can't really tell. >>> >>>Hmmm.... I still think that real native Windows port would be cool. >>> >>> >>>"When Mahomet told his people that he could call the mountain to him and >>> from the top of the mountain offer his prayers, his people bowed their >>> heads and assembled before him. And Mahomet called to the mountain to >>> come to him, but the mountain did not. And repeatedly again, Mahomet >>> called to the mountain, but the mountain stood still. Finally, >>> appearing neither perturbed nor in the least abashed, Mahomet turned to >>> his people and conceded: 'If the mountain will not come to Mahomet, >>> Mahomet will go to the mountain'." >>> >>>... and so the WSfU became reality ;-) >>> >>>An excerpt from >>>http://www.dommartin.cc/Literature/MuhammedandtheMountain.html >>> >>>-- >>>Grzegorz B. Prokopski <ga...@de...> >>>Debian GNU/Linux http://www.debian.org >>>SableVM - LGPLed JVM http://www.sablevm.org >>> >>> >>> >>>------------------------------------------------------- >>>This SF.net email is sponsored by: Perforce Software. >>>Perforce is the Fast Software Configuration Management System offering >>>advanced branching capabilities and atomic changes on 50+ platforms. >>>Free Eval! http://www.perforce.com/perforce/loadprog.html >>>_______________________________________________ >>>Sablevm-developer mailing list >>>Sab...@li... >>>https://lists.sourceforge.net/lists/listinfo/sablevm-developer >>> >>> >> >> >> |
|
From: Chris P. <chr...@ma...> - 2004-01-14 23:49:39
|
I think that we should not include non-free dependencies, including non-free programming tools (gcc is available with MinGW, so I don't see exactly why MSVC++ would be necessary). This email makes clear the difference between Cygwin and MinGW -- and makes a good argument for MinGW because you get a truly native application at the end (no cygwin.dll is required). http://lists.cs.utk.edu/pipermail/lors/2002-December/000440.html So ... MinGW + pthreads for win32 sounds like it would work, and indeed Christian Roy made some progress on that front. Are there other system things besides pthreads that SableVM needs that aren't available for Win32? Cheers, Chris >Hi, > >First, note that I am not a Windows programmer like most of us. >It may be better to have some Windows programmer comment on what >would be better. > >Maybe what we should ask ourselves is what is the goals with >SableVM/Windows we are actually trying to achieve. > >Also, we need to think about the dependencies. Do we want to depend on >Cygwin that is freely available, on WSfU (I think required to run even >compiled binaries, correct me if I'm wrong...) or not having any running >dependencies. There are also, build dependencies. If we do a native >port using MS Visual C++ and other tools, then developers are required >to buy them. Though it is likely they already had a copy. I got a free >copy from MS at a presentation... The WSfU >is advertised at US$99 on the web site, though the beta version >freely available. > >I doubt there would be very very little interest for SableVM for end users. >They are much more likely to download a more complete commercial VM. So >we are aiming at developers/researchers here, at least for now. > >I saw several open source project with a Windows version go with a native >Windows port using MS programming tools such as Visual C++. > > >David > > >On Tue, Jan 13, 2004 at 09:28:14PM -0500, Grzegorz B. Prokopski wrote: > > >>Hi! >> >>I just went over this site >>http://story.news.yahoo.com/news?tmpl=story&u=/cmp/20040112/tc_cmp/17300376 >> >>In short M$ is firing up their own, improved, proprietary cygwin4m$win >>called "Windows Services for Unix". Disregarding for this moment the >>moral aspect of using it - why bother with "native" port to Windows [*] >>when we can probably pretty much "just use" these WSfU (or WS4U). >> >>Even if their "up to 90% compliance" is marketing catch - I belive that >>with rather minimal dependencies of SableVM porting it to this "new >>platform" might be even easier than the (silently already done) >>Cygwin port. >> >>Just a thought - anybody interested? >> >> Grzegorz B. Prokopski >> >>[*] This is with assumption that WSfU suck much less than usual windows >>devel tools. I haven't tried WSfU them so can't really tell. >> >>Hmmm.... I still think that real native Windows port would be cool. >> >> >>"When Mahomet told his people that he could call the mountain to him and >> from the top of the mountain offer his prayers, his people bowed their >> heads and assembled before him. And Mahomet called to the mountain to >> come to him, but the mountain did not. And repeatedly again, Mahomet >> called to the mountain, but the mountain stood still. Finally, >> appearing neither perturbed nor in the least abashed, Mahomet turned to >> his people and conceded: 'If the mountain will not come to Mahomet, >> Mahomet will go to the mountain'." >> >>... and so the WSfU became reality ;-) >> >>An excerpt from >>http://www.dommartin.cc/Literature/MuhammedandtheMountain.html >> >>-- >>Grzegorz B. Prokopski <ga...@de...> >>Debian GNU/Linux http://www.debian.org >>SableVM - LGPLed JVM http://www.sablevm.org >> >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: Perforce Software. >>Perforce is the Fast Software Configuration Management System offering >>advanced branching capabilities and atomic changes on 50+ platforms. >>Free Eval! http://www.perforce.com/perforce/loadprog.html >>_______________________________________________ >>Sablevm-developer mailing list >>Sab...@li... >>https://lists.sourceforge.net/lists/listinfo/sablevm-developer >> >> > > > |
|
From: David <db...@cs...> - 2004-01-14 22:53:56
|
Hi, First, note that I am not a Windows programmer like most of us. It may be better to have some Windows programmer comment on what would be better. Maybe what we should ask ourselves is what is the goals with SableVM/Windows we are actually trying to achieve. Also, we need to think about the dependencies. Do we want to depend on Cygwin that is freely available, on WSfU (I think required to run even compiled binaries, correct me if I'm wrong...) or not having any running dependencies. There are also, build dependencies. If we do a native port using MS Visual C++ and other tools, then developers are required to buy them. Though it is likely they already had a copy. I got a free copy from MS at a presentation... The WSfU is advertised at US$99 on the web site, though the beta version freely available. I doubt there would be very very little interest for SableVM for end user= s. They are much more likely to download a more complete commercial VM. So we are aiming at developers/researchers here, at least for now. I saw several open source project with a Windows version go with a native Windows port using MS programming tools such as Visual C++. David On Tue, Jan 13, 2004 at 09:28:14PM -0500, Grzegorz B. Prokopski wrote: > Hi! >=20 > I just went over this site > http://story.news.yahoo.com/news?tmpl=3Dstory&u=3D/cmp/20040112/tc_cmp/= 17300376 >=20 > In short M$ is firing up their own, improved, proprietary cygwin4m$win > called "Windows Services for Unix". Disregarding for this moment the > moral aspect of using it - why bother with "native" port to Windows [*] > when we can probably pretty much "just use" these WSfU (or WS4U). >=20 > Even if their "up to 90% compliance" is marketing catch - I belive that > with rather minimal dependencies of SableVM porting it to this "new > platform" might be even easier than the (silently already done) > Cygwin port. >=20 > Just a thought - anybody interested? >=20 > Grzegorz B. Prokopski >=20 > [*] This is with assumption that WSfU suck much less than usual windows > devel tools. I haven't tried WSfU them so can't really tell. >=20 > Hmmm.... I still think that real native Windows port would be cool. >=20 >=20 > "When Mahomet told his people that he could call the mountain to him an= d > from the top of the mountain offer his prayers, his people bowed their > heads and assembled before him. And Mahomet called to the mountain to > come to him, but the mountain did not. And repeatedly again, Mahomet > called to the mountain, but the mountain stood still. Finally, > appearing neither perturbed nor in the least abashed, Mahomet turned t= o > his people and conceded: 'If the mountain will not come to Mahomet, > Mahomet will go to the mountain'." >=20 > ... and so the WSfU became reality ;-) >=20 > An excerpt from > http://www.dommartin.cc/Literature/MuhammedandtheMountain.html >=20 > --=20 > Grzegorz B. Prokopski <ga...@de...> > Debian GNU/Linux http://www.debian.org > SableVM - LGPLed JVM http://www.sablevm.org >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > Sablevm-developer mailing list > Sab...@li... > https://lists.sourceforge.net/lists/listinfo/sablevm-developer --=20 --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Chris P. <chr...@ma...> - 2004-01-14 07:57:55
|
I think a native port would not be too hard, especially given that we have pthreads for win32. I think I have heard of people using cygwin or mingw to build native applications that no longer require cygwin or mingw to run, but that use the pthreads stuff. I might be wrong about this. Cheers, Chris Grzegorz B. Prokopski wrote: >Hi! > >I just went over this site >http://story.news.yahoo.com/news?tmpl=story&u=/cmp/20040112/tc_cmp/17300376 > >In short M$ is firing up their own, improved, proprietary cygwin4m$win >called "Windows Services for Unix". Disregarding for this moment the >moral aspect of using it - why bother with "native" port to Windows [*] >when we can probably pretty much "just use" these WSfU (or WS4U). > >Even if their "up to 90% compliance" is marketing catch - I belive that >with rather minimal dependencies of SableVM porting it to this "new >platform" might be even easier than the (silently already done) >Cygwin port. > >Just a thought - anybody interested? > > Grzegorz B. Prokopski > >[*] This is with assumption that WSfU suck much less than usual windows >devel tools. I haven't tried WSfU them so can't really tell. > >Hmmm.... I still think that real native Windows port would be cool. > > >"When Mahomet told his people that he could call the mountain to him and > from the top of the mountain offer his prayers, his people bowed their > heads and assembled before him. And Mahomet called to the mountain to > come to him, but the mountain did not. And repeatedly again, Mahomet > called to the mountain, but the mountain stood still. Finally, > appearing neither perturbed nor in the least abashed, Mahomet turned to > his people and conceded: 'If the mountain will not come to Mahomet, > Mahomet will go to the mountain'." > >... and so the WSfU became reality ;-) > >An excerpt from >http://www.dommartin.cc/Literature/MuhammedandtheMountain.html > > > |
|
From: Grzegorz B. P. <ga...@de...> - 2004-01-14 02:28:21
|
Hi! I just went over this site http://story.news.yahoo.com/news?tmpl=story&u=/cmp/20040112/tc_cmp/17300376 In short M$ is firing up their own, improved, proprietary cygwin4m$win called "Windows Services for Unix". Disregarding for this moment the moral aspect of using it - why bother with "native" port to Windows [*] when we can probably pretty much "just use" these WSfU (or WS4U). Even if their "up to 90% compliance" is marketing catch - I belive that with rather minimal dependencies of SableVM porting it to this "new platform" might be even easier than the (silently already done) Cygwin port. Just a thought - anybody interested? Grzegorz B. Prokopski [*] This is with assumption that WSfU suck much less than usual windows devel tools. I haven't tried WSfU them so can't really tell. Hmmm.... I still think that real native Windows port would be cool. "When Mahomet told his people that he could call the mountain to him and from the top of the mountain offer his prayers, his people bowed their heads and assembled before him. And Mahomet called to the mountain to come to him, but the mountain did not. And repeatedly again, Mahomet called to the mountain, but the mountain stood still. Finally, appearing neither perturbed nor in the least abashed, Mahomet turned to his people and conceded: 'If the mountain will not come to Mahomet, Mahomet will go to the mountain'." ... and so the WSfU became reality ;-) An excerpt from http://www.dommartin.cc/Literature/MuhammedandtheMountain.html -- Grzegorz B. Prokopski <ga...@de...> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org |
|
From: David <db...@cs...> - 2004-01-13 06:34:54
|
Hi,
SableVM/staging was broken for multithreaded stuff after the
integration of Thread/VMThread (CP 0.06 -> 0.07 merge). I fixed
a few problems and should be better now. I wrote that email 2 days ago
but forgot to sent it...
I also checked in an implementation of Monitor{Enter,Exit}, bug for
ThrowNew that I did some time ago.
The VMThread/Thread/SableVM integration would need quite some cleanup
and restructuration before moving it to SableVM/bugfree, it is currently
a mixture of old Classpath/Etienne implementation with new
Classpath implementation. Any volunteer is welcome.
David
---
David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226
Web page: http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt
|
|
From: Archie C. <ar...@de...> - 2004-01-13 03:27:47
|
Etienne, In _svmf_stopping_java(), if the current thread is in state SVM_THREAD_STATUS_HALT_REQUESTED you halt it by calling _svmf_halt_if_requested(). Is this really necessary? Couldn't you just change the thread's state to SVM_THREAD_STATUS_NOT_RUNNING_JAVA_RESUMING_DISALLOWED and let it continue? If it tries to return to Java mode later, then it would have to halt of course. Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Halloo Communications * http://www.halloo.com |
|
From: Grzegorz B. P. <ga...@de...> - 2004-01-07 03:37:38
|
Hi Mark and everybody, I am attaching *introduction* (not an abstract, at least not this time) to the talk I am going to give at FOSDEM [*] in Debian/Free Java room. This may or may not make it into some prospective web page for Java room - so it's just to give you idea what's in store. Beware - the real meat begins near the end of this introduction :-) Cheers, Grzegorz B. Prokopski [*] http://www.fosdem.org/ 21-22 Feb 2004, Brussels Belgium PS: Crossposting to SableVM ML for obvious reasons, to GNU CP as the forum where Java room at FOSDEM was actively discussed and to debian-java, as we're to share room with Debian people (huh, I'll have to share room with myself! ;-) and apparently the areas of interest actually overlap. -- Grzegorz B. Prokopski <ga...@de...> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org |
|
From: David <db...@cs...> - 2004-01-06 18:53:42
|
Hi, I find though that the word "Sable" is somewhat small... David On Tue, Jan 06, 2004 at 07:25:17PM +1300, M.Negovanovic wrote: > Hi, >=20 > just to say that triangle logo looks cool ;)! >=20 > Regards > Milos >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM= 's > Free Linux Tutorials. Learn everything from the bash shell to sys admi= n. > Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick > _______________________________________________ > Sablevm-developer mailing list > Sab...@li... > https://lists.sourceforge.net/lists/listinfo/sablevm-developer --=20 --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Chris P. <chr...@ma...> - 2004-01-06 09:34:50
|
Personally I would like something that tied into the whole Soot and Ashes thing ... maybe a train or an engine that runs on coffee beans (there's little beans in the Sable logo, and the VM is definitely an engine, although there's probably inconsistencies in the analogy somewhere). Pinkish triangles also have other connotations. Just my 2 cents :) Chris M.Negovanovic wrote: >Hi, > >just to say that triangle logo looks cool ;)! > >Regards >Milos > > >------------------------------------------------------- >This SF.net email is sponsored by: IBM Linux Tutorials. >Become an expert in LINUX or just sharpen your skills. Sign up for IBM's >Free Linux Tutorials. Learn everything from the bash shell to sys admin. >Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click >_______________________________________________ >Sablevm-developer mailing list >Sab...@li... >https://lists.sourceforge.net/lists/listinfo/sablevm-developer > > > |
|
From: M.Negovanovic <mi...@xt...> - 2004-01-06 06:26:04
|
Hi, just to say that triangle logo looks cool ;)! Regards Milos |
|
From: David <db...@cs...> - 2004-01-05 04:52:29
|
Hi, ok. It is now in staging. David On Sun, Jan 04, 2004 at 11:43:28AM -0500, Etienne Gagnon wrote: > David B=E9langer wrote: > >Hi, > > > >I fixed 3 bugs about the class loader memory manager. 2 were reported > >a long time ago and a 3rd one found today. > > > >Etienne, you may want to have a quick look to see if everything is okay > >before I check it to staging. > > > >Basically: > >1) New mem blocks malloc() were not added to the allocated block list. >=20 > Right. >=20 > >2) init_cl_alloc was called only for the bootstrap class loader. Note: > >Even if init_cl_alloc is not called, everything works fine as no blocks > >have ever been allocated, cl_alloc will allocate a new one. So, > >function init_cl_alloc is not absolutely needed... I still add a call > >for the other class loaders. >=20 > In fact, the call was missing. >=20 > >3) While doing #2, I saw that the class_loader_info is freed on error > >but not removed from the list. I fixed it by moving the addition to the > >list at the end. >=20 > Right. >=20 > Thanks, >=20 > Etienne >=20 > --=20 > Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ > SableVM: http://www.sablevm.org/ > SableCC: http://www.sablecc.org/ >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=CCk > _______________________________________________ > Sablevm-developer mailing list > Sab...@li... > https://lists.sourceforge.net/lists/listinfo/sablevm-developer >=20 --=20 --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Etienne G. <gag...@uq...> - 2004-01-04 16:53:25
|
David B=E9langer wrote: > Hi, >=20 > I fixed 3 bugs about the class loader memory manager. 2 were reported > a long time ago and a 3rd one found today. >=20 > Etienne, you may want to have a quick look to see if everything is okay= > before I check it to staging. >=20 > Basically: > 1) New mem blocks malloc() were not added to the allocated block list. Right. > 2) init_cl_alloc was called only for the bootstrap class loader. Note:= > Even if init_cl_alloc is not called, everything works fine as no blocks= > have ever been allocated, cl_alloc will allocate a new one. So, > function init_cl_alloc is not absolutely needed... I still add a call > for the other class loaders. In fact, the call was missing. > 3) While doing #2, I saw that the class_loader_info is freed on error > but not removed from the list. I fixed it by moving the addition to th= e > list at the end. Right. Thanks, Etienne --=20 Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Etienne G. <gag...@uq...> - 2004-01-04 04:01:07
|
Late but done. (At least it's in my sandbox right now and will be propagated to staging). Really like your changes, Thanks Etienne PS: I added you name to AUTHORS. :-) Patrick Cernko wrote: > Also sprach Etienne Gagnon zu "19.12.2003 22:31" Anno Domini: > >>Hi Patrick. >> >>Thanks for the patch. Before committing it, I need your confirmation >>about the following, about this contribution and future ones: >> >>1- You are in a clean-room status, regarding contribution to a Java >>virtual machine. > > > ACK! > > >>2- You are the copyright holder of your contributions (e.g. not your >>employer or school). > > > ACK! > > >>3- You retain copyright ownership on your contributions, but you license >>them >> under the terms of the GNU LGPL. > > > ACK! > > >>4- You grant me the permission to modify or add clarifications to the >>license if the >> needs for it shows at some point; modifications and clarifications >>(if any) will be in the spirit >> of the Free Software definition >>(http://www.gnu.org/philosophy/free-sw.html) and >> the Debian Free Software Guidelines >>(http://www.debian.org/social_contract#guidelines). >> > > > ACK! > > >>Alternatively to 2, 3, and 4, you can put your contributions in the >>public domain, of course. > > > If you prefer, of course, you can take _these_ changes as public domain. > I do not invented a great algorithm improving your Makefiles. :-) > > But I reserve the right for me, to no publish further patches in public > domain but under the conditions 1-4. As I am writing my deiploma thesis > about a JVM (see my homepage), it might be, that I make some really > semantics-changing patches/enhancments! > > >>Sorry for annoying you with these legal related questions, but I have to >>do it >>once for every contributor... >> > > > I can understand this clearly. I just _have_ a problem with copyright of > code I wrote and published under LGPL. > > >>Patrick Cernko wrote: >> >> >>>So I digged out my autotools knowledge and made a patch to be able to >>>build sablevm in a directory different from the sources (this way my >>>checked out sources stay mostly "clean" -- only "poluted" by the files >>>generated from the autotools chain. >> >> >>An auto* knowledgeable person: it's so nice to have one around. Great! >> > > > Don't count on me. I just wanted to compile sablevm in _my_ _style_. I'm > not sure, if I will have time for helping as my diploma thesis is taking > all. But ask if you have a problem. At minimum, I will say "No time > now". :-) > > >>>I hope the patch can make it into the svn. >> >> >>As soon as I get your reply to the annoying legal question above, I'll >>do it. >> > > > Well, here it is! :-) > > CU/all -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: David <db...@cs...> - 2003-12-31 01:26:53
|
Hi, I fixed 3 bugs about the class loader memory manager. 2 were reported a long time ago and a 3rd one found today. Etienne, you may want to have a quick look to see if everything is okay before I check it to staging. Basically: 1) New mem blocks malloc() were not added to the allocated block list. 2) init_cl_alloc was called only for the bootstrap class loader. Note: Even if init_cl_alloc is not called, everything works fine as no blocks have ever been allocated, cl_alloc will allocate a new one. So, function init_cl_alloc is not absolutely needed... I still add a call for the other class loaders. 3) While doing #2, I saw that the class_loader_info is freed on error but not removed from the list. I fixed it by moving the addition to the list at the end. Patch is attached. David --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Chris P. <chr...@ma...> - 2003-12-27 15:11:20
|
Hello again,
So ... it turns out an exception was being thrown in the non-speculative
code, and the method did not exit normally, which made the later join
invalid.
I'd already prevented against throwing exceptions speculatively, but
hadn't thought that throwing an exception non-speculatively would
invalidate any children. Perhaps there is a way to throw exceptions in
the parent and not always need to invalidate speculative children, but
I'll leave that for later.
Cheers,
Chris
Chris Pickett wrote:
> Hi,
>
> I have some problem with my SpMT stuff, and I would like to know if
> I'm observing the correct behaviour. In trying to get the Jack
> benchmark to run, I turned off many features of my SpMT code. My code
> still does some state saving and restoring though, which involves:
>
> to save:
>
> 1) saving the current pc
> 2) saving the current stack_size
> 3) copying the entire stack from stack.start to stack.end
> 4) saving the current *locals (adjusted)
> 5) saving the current *stack (adjusted)
> 6) saving stack.current_frame (adjusted)
>
> to restore:
>
> 1) pc = saved pc
> 2) stack_size = saved stack_size
> 3) *locals = saved *locals
> 4) *stack = saved *stack
> 3) stack.current_frame = saved stack.current_frame
> 4) stack.end = saved stack.end
> 5) stack.start = saved stack.start
>
> Here's the problem:
>
> At every invokevirtual that returns void, I first save the state
> ("non-speculative"). Then I skip forward over the invokevirtual,
> adjust the stack_size to account for method parameters being popped,
> and immediately save the state ("speculative"). Then I restore the
> non-speculative state and execute the method. When I return from the
> method, as determined by the height of env->stack.current_frame
> returning to the height of the frame before the invokevirtual, I
> should (according to what I originally thought, at least) have an
> execution state that's identical to the saved speculative state
> (remember that the method is void). Normally I can restore this state
> and keep executing without any problem, but in Jack I get errors if I
> try to do so. If I instead restore the state by copying the entire
> saved stack over the execution stack (and freeing the saved copy
> instead of freeing the original), I still get problems -- so I know
> it's not because of external pointers into the stack. Furthermore, if
> I decide not to restore the "speculative" state after execution but
> keep going with the previously restored "non-speculative" state, I
> don't get any errors at all -- which indicates that there's not
> problems with the state-saving code in itself.
>
> My question is ... is it possible for the caller frame to be modified
> before returning from the callee, if the callee returns void?
>
> I did some experiments, comparing (_svmt_stack_value *)->jint by
> (_svmt_stack_value *)->jint, and it turns out that the saved
> speculative stack is not identical to the stack after returning from
> the call, at a couple of positions. I'm really at a loss to explain
> this, any pointers would be greatly appreciated ...
>
> Cheers,
> Chris
>
> P.S. Merry Christmas and Happy New Year everyone! :)
>
>
>
>
|
6 messages has been excluded from this view by a project administrator.
