> "Pavel" == Pavel Rebriy <[EMAIL PROTECTED]> writes:
Pavel> There are several virtual machines in Harmony project and none
Pavel> of them provides subroutine verification for Java bytecode. I
Pavel> would like to discuss appropriate methodology of subroutine
Pavel> verification.
Pavel> The q
> "Mikhail" == Loenko, Mikhail Y <[EMAIL PROTECTED]> writes:
Mikhail> I think Classpath is a little bit different story. It is not
Mikhail> a Java(tm) so a developer who writes for Classpath has to
Mikhail> validate with Classpath docs whether his code is going to
Mikhail> work.
The real reas
> "Archie" == Archie Cobbs <[EMAIL PROTECTED]> writes:
Archie> Great! What O/S are you using? Do you know a good ./configure test
Archie> for whether "-ldl" is required?
The usual thing is to pick whatever symbol is used by the package and
do a series of AC_CHECK_LIB calls. The original post
> "Tim" == Tim Ellison <[EMAIL PROTECTED]> writes:
Tim> I read the description of CNI here:
Tim>http://gcc.gnu.org/onlinedocs/gcj/index.html
Tim> Is there some description of how this looks from the Java side? Are the
Tim> natives declared as CNI natives somehow, or does the VM go throug
Geir> What's an activation record?
Compiler speak for a stack frame.
http://en.wikipedia.org/wiki/Activation_record
Tom
> "Steve" == Steve Shih-wei Liao <[EMAIL PROTECTED]> writes:
Steve> Harmony JVM needs to be designed to support non-reentrant JITs
Steve> as a default. It also needs to be designed to take advantage
Steve> of reentrant JITs. This is particularly important as the
Steve> industry moves to multi
> "Graeme" == Graeme Johnson <[EMAIL PROTECTED]> writes:
Graeme> Split-class (ClassX & VMClassX) or customized-class solutions (Tim E's
Graeme> Kernel classes) are different approaches to solving the same problem.
Graeme> Of the two approaches I believe that the customized-class solution
Gr
> "Matt" == Matt Benson <[EMAIL PROTECTED]> writes:
>> I don't understand this (sorry if I wasn't paying attention
>> earlier). If "extend" means defining public API's in those
>> packages, then Classpath doesn't purport to do that. The
>> java.lang.VMClass, etc. stuff are all internal API's
> "Dan" == Apache Harmony Bootstrap JVM <[EMAIL PROTECTED]> writes:
Dan> I agree that the verifier should look into this, but what happens if
Dan> you get a divide by zero error? Or a null pointer exception? These
Dan> are not available to the verifier, but are runtime conditions that
Dan> d
> "Dan" == Apache Harmony Bootstrap JVM <[EMAIL PROTECTED]> writes:
Dan> Another thought about the '__int64' issue. A friend told
Dan> me a while back that this symbol was typedef'ed in a
Dan> header file called 'stdint.h' on GCC, but this does not
Dan> exist on my Solaris box, and I didn't n
> "Enrico" == Enrico Migliore <[EMAIL PROTECTED]> writes:
Enrico> Since we got GNU libc code, my suggestion is, for each
Enrico> architecture, compile _ALL_ the C code with the same set of C
Enrico> flags, including the libc.
Enrico> In this way, the libc and the VM will be a monolithic
Enric
> "Dan" == Dan Lydick <[EMAIL PROTECTED]> writes:
Dan> It has been my experience that permitting structures to remain
Dan> _unpacked_ produces compatibility problems.
Dan> My use of GCC 3.3.2 on Solaris 9 seemed to confirm
Dan> this when all library and system calls worked fine
Dan> except fo
> "Andy" == acoliver <[EMAIL PROTECTED]> writes:
Andy> A principle reason for {} scoping is that it allows register
Andy> allocation ; however, it is practically useless in the above. 9/10
Andy> you're going to have to put "myvar" in at least method scope so that
Andy> you can get at it outs
> "Michael" == Michael Haupt <[EMAIL PROTECTED]> writes:
Michael> couldn't startup time be increased by caching native code versions of
Michael> methods somewhere on the hard disk and loading instead of compiling
Michael> them every time the VM is started up?
Yeah, startup can be improved thi
> "Geir" == Geir Magnusson <[EMAIL PROTECTED]> writes:
>> On the other hand, a fast code-generating JIT can call runtime
>> helpers and native methods without additional glue code whereas an
>> interpreter has to have special glue code to make it work in a JIT
>> environment.
Geir> I believe
> "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
On Tue, 2005-08-30 at 20:34 +0800, Xiao-Feng Li wrote:
> Hi, Ron, I think your concern is valid. We fully understand POSIX has
> been and is being used widely. That's why we want to have a discussion
> here. APR does have some features a JVM may need in all platforms,
> such as atomic operations, w
> "Geir" == Geir Magnusson <[EMAIL PROTECTED]> writes:
Geir> But on a serious note, would it be possible for someone to give a
Geir> good technical description of the GNU Classpath VM interface so that
Geir> people who aren't aware and for whatever reason can't read it on the
Geir> classpath s
> "Tim" == Tim Ellison <[EMAIL PROTECTED]> writes:
Just some random thoughts on this.
Tim> The goal is to (a) stimulate discussion, and (b) think about the
Tim> components that we should declare with well-defined interfaces to other
Tim> components (I'm thinking of OSGi bundles here).
In mos
> "PJ" == PJ Cabrera <[EMAIL PROTECTED]> writes:
PJ> And a big problem it is. If we go with GNU Classpath as the basis of
PJ> the Harmony API, AWT and Swing will depend on GTK+ 2.4 being installed
PJ> on OSX, through DarwinPorts or Fink.
There is nothing stopping anybody from writing peers th
> "Dan" == Dan Lydick <[EMAIL PROTECTED]> writes:
Dan> Yea-- painful is the word. I have tried it
Dan> on a Solaris 9 platform and keep getting
Dan> rather confusing errors on packages, namely
Dan> GTK, GLIB, and LIBICONV. Even when I try to
Dan> download and compile these packages directly
> "Ben" == Ben Laurie <[EMAIL PROTECTED]> writes:
Ben> I can't think of _any_ other interesting security properties that Java
Ben> has and C lacks. Am I missing something?
Probably not. At some point any VM has to do untrusted things. There
may be reasons that this "window" is bigger or sma
> "Weldon" == Weldon Washburn <[EMAIL PROTECTED]> writes:
Weldon> Below is a first stab at the API to retrieve the values
Weldon> contained in internal classloader data structures.
Weldon> Comment/questions are appreciated.
Weldon> Class access and property modifiers (table 4.1)
Weldon> bool
> "Geir" == Geir Magnusson <[EMAIL PROTECTED]> writes:
>> Yes, 1.5 *will* add new requirements to the VM interface. But the
>> Classpath VM interface isn't some immutable static thing either.
>> All I'm saying here is: how about crossing that bridge when you get
>> there, instead of deciding o
> "Geir" == Geir Magnusson <[EMAIL PROTECTED]> writes:
>> I still don't understand why you think this.
>> Could you explain what problem might arise?
Geir> Sun adds "java.lang.VMObject" as a public class (ok, farfetched) or
Geir> adds it as a private class (not so farfetched).
Ok, this is th
> "Geir" == Geir Magnusson <[EMAIL PROTECTED]> writes:
>> What do you mean by "extending java.lang"? GNU Classpath does not
>> extend java.lang (for any reasonable definition of extend). Having
>> package private classes is not extending.
Geir> Why do you say that? Suppose for J2SE 6, the E
> "Geir" == Geir Magnusson <[EMAIL PROTECTED]> writes:
Dan> I've
Dan> never tried that, but Geir is right, I think it can be done if
Dan> you try hard enough.
>> In the second case, when there is a security manager, then, no, you
>> cannot get around the access controls, even with reflection.
> "Geir" == Geir Magnusson <[EMAIL PROTECTED]> writes:
Geir> That's not fair. I told you that *I* think that extending java.lang
Geir> is a *bad idea*.
I still don't understand why you think this.
Could you explain what problem might arise?
Geir> Also, I don't know what the 1.4 and 1.5 Java
> "Dan" == Dan Lydick <[EMAIL PROTECTED]> writes:
Dan> What gives? Where can I find correct descriptions of
Dan> the latest .class file definitions for JDK 5?
Here's one source I found via google. Not sure if it is the most up
to date.
http://java.sun.com/docs/books/vmspec/2nd-edition/Upda
> "Dan" == Dan Lydick <[EMAIL PROTECTED]> writes:
Dan> That includes the language protection features like Geir's
Dan> example of package private, which are an interesting game of
Dan> navigating class file structures with reflection, etc. I've
Dan> never tried that, but Geir is right, I thin
> "Sven" == Sven de Marothy <[EMAIL PROTECTED]> writes:
Sven> Depending on non-public parts of other API packages is to be
Sven> avoided as far as possible. And if there is Classpath-specific
Sven> behaviour in the public API, then that is likely a bug. (or the
Sven> absence of a Sun bug)
One
> "Steve" == Steve Blackburn <[EMAIL PROTECTED]> writes:
Steve> I imagine I'm not alone in thinking that there are a great many
Steve> concrete things people can be working on right away, even while
Steve> discussion on key design issues continues.
Don't forget hacking on Classpath :-)
Steve
> "Geir" == Geir Magnusson <[EMAIL PROTECTED]> writes:
Geir> 4) RMI stuff
On irc Geir said that he meant "JNI" here.
Basically what this means, I think, is that Classpath has an
implementation of "jni.h", but the VM has to provide certain typedefs,
e.g., "jint".
Geir> 2) Are there things th
> "Jakob" == Jakob Praher <[EMAIL PROTECTED]> writes:
>> 2. Performance. The result has to be reasonable competitive
>> performance wise. E.g., starting eclipse has to be reasonable both in
>> time and space.
Jakob> How are doing with gcj in this direction?
I'm not sure I understand. We d
> "Jakob" == Jakob Praher <[EMAIL PROTECTED]> writes:
Jakob> do we want to build something that competes with sun j2se/mono on the
Jakob> desktop side (gnome/redhat would be interested in that)
I don't speak for Red Hat, but I can explain a little about why we
ship gcj and not other VMs. In
> "acoliver" == acoliver <[EMAIL PROTECTED]> writes:
acoliver> RTL is Register Transfer Language I believe.
Yes. But front ends don't generate RTL.
acoliver> Writing a GCC front end is actually rather non-trivial I'm
acoliver> afraid. While it does do a traditional AST tree more or less, i
> "Geir" == Geir Magnusson <[EMAIL PROTECTED]> writes:
Geir> In the meantime, any comments on architectures of some of the VMs?
Geir> I'm interest in having a balanced amount of upfront design that
Geir> prevents us from preventing participation from unexpected places in
Geir> the future...
T
> "Ben" == Ben Laurie <[EMAIL PROTECTED]> writes:
>> One answer is, cross-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.
Ben> I'm going to stop beating on this dead horse: you'll be happy if we
Ben> can implement th
> "Stefano" == Stefano Mazzocchi <[EMAIL PROTECTED]> writes:
>> JCVM has a nice feature in this area in that it converts bytecode to C
>> and then lets GCC compile that.
Stefano> Hmmm, interesting... I wonder if we could hook directly into the
Stefano> compiler intermediate representation ins
> "Ben" == Ben Laurie <[EMAIL PROTECTED]> writes:
Ben> This has to be a VM that produces native code, right?
Yes.
Ben> In any case, here I am with a platform that currently has no VM, but
Ben> does have a C compiler. What do I do?
One answer is, cross-build the VM from another machine that
> "Steve" == Steve Blackburn <[EMAIL PROTECTED]> writes:
Steve> There is no need for any function call on the fast path of the
Steve> allocation sequence.
[ ... ]
Steve> However this is small fry compared to the importance of compiling
Steve> write barriers correctly (barriers are used by mos
> ">" == shudo <[EMAIL PROTECTED]> writes:
>> Note that I remember Kaffe and GCJ had a test suite good even for JVMs
>> while Mauve is targetted for class libraries.
I think Kaffe has some VM-layer tests. gcj doesn't really have much
here. The best way forward, IMO, is to make a new module
> "David" == David Griffiths <[EMAIL PROTECTED]> writes:
David> Maybe a concrete example would help. Let's say you have a GC module
David> written in C. One of it's API calls is to allocate a new object. How
David> is your JIT module going to produce code to use that API? Via a C
David> functi
> "Ben" == Ben Laurie <[EMAIL PROTECTED]> writes:
>>> I'm pretty sure we want a framework in C/C++, whatever components
>>> are developed in.
>> Umm. Why?
Ben> So it can run everywhere.
FWIW, writing a VM in java doesn't make this harder per se.
In fact, in a way it is easier as you are al
> "Rodrigo" == Rodrigo Kumpera <[EMAIL PROTECTED]> writes:
Rodrigo> Making Harmony modular enouth to be kind of a JVM framework
Rodrigo> cannot be done before having a working JVM.
Rodrigo> Creating such is a big chalenge, to guess what spots need to flexible
Rodrigo> and the others that don'
> "Stu" == Stu Statman <[EMAIL PROTECTED]> writes:
Stu> Would it be possible for someone from the GNU Classpath community ...
Stu> if any are on this list ... to give an overview of the status of GNU
Stu> Classpath? How complete is it now? How much work do they anticipate it
Stu> being to get
> "Steven" == Steven Augart <[EMAIL PROTECTED]> writes:
Steven> What really quashed the idea was the issue of garbage
Steven> collection -- GCC is not designed to pass type information
Steven> down to the lower levels of the compiler, so GCJ doesn't build
Steven> a "gc map", which you need in
> "Steve" == Steve Blackburn <[EMAIL PROTECTED]> writes:
Steve> I am going to stick my neck out and make a few concrete suggestions
Steve> for how the Harmony VM might be developed.
Excellent post.
I would like to mention a different possibility:
* Write a new, modular VM in C or C++
- G
>>>>> "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
> "Geir" == Geir Magnusson <[EMAIL PROTECTED]> writes:
Geir> To be clear, "using APR" and "writing in Java" aren't orthogonal, are
Geir> they? I would assume that we do need some boundary between the VM
Geir> and the underlying OS/Hardware.
You are correct. Any VM will always need a way to
> "Berlin" == Berlin Brown <[EMAIL PROTECTED]> writes:
Berlin> Curious, why not jikes, it seems to have a liberal license.
My impression is that it isn't being actively developed. However, I
don't track jikes very closely.
If it is being developed, then it is another good choice. Basically
> "Rodrigo" == Rodrigo Kumpera <[EMAIL PROTECTED]> writes:
Rodrigo> It would be great to be GCJ compatible. Leveraging they effort with
Rodrigo> the binary ABI is a smart move and will promote more harmony instead
Rodrigo> of fragmentation between the java ahead-of-time systems.
See the "plug
> "Berlin" == Berlin Brown <[EMAIL PROTECTED]> writes:
Berlin> The compiler seems to be a non-issue at this time with a focus
Berlin> on the JavaVM. What are your thoughts on the different
Berlin> compilers?
For Harmony I would say the leading contender is the java compiler
that comes with E
> "Bob" == Bob <[EMAIL PROTECTED]> writes:
Bob> There's a lot of discussion on JIT vs. WAT. I think I can lay down
Bob> some framework on the issue.
Bob> WAT-compiled code requires a smaller runtime system, their programs
Bob> load faster, they probably use less memory at runtime, and they
> "Dalibor" == Dalibor Topic <[EMAIL PROTECTED]> writes:
>> Mladen Turk wrote:
>> AFAICT, one of the goals is to pass the TCK's, so how can you do that
>> if you don't have a full control over the major part of the package?
Dalibor> In the same way all the other runtimes pass the TCK without
> "Mladen" == Mladen Turk <[EMAIL PROTECTED]> writes:
Mladen> IMHO the ASF has much more transparent OS abstraction layer (APR)
Mladen> then either classpath or any other library has. Also developing that
Mladen> is less demanding task then JVM/JIT/GC etc... is thought.
Rewriting Classpath's
> "Ben" == Ben Laurie <[EMAIL PROTECTED]> writes:
Ben> Also, curious to know - what about out-of-band verifiers? So, for
Ben> example, I verify something on my PC, sign it as verified, then run it
Ben> on a Palm, with no verification?
My understanding was that there is a new kind of "split ve
> "Henri" == Henri Yandell <[EMAIL PROTECTED]> writes:
>> On 5/10/05, Mark Wielaard <[EMAIL PROTECTED]> wrote:
>> We do have a separate CVS development branch for the new generics
>> support in 1.5 that we hope to merge in as soon as all free compilers
>> and runtimes properly support the new
> "Matthew" == Matthew French <[EMAIL PROTECTED]> writes:
Matthew> I am guessing the Classpath project has the same issue. Is it
Matthew> really practical (right now) for an open source java library
Matthew> to be 100% compliant with J2SE 1.3/4/5?!? Would it not be
Matthew> more pragmatic to a
> "Dalibor" == Dalibor Topic <[EMAIL PROTECTED]> writes:
>> java.lang.instrument/management, a surprising amount of java.math are
>> all areas in need of definite work. Amongst others.
Dalibor> Yep. There is also CORBA, the org.omg interfaces. My hope is that we
Dalibor> can then just plug in
> "Ben" == Ben Laurie <[EMAIL PROTECTED]> writes:
>> A few short & sweet reasons see
>> http://fpl.cs.depaul.edu/cpitcher/se573/lectures/lecture-07.html#slide013
Ben> So its an optimisation (and therefore optional), right?
Yes. Though in practice it is probably necessary to get acceptable
p
> "Bob" == Bob <[EMAIL PROTECTED]> writes:
Bob> While it's still in its initial stages, I would like to advocate for
Bob> the importance of the Java 2 Security Model, and that it is
Bob> implemented correctly.
I wouldn't worry about this too much, I think it is implicit in the
goal of having
I've started writing, and then deleted, a few messages to this list
about different aspects of what I see as the solution -- using
Classpath, notes on licenses, etc. But this proved unsatisfactory and
I decided instead to start with a note about what I see as the
problems in the free java space.
> "Henri" == Henri Yandell <[EMAIL PROTECTED]> writes:
Henri> 1) Use Parrot.
LLVM is probably a better choice, if it comes to that.
But looking at execution engines is probably premature.
Henri> 5) Have Sun open-source things to Harmony, or IBM.
Would be nice.
Henri> 6) Will generics be tr
> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes:
Mark>I don't know if there are documents on the shared bytecode
Mark>verifier ideas that some people talked about. The verifier exists in
Mark>pluggable form on the gcjx branch of the GCC cvs repository.
There are no documents.
65 matches
Mail list logo
