On 6/2/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
All,
The conventional approach is to ahead of time compile MMTK to an
executable image. Then load this image during JVM initialization.
This means building some sort of AOT infrastructure. I would like to
avoid this for initial bring up if
On 6/2/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
All,
Perhaps the following is already covered in documentation. If this is
the case, please tell me where to find it. Below are some initial
questions regarding porting MMTK to DRLVM.
A question about org.vmmagic.pragma.InlinePragma class.
Note that read barriers are also needed if you want to implement a GC
like Baker's real time copying collector that uses incremental
forwarding.
Rodrigo
On 5/24/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 5/24/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
> I have a patch for drlvm which
Isn't the idea to have a shared implementation that both FileChannel
and java.io stream. Can't we just use some sort of reference counting
to close it on finalize?
On 1/25/06, Rodrigo Kumpera <[EMAIL PROTECTED]> wrote:
> On 1/25/06, Paulex Yang <[EMAIL PROTECTED]> wrote:
On 1/25/06, Paulex Yang <[EMAIL PROTECTED]> wrote:
> Agree, it should, but currently not in Harmony.
>
> Rodrigo Kumpera wrote:
> > Aren't channels supposed to hold references to the original streams?
> >
> > On 1/24/06, Paulex Yang <[EMAIL PROTECTED]>
Aren't channels supposed to hold references to the original streams?
On 1/24/06, Paulex Yang <[EMAIL PROTECTED]> wrote:
> The patch does work in some case, but it is not enough.
>
> First, when the channel is closed, the relevant stream(FileInputStream,
> FileOutputStream or RandomAccessFile) also
though I agree with Paulex that it should
> move into LUNI). If the functionality of OSMemory is lacking we can, of
> course, extend it to support concurrent.
>
> Regards,
> Tim
>
> Rodrigo Kumpera wrote:
> > Can we import the backport of jsr-166 as the starting point for
t; "public domain" doesn't mean "clean pedigree"...
> >
> > But yes, certainly worth investigating. Can you look into it?
> >
> > Rodrigo Kumpera wrote:
> > > Can we import the backport of jsr-166 as the starting point for
> > > im
Can we import the backport of jsr-166 as the starting point for
implementing this package? It's released as public domain, so there
should be not license issue IFAIK.
There are only a few things required make it work, like removing
references to com.sun.Unsafe.
I have a few comments to make.
First, don't use Microsoft Word, please. Having this on the wiki would
be wonderful.
Socket and SocketChannel have some very weird strange relationship:
1)Socket and ServerSocket must be implemented in terms of SocketImpl,
as a user can supply a custom SocketImpl as
I think allowing tests to be fully executable in Java (i.e. a
certified jvm) would be really tricky. Some black-magic to rename all
classes would be required, and testing some core functionality would
be really hard - think synchronization and threading.
But for most classes this is perfectly doab
The source is attached. I've done some changes to compute
dependencies. So the result is a bit diferent.
On 12/28/05, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
> Rodrigo Kumpera wrote:
> > Just for curiosity I've written a small program that enumerate all
>
of components we ended up with was proposed a while ago on the
> wiki[1], but it's certainly open for debate.
>
> [1] http://wiki.apache.org/harmony/ClassLibrary
>
> Regards,
> Tim
>
>
> Rodrigo Kumpera wrote:
> > Just for curiosity I've written a small p
Just for curiosity I've written a small program that enumerate all
graph cycles of packages dependencies in Java 1.4 (counting only
fields, methods and super types). This shows that for most packages
this won't be an issue and a packaging that have no cyclic dependencis
is possible.
Given the crit
On 12/28/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> All,
>
> For you gurus out there, I have some questions about
> interpretation of the JVM 2.0 spec. I am trying to clarify
> certain operational details of array and exception handling.
> I would appreciate the collective wisdom of you
I wonder if the classpath vm interface classes where public domain
that issue would be solved. After all, there isn't much value, I
believe, on these classes only.
On 12/5/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> Yes, sublicensing. I believe the terms are not clear on how third
> partie
I think park/unpack can be implemented using java monitors without much trouble.
On 11/25/05, Andrey Chernyshev <[EMAIL PROTECTED]> wrote:
> I've been thinking a bit about the java.util.concurrent package, and
> how we might want to approach it here in Harmony. What kind of
> modifications one m
compare against BootJVM and
> JCHEVM. Are you still willing to contribute your JVM?
>
> I reply to you directly because I'm not sure if you still want to
> contribute your JVM. You can also answer to this mail on harmony-dev if
> you want your answer to be public.
>
> Regards,
I cannot see how adding package private classes can possibly be
classified as 'extend the defined namespaces'. This makes perfect
sense and allow implementation classes easier access the guts of spec
classes (eg, org.apache.harmony.ClassLoaderStuff will have some hard
time to mess with java.lang.Cl
On 11/1/05, Robin Garner <[EMAIL PROTECTED]> wrote:
> > On 11/1/05, Robin Garner <[EMAIL PROTECTED]> wrote:
> >> Rodrigo Kumpera wrote:
> >>
> >> >AFAIK IKVM, sablevm and jamvm all run on portable devices.
> >> >
> >> >Develo
On 11/1/05, Robin Garner <[EMAIL PROTECTED]> wrote:
> Rodrigo Kumpera wrote:
>
> >AFAIK IKVM, sablevm and jamvm all run on portable devices.
> >
> >Developing a j2me jvm is not as easier as it seens, first, the
> >footprint and execution performance must be rea
AFAIK IKVM, sablevm and jamvm all run on portable devices.
Developing a j2me jvm is not as easier as it seens, first, the
footprint and execution performance must be really optimized, so
expect a LOT of assembly coding.
After that, a jvm that runs in no device is pretty much useless, then
we woul
using the current scripts.
> > (Sorry I didn't think to put the effort into this in
> > the first place, as I deemed getting the code base done
> > first the more important item.)
> >
> > Would The List be interested in me replacing these simple
> > shell scri
Supporting many compilers have a few problems, the three I can think
of right now are, assembly sintax (intel x at&t), compiler extensions
(gcc's computed goto can speed interpreters a lot) and c++ libraries
nuanses (iff c++ is used).
On 10/24/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
On 10/21/05, Apache Harmony Bootstrap JVM <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-
> > From: Rodrigo Kumpera <[EMAIL PROTECTED]>
> > Sent: Oct 21, 2005 12:08 PM
> > To: harmony-dev@incubator.apache.org
> > Subject: Re: Som
On 10/21/05, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > "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 avail
tions.
Maybe that's because I do suck when using and developing with
autotools and I hope so.
Anyway, configure scripts are really sweet... when they work and don't
screw up too badly.
On 10/21/05, Dalibor Topic <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 21, 2005 at 01:08:34P
On 10/21/05, Apache Harmony Bootstrap JVM <[EMAIL PROTECTED]> wrote:
>
> Comments below.
>
> -Original Message-----
> From: Rodrigo Kumpera <[EMAIL PROTECTED]>
> Sent: Oct 20, 2005 1:49 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: Some question
e should see what everyone thinks
> about MSVC in particular.
>
> Dan Lydick
>
>
> -Original Message-
> From: Rodrigo Kumpera <[EMAIL PROTECTED]>
> Sent: Oct 20, 2005 12:40 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: Small problems building
Dan,
I think they should expand to #error instead of expanding to wrong code.
BTW, have you thought about using make to have incremental builds?
you think?
>
>
> Further comments follow...
>
> -----Original Message-
> From: Rodrigo Kumpera <[EMAIL PROTECTED]>
> Sent: Oct 19, 2005 4:49 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: Some questions about the architecture
>
> On 1
it has a large installed
> base, and a Windows version of the build scripts
> should be able to support both. I suggest that we
> could have the compiler as one of the configuration
> options in 'config.sh' for Windows and CygWin, also
> for the Windows .BAT file equivalen
I've found a small issue while building under cygwin.
I'm using j2sdk 1.4 and gcc 3.4.4 (cygwin). The problems are when
building the jni stuff.
First it included on gcc find patch "j2sdk\include\cygwin", but it
should be "j2sdk\include\win32".
Second is when building the included file "jni_md.h"
On 10/19/05, Apache Harmony Bootstrap JVM <[EMAIL PROTECTED]> wrote:
>
>
> -Original Message-
> From: Rodrigo Kumpera <[EMAIL PROTECTED]>
> Sent: Oct 19, 2005 1:49 PM
> To: harmony-dev@incubator.apache.org, Apache Harmony Bootstrap JVM <[EMAIL
> PROTE
r on
stack (since it's the one used to lookup classes for deserialization);
Security needs to walk the stack for performing checks on the code
base of each method on on; and JNI needs this as exceptions are queued
for using by the ExceptionOccurred call.
I did look at opcode.c and thread.c but
On 10/18/05, Zsejki Sorin Miklós <[EMAIL PROTECTED]> wrote:
> Rodrigo Kumpera wrote:
>
> >On 10/18/05, Archie Cobbs <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Rodrigo Kumpera wrote:
> >>
> >>
> >>>This won´t help to find the
On 10/18/05, Archie Cobbs <[EMAIL PROTECTED]> wrote:
> Rodrigo Kumpera wrote:
> > This won´t help to find the spots that require memory barriers, as
> > these are only an issue on SMP systems. But your idea should not be
> > discarded as it may help with other kinds
This won´t help to find the spots that require memory barriers, as
these are only an issue on SMP systems. But your idea should not be
discarded as it may help with other kinds of problems.
On 10/17/05, Archie Cobbs <[EMAIL PROTECTED]> wrote:
> Apache Harmony Bootstrap JVM wrote:
> > For testing
w), I will be checking in the changes for the
> 0.0.1 release, which will be enough for someone to
> get started evaluating the code in a fairly final form.
> With the 0.0.2 release, the test cases will be able to
> be exercised.
>
> Dan Lydick
>
> -Original Messag
These are really good news Dan!
I think we could start writing test code for the runtime functionality
like proper null checks, array bounds, class initialization,
synchronization and such.
On 10/17/05, Apache Harmony Bootstrap JVM <[EMAIL PROTECTED]> wrote:
>
> Everyone,
>
> I've been working h
Having a mixed JITed-interpreted enviroment makes things harder.
Writing a baseline, single pass JITer is easy, but there are A LOT
more stuff to make a port that just the code execution part.
JikesRVM have a base JITer class that does the bytecode decoding and
one subclass per platform that does
I've written a pet JVM in Java, it includes a very simple JITer, no GC
(but it is starting to use MMtk magic, so should be doable to use it),
no self-hosting and no support for native code. The code have never
left my machine but I'm willing to donate if is desirable.
[]'s
Rodrigo
On 9/20/05, G
I was wondering what similarities on-stack replacement of JITed code
have with suspension with code patching.
On 9/9/05, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
> Thanks, Rodrigo and Shudo. ORP had a similar approach as code patching
> previously, which we called "IP hijacking". We found, as you
Some time ago someone on this list pointed to a paper from Sun folks
about this subject.
>From what I remember, they tried the folllowing tecniques:
-Pooling on back-edges and call/return, using ether a boolean flag or
forcing a page-fault at a specific address. They noticed that
page-faulting ha
Using APR doesn´t mean Harmony won´t be posix compliant. Only that it
will be one layer above the posix stuff.
On 8/30/05, Xiao-Feng Li <[EMAIL PROTECTED]> 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
On 7/15/05, PJ Cabrera <[EMAIL PROTECTED]> wrote:
> Sven, Tom,
>
> Thanks for the suggestions. I mentioned SwingWT in the interest of not
> reinventing the wheel. Of course other peers could be written.
>
> Sven, how far along on the Qt peers are you? Which version of Qt are you
> using?
>
> I'm
This is insane, if implementing the classlibrary takes half the time
the GNU folks are on the road, by the time Harmony completes 1.5,
2010+, it will be history.
Leveraging ASL compatible software is the only feasible way to have it progress.
On 7/5/05, Weldon Washburn <[EMAIL PROTECTED]> wrote:
Java can offer true sandboxing, while with C no library wrapping can
stop you from doing syscalls.
On 7/3/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
> On Jul 3, 2005, at 8:25 AM, Ben Laurie wrote:
>
> > Joel Neely wrote:
> >
> >> Typed, constrained object references vs. untyped, uncon
If the API is meant to be language agnostic, it's just a bunch of
constants and a function vector. This should provide enouth to build a
better layer for each language.
The API between a Java JITer and a C JVM should be coarse grained
since cross-language calls are slow. ORP defines a very nice C+
On 6/10/05, Richard S. Hall <[EMAIL PROTECTED]> wrote:
> Rodrigo Kumpera wrote:
>
> >AFAIK the term extension classloader is used for application created
> >classloaders. The application classloader handles classpath and
> >installed extends (the dreaded /lib/ext
On 6/9/05, Richard S. Hall <[EMAIL PROTECTED]> wrote:
> Rodrigo Kumpera wrote:
>
> >OSGi is really nice to work, but I doubt it can be used within the
> >class library. Most code except that a JVM will create at most 2
> >classloader, the bootstrap classload
OSGi is really nice to work, but I doubt it can be used within the
class library. Most code except that a JVM will create at most 2
classloader, the bootstrap classloader (which can be null) and the
application classloader.
On 6/9/05, Richard S. Hall <[EMAIL PROTECTED]> wrote:
> Geir Magnusson J
On 5/28/05, Dalibor Topic <[EMAIL PROTECTED]> wrote:
> Rodrigo Kumpera wrote:
>
> >>b) an accidental mistake, then you fix the small bug in your code, feel
> >>better about the quality of your code, and move on.
> >
> >
> >
> > I agree wit
On 5/28/05, Dalibor Topic <[EMAIL PROTECTED]> wrote:
>
> Rodrigo Kumpera wrote:
> > Last time I checked, no one, nether me or you, is developing code agains
> the
> > TCK, but to a real JVM. And as hard as we may try, sometimes we end with
> > software that de
On 5/27/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
>
> On May 27, 2005, at 4:34 PM, Rodrigo Kumpera wrote:
>
> > We should provide wrappers to classes for the sake of
> > compatibility. Are
> > there any legal problems with doing so?
>
&
Latelly I've been playing with a toy JITer written in java (like jikesRVM
baseline compiler) for x86 on windows. It works on a single pass and perform
no optimizations at all, but the generated code is correct.
The parts missing are the hard ones, object allocation and exception
handling.
Next
We should provide wrappers to classes for the sake of compatibility. Are
there any legal problems with doing so?
Unfortunately, some Apache
> software actually does rely on com.sun classes, e.g. the SSL connectors
> in Tomcat.
>
> Tor
>
>
>
I think you dind't quite get how it works with MMtk. There are a few
"magic" classes that receive special treatment from the compiler and
translates method calls into pointer operations. This way MMtk can operate
under the same condition of C code.
I'm not sure how did you relate interface ca
There isn't much space for plugability of components beyond compile-link
time. And I see no reason to have it otherwise.
Rodrigo
On 5/24/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
>
> On May 24, 2005, at 4:49 AM, Dmitry Serebrennikov wrote:
>
> >
> > * "OS interface" is perhaps one p
A good way to define milestones that are perceptible by the general public
(Bare FOSS that runs fine on Harmony. Something like a Geronimo or Eclipse
(Bmilestones.
(B It's a way to deliver something that is valuable before the JCK compliant
(Bproduct ships,which will take a couple of years.
Not true. A java-in-java JVM don´t need any C code. Making syscalls is as
hard as calling a C function (from the assembly point of view), so providing
a wrapper for ether native functions or system calls is not that big deal.
But, well, it would be a lot more profitable to leverage APR to do a l
I still think a java-in-java solution is the way to go. All components can
be tested from a JVM until it can hosts itself. The only reason for using
C/C++ is with a vm as seed.
If the objective is to write a high performance JVM, having a vm with an
interpreter doesn't help much.
Starting with
Green threads have a lot of problems that are hard to solve. You have to
deal with blocking function, interupts, syscall restarts, blocking native
code, etc...
JikesRVM handles that gracefully? My impression is that everyone is dropping
this M:N model because of implementation issues. BEA dropp
jikesRVM have 3 compilers, baseline, quick and opt.
baseline is meant to have jit times comparable to an interpreter preparation
time[1].
quick is a replacement for baseline on PPC, as the generated code is too
slow, and aim to only get low hanging fruits. It's a linear, one pass
compiles, so i
Sure it does, we would be writing just a front-end. Which in case is not an
option for Harmony, since such code must be GPL.
Does anybody know if GCC allows such a thing?
>
> Keep in mind I know squad about GCC and friends.
>
> --
> Stefano, who should really do his homework some day.
>
>
I think jikesrvm can be executed from another JVM, this should make
debugging easy.
On 5/19/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > The problem of Java written JVM/JIT isn't one of performance. You can
> > theoretically achieve the same performance (although I'm not 100%
> > con
Hi,
What can someone that agreed to the SCSL contribute?
I've agreed on the SCSL for the 1.4.2 JVM and I want to contribute to
Harmony.
I did a carefull reading of the license and in my layman's undestanding,
I cannot contribute to anything that is convered by the 1.4.2 spec since it
would
My bad, I've not looked enouth on the poll api.
On 5/18/05, Mladen Turk <[EMAIL PROTECTED]> wrote:
>
> Rodrigo Kumpera wrote:
> > A quick look at APR reveal that it doesn´t provide all OS abstraction
> that a
> > JVM needs.
>
> I tend to disagree wi
A quick look at APR reveal that it doesn´t provide all OS abstraction that a
JVM needs. There are no functions to mark pages as executable, access to
scalable IO facilities (IOCP, epoll, kqueue, etc...) or workarounds for
small diferences on syscalls or libC implementation.
I think Harmony shou
If C/C++ is going to be used, the reference compiler is gcc. I don´t think
the pascal frontend of gcc is up to the others.
Rodrigo
On 5/17/05, Bryce Leo <[EMAIL PROTECTED]> wrote:
>
> Now don't go too crazy for my suggesting this, but why not pascal? If
> we're considering C as it is this re
C++, just C++, is a recipe for trouble. Most projects that use it define a
subset to make development a less painfull talk. Usually operator
overloading, templates and virtual inheritance are discarded.
Rodrigo
On 5/17/05, Ben Laurie <[EMAIL PROTECTED]> wrote:
>
> Jónas Tryggvi Jóhannsson wrot
The free JVMs based on it ether use vanilla Classpath or have some
custization for some key classes.
Making it plugable a layer above it's VM interface will be a nightmare to
mantain. Maybe if you can point to a use-case where the might make any
sense, many here will think positively about.
R
ng to make this possible on their JVM, but right
now they can't really say how it will look when finished.
Rodrigo
On 5/17/05, Royce Ausburn <[EMAIL PROTECTED]> wrote:
>
>
> Ack - Sorry about the incomplete mail.
>
> On 17/05/2005, at 3:58 AM, Rodrigo Kumpera wro
Nether support apt, AFAIK, which seens to be an easier task to do with the
Eclipse compiler.
Rodrigo
On 5/16/05, Nick Lothian <[EMAIL PROTECTED]> wrote:
>
> >
> > > "Berlin" == Berlin Brown <[EMAIL PROTECTED]> writes:
> >
> > Berlin> The compiler seems to be a non-issue at this time
> > wit
I'm wondering, some parts of the JDK seens to be product features and not a
standard. For examples, the sound system should use arts, esd or alsa (I
believe Sun support the last 2). The printing system should support cups,
lprng or both? The same goes for the crypto algorithms on the pack.
Rodr
A good way to get people started is having something like the Linux
Kernel Janitor Project.
Rodrigo
On 5/16/05, Ahmed Saad <[EMAIL PROTECTED]> wrote:
> hi all... i'm a computer science student located in cairo, egypt with a
> modest experience in c/c++ (wrote some bsd-style sockets and posix stu
Making Harmony modular enouth to be kind of a JVM framework cannot be
done before having a working JVM. There is a lot of literature about
how frameworks should emerge from continuous design and development.
This must not be the focus until required, so no JIT plugable layer
until someone tries to
It's never that simple. Python have some HUGE diference in terms of
semantics and runtime behavior for Java or .NET. People already
mentioned about the fact that it uses reference counting, this makes
object lifetime more predictable and all libs uses this fact.
Emulating this big semantic diferenc
On 5/14/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 2. Interpreting other bytecodes with the HarmonyVM - this is quite
> possible and might even be done in a performant way. By tweaking your
> primordial classloader or having multiple primordial classloaders.
> HarmonyVM may already require
It would be great to be GCJ compatible. Leveraging they effort with
the binary ABI is a smart move and will promote more harmony instead
of fragmentation between the java ahead-of-time systems.
But this raises a question, can Harmony use GCJ's binary ABI without been GPL?
Rodrigo
On 5/13/05, Pa
Harmony should be just a JVM. The runtime model between .NET and Java,
for example, is diferent enouth to be well harder than perform the
bytecode translation.
See IKVM, that run java bytecode on top of mono/.net.
Rodrigo
On 5/13/05, Steve Heath <[EMAIL PROTECTED]> wrote:
> won't that all be a
If it´s not 100% API equivalent, then it cannot be called Java. The
announcement says that Harmony is about free java.
Rodrigo
On 5/11/05, Doug Hall <[EMAIL PROTECTED]> wrote:
>
> On May 11, 2005, at 11:45 AM, Stefano Mazzocchi wrote:
>
> > Deprecated or non deprecated, we want Harmony to pass
Are you really curious? Then go to dev.java.net and take a look at the
TCK sources. It's distributed in a read-only license.
Rodrigo
On 5/11/05, FaeLLe <[EMAIL PROTECTED]> wrote:
> But im still curious do you think TCK checks if Harmony would have
> implementations of the deprecated methods or ca
The verifier is part of the the class loading process, it's the first
step of linking a class to the runtime. More about that can be found
in [1], but the verifier makes sure that a given piece of bytecode
won't mess up the stack or incorrectly use types.
Rodrigo
[1] The Java Virtual Machine Spe
Not sure, but how many machine code generation software java have?
Near-two? JikesRVM and near-to-be-usable SableVM jit? And C/C++? Using
tools like llvm, iburgs, vmgen and many more can make a huge
diference.
Besides that, for a long JikesRVM could not bootstrap from a free JVM,
last year someone
On 5/9/05, Steven Augart <[EMAIL PROTECTED]> wrote:
>
> --- Tom Tromey <[EMAIL PROTECTED]> wrote:
> > * Fragmentation. I think there are too many free JVMs.
>
> Amen to that. I hate to say it, since my own favorite VM is one of the
> ones keeping that space big. But a "state of the art" optimi
86 matches
Mail list logo
