e
tried to follow the JVM Spec.)
While you can construct bad cases that make Coglio-style verifiers
very slow, I'd be surprised if the verifier generally shows up high in
profiles. (Our profiles tend to omit the verifier for other
+1
On 3/17/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> Thanks Etienne -- all opinions welcome!
>
> Etienne Gagnon wrote:
> > If non-members have any say, I'll add a +1. If not, ignore this... ;-)
> >
> > Etienne
> >
> > Stefano Mazzocchi wrote:
> >>> This opens up so many new opportunities for c
Thanks for checking that out! About (2): From what I am seeing these
days it is important to support ARM. BTW, where did you get this
information about ports not being available please? I did not find a
"porting page".
Enrico Migliore wrote:
Stefano wrote:
I think we would gain a lot of va
7;s javadoc goes... in my experience you can't really call
it a "spec" with a straight face. It omits far too much.
Tom
ns to check for.
I'd say to look at APR before spending a lot of time on configury
though.
Tom
ditional VMs, where native has a
different meaning, i.e. IKVM, or Jaos, or the oberon-based VM (I
forgot the name of that one, sorry).
Tom
Geir> What's an activation record?
Compiler speak for a stack frame.
http://en.wikipedia.org/wiki/Activation_record
Tom
mportant as the
Steve> industry moves to multicore.
What do you mean when you say "non-reentrant JIT"? A JIT that has
global variables and assumes it is only running in one thread at a
time? Or a JIT that assumes that it won't be interrupted (in a given
thread) to do some other piece of work? Or maybe something else?
Tom
ns. The difficulty
here is that bug fixes to the shared code must be manually merged.
This turns out to be more work than we originally thought it would be;
in general these days I try to push us to follow Classpath more
closely for this reason.
Tom
re's no bad (i.e., security violating) situation that can arise
from this. It is no different from Sun adding any other class that is
not yet implemented in Classpath.
Tom
*/
Typically it is simpler to unify the exception handling code so that
internally generated exceptions (e.g., an NPE) are thrown using the
same mechanism as user-code-generated exceptions. In other words, I
think you're going to want an object reference here.
Tom
ntaining this file is not a big deal.
The actual code in the x86 linux version of the file in Classpath
amounts to 13 lines.
Tom
ould require not only recompiling libc,
but also any JNI code that might be used, plus any libraries used by
this JNI code. As an example, consider the Gtk peers used by
Classpath's AWT... to do this you're talking about rebuilding a large
part of a typical distro.
Tom
a lot of code around a lot of platforms,
Dan> but I'm interested hear how other folks have solved
Dan> problems like this.
AFAIK the typical approach for struct packing is to do nothing and let
the target platform's headers sort it out. We never had to do
anything in this area for libgcj, and a quick grep through kaffe shows
that it doesn't need this either (aside from one unusual case).
More generally this is why APR is nice to have :-)
Tom
h Microsoft on
Andy> that one. It took me awhile...but checked exceptions do more harm
Andy> than good.
This is a java->bytecode compiler issue, not a runtime issue.
Checked exceptions are only checked by the compiler, not by the VM.
Tom
Michael> Sorry for being off-topic,
IMO not offtopic as we're discussing what to do, and this is an option.
Tom
choice of execution engine up
front; so the "fast JIT" and the "optimizing JIT" are just part of the
same code base and only need to talk to each other, and can be built
in an ad hoc way.
Personally I'd be just as happy if we only had a JIT. There are
already plenty of interpreters out there.
Tom
>>>>> "David" == David Tanzer <[EMAIL PROTECTED]> writes:
David> * Kaffee:
David>- [EMAIL PROTECTED]
Just one 'e': "kaffe".
There's also the gcj lists:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Tom
h libgcj suggests that OS porting layer has few tricky
parts[1]. The bulk of the code -- file and network I/O, for instance --
is simple and porting it doesn't represent a major effort. I think our
"posix" port (includes linux, solaris, macos x) is about 4 KLOC. The
Windows-spec
target to get the JVM to run. This will help to use Harmony with
different bootpaths later on. For example, the VM will not require
libraries for X-Path and database operations, or will it? (They seem to
be required to run libapr0 in your link)
Thanks
Tom
Joerg Wendland wrote:
*unlurk*
Hi
)
So, rather encouraging, but if someone could post his own experience on
porting APR this would certainly be more helpful than my Google-guessing.
Thanks
Tom
Ricardo Morin wrote:
Hi,
I updated the "Modular Structure JVM Components"
section of the architecture document with
versions of some core
classes like String and Object. We periodically have to merge over
bug fixes and javadoc and the like. It seems to me that the other
classpath-using VMs have it simpler here, as they just require the
occasional tweak to their VM classes.
Let me know if you want more info.
Tom
rget).
I'm not sure what this means for your breakdown ... would these
classes need to be in the same bundle?
Tom
problems still to be resolved "the right way" (I just hacked the
PJ> makefiles to get it to build, and had to use Fink to get many of the
PJ> requirement packages, as they weren't part of the base OSX full dev
PJ> tools install.)
Did you try disabling the gtk peers?
Portability fixes (for the build or for the JNI code or whatever) are
also welcome.
Tom
; download and compile these packages directly
Dan> instead of using the www.sunfreeware.com versions,
Dan> I have _not_ succeeded.
Dan> Has anybody successfully compiled GNU Classpath 0.1x
Dan> on a Solaris platform?
Please file bug reports.
Also, try configuring with --disable-gtk-peer to avoid compiling the
gtk peers.
Tom
e discussed a little is writing new FindBugs checks to
look for the required security calls. But this doesn't protect us
from bugs in the native code or bugs allowing access to non-standard
weird things that shouldn't be generally accessible (we have some
interesting code in gnu.gcj.*).
Tom
Date:06/28/05
Location:Thirsty Bear, San Francisco, CA
Present:
Geir Magnusson
Flavio Bergamaschi
Ian Darwin
Weldon Waschburn
Tom Enderes
[Geir] Start off with codebase from Dan Lydicks VM ?
[Flavio] Need proper SE Process?
[Flavio
PJ Cabrera wrote:
On 6/28/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> When and where shall we meet?
>
> I suggest the Thirsty Bear, just a block away from Moscone. We can
> try during the day, or at night, but to start...
>
> 8pm Tuesday, June 28?
That sounds good to me, as this
ibute.
The former are typically needed internally but the latter are needed
in some situations (Class.newInstance I think).
Tom
+1 and just looked at the schedule:
Tuesday evening is not good as it overlaps with the open JCP evening
which goes on till 9pm.
Monday and Wednesday are some receptions / bashes (which I personally
wouldn't mind skipping), and Thursday seems open, so perhaps Thursday?
PS: I have a Pavilio
won't need any major overhauls, just additions
here and there. But if someone wanted to go through all the new bits
and check this, that would be helpful. Better yet, actually go write
the new bits, there is plenty of 1.5 stuff still to be done.
Tom
gt; adds it as a private class (not so farfetched).
Ok, this is the scenario. This I understand.
But what actual problem does this cause?
Tom
e. The VMs have to change, but then the VMs have to change with
each major release anyway, since ordinarily new features are added
which require new VM glue.
Tom
nnot get around the access controls, even with reflection.
Geir> Why would I have to "get around" the access controls? I'm the VM. I
Geir> can do magic things, right? (I should be able to...)
I thought we were talking about malicious user code.
Tom
ime to time the VM interface has to be extended for new
VMs, which have different needs. This is one reason that the
interface isn't yet stable, even for 1.4.
Tom
ding an extension to the
semantics of 'ldc'.
Tom
hen, I'm not really getting this part of the discussion. For
instance, why does Harmony need a VM layer different from the one
Classpath provides? I don't understand that.
Tom
gt; implementation of java.lang?
Sven> Why wouldn't it be possible? It'd be horrible coding if it were
Sven> any other way.
Totally agreed. Most code in Classpath doesn't use native code, or VM
code, or anything but the public API of classes in other packages.
Tom
tack
caching, superinstructions, scheduling, whatever new stuff they've
come up with...)
Tom
e Classpath VMObject, due to the access protection. So
failures "the other way" aren't possible.
Geir> I'd like to drive to a standard interface that we can all agree on,
Geir> and hopefully GNU Classpath will support it.
Experience has shown that the Classpath approach is pretty flexible.
A wide range of VMs already use it. Also we're pretty open to
specific needed changes.
Tom
now at the very heart of gcj.
This is hard for the reasons outlined before.
Tom
It does not
however, since it is about 100 times less work to maintain vcproj and sln
files opposed to makefiles (at least in my oppinion) it just comes with
build files for the commercially most used compiler in the world.
Anyway, anyone with knowledge about ant or makefiles could get the thin
petitive
performance wise. E.g., starting eclipse has to be reasonable both in
time and space.
3. Debugging. There has to be some debugger story.
Harmony would have to excel on all of these before I would even
consider, say, recommending it for FC.
Tom
ld rip pieces of GCC out and construct a more traditional
acoliver> JIT, but its really not what we want.
Probably more profitable to simply integrate a JIT into libgcj.
Tom
ly ported as it is; the core gcj developers hardly ever do any
architecture-specific work but instead we just inherit it from GCC.
Tom
umed by the core? E.g., does the JIT itself rely crucially on
exception handling? Garbage collection?
The reason I ask is that I'm curious about how minimal a system can be
made with JikesRVM.
Tom
Stefano> compiler intermediate representation instead of having to write a big
Stefano> string using C syntax and fire a parser on it.
Stefano> Does anybody know if GCC allows such a thing?
It already exists -- you're describing gcj.
Tom
nt: Wednesday, May 18, 2005 3:40 PM
Subject: Re: [arch] mudGE VM ( was Re: [arch] VM Candidate : JC @
http://jcvm.sourceforge.net/)
> Oh, never mind. I didn't RTFM (I did, but missed the top section...)
>
> geir
>
> On May 18, 2005, at 9:14 AM, Geir Magnusson Jr. wrote:
>
&g
s-build the VM from another machine that it does
work on. This is one way people bring up GCC on a new machine as
well.
Tom
ble to require
compile-time choices.
So, in this case, it isn't as if we would have to design an allocation
interface that allows all possible choices. It can merely allow the
subset we know to be immediately usable.
Tom
ization compatibility
tests, and the 'wonka' module which holds the Acunia visual tester
(tests AWT functionality).
Tom
to be notified about what happens to my code
and who uses it.
Tom van Dijck
mudGE Entertainment
> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 18, 2005 6:35 AM
> To: harmony-dev@incubator.apache.org
> Subje
reading through it. ORP already solved these problems in a
fairly reasonable way.
Tom
, which is the actual VM. Then you can run your java
programs using this image.
Once you have the infrastructure for this, setting it up for
cross-building (cross architecture or cross OS) is not theoretically
hard, merely a SMOP.
It looks like JikesRVM already has some support for this:
http://jikesrvm.sourceforge.net/userguide/HTML/userguide_8.html
Tom
e is probably enough knowledge here to
succeed at this part of the effort.
Rodrigo> I believe the focus should be on deciding if Harmony will star from
Rodrigo> other JVM or not.
And in addition, deciding what the goals are. You wouldn't want to
pick a starting point that doesn't take you where you want to go.
Tom
he
Subject.
Development proceeds (as with Apache I suppose) according to each
developer's interest. Lately those of us at Red Hat have mostly been
working to get some specific big java applications working: eclipse,
tomcat, ant, their many dependencies, jonas, and OO.o. This mostly
seems to mean bug fixing and minor additions here and there.
Tom
ibgcj uess. Usually this just means
disabling things.
... But once you do this you run into all the other reasons binary
interoperability is hard; my looks into LLVM, ORP, and Kaffe all
failed due to disagreement over exception handling.
Tom
compilation
* Configurable VM means it is simpler to target the small machine
embedded scenario
* Re-use somebody else's compiler framework. For AOT, re-use lessons
learned by gcj.
Tom
[1] http://lists.gnu.org/archive/html/classpath/2004-01/msg00033.html
[2] http://www.llvm.org/
>>>>> "Ben" == Ben Laurie <[EMAIL PROTECTED]> writes:
Ben> Tom Tromey wrote:
>> * Fragmentation. I think there are too many free JVMs. In particular
>> the "C/C++-based VM" niche is over-full. It ought to be possible,
>> though
OS/Hardware.
You are correct. Any VM will always need a way to call system
functions somehow, and on Linux/Windows/etc, this means C ABI calls.
Depending on the approach one chooses, some kinds of APIs are simpler
to wrap than others, but I think this is not a major issue.
Tom
ng developed, then it is another good choice. Basically
the message is, unless a particular license is a hard requirement,
there is little reason to write a java compiler.
Tom
GCJ's binary ABI
Rodrigo> without been GPL?
I'm sure that wouldn't be a problem.
I think it is no different from, say, replacing libgcc, which some
people do.
Tom
of gcc at all. It is
written in C++.
kjc is also out there and being developed, but I don't know much about
it.
Tom
r, GCJ was not "drop-in" compatible with
Bob> Sun's javac. You cannot just take an Ant script and replace "javac"
Bob> with "gcj" and have it all work.
This is the role that the java-gcj-compat package fills.
jpackage-style alternatives basically solve all the problems in this
area.
Tom
rtified. Change the build, lose
the cert. I doubt it matters much where the sources come from, as
long as the build passes.
Tom
tc... is thought.
Rewriting Classpath's native code in terms of APR should be trivial
for a motivated someone. We're talking about 10 KLOC as counted by wc.
Tom
; byte[] representation in a database of
known-valid classes, and then only does the full verification if it is
not seen. (This is not completely trivial due to class loading
oddities, but it could be done by deferring some kinds of type
checking, as gcj does.)
Tom
ll, uhm... I would be more then happy to share and learn, in case of
interest that is.
Tom van Dijck
Research & Development
Playlogic Game Factory
www.playlogicgames.com
free compilers
>> and runtimes properly support the new 1.5 language features.
Henri> Are any enums in the JDK being held off on for the same reason? (only
Henri> one I noticed was java.math.RoundingMode).
There are already other enums on the generics branch.
Anything missing there is just because nobody has gotten around to
writing it yet.
Tom
things to compile, but then the stubs fail at runtime.
This is a pain because the stubs don't show up as bugs in the API
comparison. We generally avoid this except for unusual circumstances,
though.
Tom
My hope is that we
Dalibor> can then just plug into JacORB for the backend.
Yeah. Also, note that all the missing parts of java.math are new in
1.5. It helps to look at the 1.4 comparison as well, to see what is
historically missing and what is just new.
Tom
ractice it is probably necessary to get acceptable
performance.
Without a verifier you must track the types of everything on the stack
and in local variables (if you have a verifier you don't need to do
this), and do assignability checks on arguments to all method calls,
qualifying reference for a field lookup, etc.
Tom
We have even written the compiler
to emit type assertion tables, to duplicate the runtime effects of
verification (without the expense).
I'm not trying to push gcj here, and this doesn't eliminate other
reasons one might prefer JITting... I just wanted to avoid propagating
inaccuracies.
Tom
om the JikesRVM angle... I won't speculate here, though, since
I'm not really involved with that project.
Maybe it seems like a grim environment for starting a new project.
Well, considered on technical grounds alone, it is. One needs a
pretty compelling technical story to do better than already existing
projects.
Tom
completely independent. You can see some discussion of a few of the
issues in this thread:
http://lists.gnu.org/archive/html/classpath/2004-01/msg00033.html
It would be nice to have some kind of reusable, configurable core VM.
Perhaps we could eliminate one of the current areas of divergence this
way, by letting (eg) kaffe/sable/jamvm/libgcj share more bits.
Tom
ces. Most of the wire-protocol at least can be
Mark>shared. I have some designs for that, but I forgot who is
Mark>working on this for gcj.
The documents for this still haven't been released; I'll try to push
on that again.
Tom
76 matches
Mail list logo
