Re: Apache Booth At JavaOne

[Dmitry Serebrennikov]

Greetings,

Has the time been selected? I'm sorry if I missed it. Could someone 
please repost it?
If not, how about Monday or Thursday (both days after 5 pm would work 
for me).
By the way, there is another conference concurrently at San Francisco - 
Oreilly's Where 2.0, which is about location-enabled technologies (gps, 
google maps, mobiles, etc). They have a component, which is open to the 
public. It's the Where Fair, on Wednesday 29th from 7:30pm to 10:00pm. I 
don't think you have to register or anything - this part is open to the 
public.

Here's the URL and some info:

===
General Conference Info
--
http://conferences.oreillynet.com/where/
Location-aware technologies combined with mapping and other data are 
poised to create a whole new class of web apps and services. Maps are 
becoming an interface, helping us to visualize and access a variety of 
data. Location is fertile ground for hackers and researchers who mash up 
Google Maps with Craigslist or plug restaurant info into dashboard 
navigation. Call centers, insurance agencies, transportation companies, 
and retailers are finding unconventional internal uses for location 
technologies too.


But where is location-based technology leading us in the larger sense? 
And where's the business model beef? The first Where 2.0 Conference 
brings together the people 
, projects 
, and 
issues  leading 
the charge into this technological frontier. Join us to debate and 
discuss what's viable now, and what's lurking just below the radar.


===
The Where Fair
---
http://conferences.oreillynet.com/cs/where2005/view/e_sess/7098
The Where Fair is a science fair-style event that gives participants a 
first-hand look at just a few of the intriguing location-aware 
technologies lurking just below the radar. Fair-goers can discuss the 
ideas behind the demos with the creators, and learn how these 
unconventional new technologies can be adapted into existing business 
strategies. Where Fair projects are being selected from research, 
academia, and yet-to-be-discovered entrepreneurs. The Where Fair 
complements the conference's exhibit hall, which will showcase 
state-of-the-art systems, apps, and services in the location space.



Cheers
Dmitry

Tom wrote:


+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 Pavilion pass for Monday, so if you still need help at 
the Apache booth for velocity/harmony that day, let me know.


Geir Magnusson Jr. wrote:


Not yet, but we still should certainly do it.

As a default, the Thirsty Bear is a great venue because of the  
"architectural discussion support products" created there on site 
and  made available for purchase :)


What times are good for people?


On Jun 21, 2005, at 7:54 AM, Joel Neely wrote:


There was some talk earlier about a Harmony conversation outside the
official J1 program.
Has anything firmed up?

-jn-

On 6/10/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:


All,

The ASF will have a booth at JavaOne this year...

Re: Apache Booth At JavaOne

[Dmitry Serebrennikov]

I just put together a simple mockup of this kind of a flyer. Please take 
a look at

http://www.jsdiinc.com/harmony/ossjava.html

What do you think?



Dmitry Serebrennikov wrote:


Greetings,

Here's an idea that occurred to me yesterday after reading Geir's post 
about booth at Java ONE. I think this is a good opportunity, but needs 
more thoughts.


You know how James Gosling keeps saying that Sun's customers tell them 
they would run for the hills if Java was opensourced, etc., etc.? 
Well, JavaOne is a gathering of just these types of customers, and 
they will be walking around the pavilion, possibly stopping by the 
Apache booth. What an opportunity to validate (and hopefully disprove) 
that assertion! If we could just come up with a way to poll people as 
they stop by the booth, we might have an excellent argument to 
counteract Gonsling's FUD/misunderstanding (whichever it is).


Not only that, but at the same time we could actually educate people 
on (a) what OSS is *really* all about, (b) what Apache and Harmony's 
intentions are for Java (no incompatibility, just improvement), (c) 
about work that has already been done by other OSS projects in the 
Java VM field (gcj, classpath, etc).


Without the booth, there will be a few people that come the 
OSS-related sessions, fewer still will be at the Harmony session. But 
the booth changes things. If we conduct this kind of poll at the 
booth, and generate buzz about the booth at the sessions, we could 
reach vastly more people! Of course the booth is meant to be shared 
between all Java-related Apache projects, but isn't Harmony kind of an 
overriding umbrella that relates to and benefits all of these 
projects? Logically, it makes sense to have Harmony represented at the 
booth at all times, even if politically this may require negotiation. 
But maybe having a poll station and a stand with questions (see 
below), even as the rest of the booth is devoted to other topics, 
wouldn't be that difficult?


Isn't this an exciting opportunity? What I envision is something like 
this. Like I said, this requires more thought on exactly how to do this.
We present people with a series of questions, maybe 3 or 4, designed 
to spark their interest and explain benefits of a fully-compatible OSS 
Java implementation to them. At the end, we ask - Would you support an 
open source Java implementation that delivered the above? Yes / No. 
This could be printed on a largish poster so that people see it over 
the heads of others and also printed on postcard-sized sheets of 
paper. Under the poster and next to these postcards we put two 
fishbowls with big "Yes" and "No" scotch-taped to them. They grab the 
postcard, mark off their answer, fill in a comment if they want, and 
drop it in the right bowl. It might be good to ask for their name and 
org, but I'm not sure. Having that would help with legitimacy, but 
it's too much work to fill out and will cause lots of work for us to 
sort though anyway.


I don't suppose we are going to have one of those card readers there, 
will we? I think they cost extra.


Now, the postcards have an additional benefit. It's a matter of funds 
to print more of them, but the more we have, the more we can use them. 
We can distribute them at the entrance, cafeteria, etc. We can 
distribute them at sessions. The cards would also have the booth 
number on them to draw people in. They could even be as small as 
business cards, but they will be hard to see then. This would also 
just draw people to the Apache booth in general, so other projects 
might even be interested in supporting this idea as well.


So, what about the questions? Here are some ideas.
At the top, in large font, a big draw-in header. Something like: Is 
Open Source Java a Good Thing?

Then something like this:
Have you ever found a bug in Java that broke your application?
  You could have just fixed it, but had to work around it 
instead?
OSS Java will not only let you fix it and distribute your code with 
your application, but you would benefit from other people making such 
fixes, while you can just focus on your work and stop wasting time on 
workarounds!


Do you work with a platform that Sun's Java does not support?
  Have you ever wished that someone would just write a good 
JVM for it?
OSS Java with a vibrant community will provide an incentive to do just 
this. Because codebase is shared and understood by many people, the 
cost of adding a new platform becomes smaller over time, while the 
benefits become larger!


.

It needs a third one, but I can't think of one right now. I think we 
absolutely need to emphasize rigorous compatibility. But I can't think 
of how to put that in this format at the moment. Thoughts? Comments? 
What other benefits do we want to highlight?



Regards
Dmitry


Geir Magnusson Jr. wrote:


All,

The ASF will have a booth at Ja

Re: Apache Booth At JavaOne

[Dmitry Serebrennikov]

Greetings,

Here's an idea that occurred to me yesterday after reading Geir's post 
about booth at Java ONE. I think this is a good opportunity, but needs 
more thoughts.


You know how James Gosling keeps saying that Sun's customers tell them 
they would run for the hills if Java was opensourced, etc., etc.? Well, 
JavaOne is a gathering of just these types of customers, and they will 
be walking around the pavilion, possibly stopping by the Apache booth. 
What an opportunity to validate (and hopefully disprove) that assertion! 
If we could just come up with a way to poll people as they stop by the 
booth, we might have an excellent argument to counteract Gonsling's 
FUD/misunderstanding (whichever it is).


Not only that, but at the same time we could actually educate people on 
(a) what OSS is *really* all about, (b) what Apache and Harmony's 
intentions are for Java (no incompatibility, just improvement), (c) 
about work that has already been done by other OSS projects in the Java 
VM field (gcj, classpath, etc).


Without the booth, there will be a few people that come the OSS-related 
sessions, fewer still will be at the Harmony session. But the booth 
changes things. If we conduct this kind of poll at the booth, and 
generate buzz about the booth at the sessions, we could reach vastly 
more people! Of course the booth is meant to be shared between all 
Java-related Apache projects, but isn't Harmony kind of an overriding 
umbrella that relates to and benefits all of these projects? Logically, 
it makes sense to have Harmony represented at the booth at all times, 
even if politically this may require negotiation. But maybe having a 
poll station and a stand with questions (see below), even as the rest of 
the booth is devoted to other topics, wouldn't be that difficult?


Isn't this an exciting opportunity? What I envision is something like 
this. Like I said, this requires more thought on exactly how to do this.
We present people with a series of questions, maybe 3 or 4, designed to 
spark their interest and explain benefits of a fully-compatible OSS Java 
implementation to them. At the end, we ask - Would you support an open 
source Java implementation that delivered the above? Yes / No. This 
could be printed on a largish poster so that people see it over the 
heads of others and also printed on postcard-sized sheets of paper. 
Under the poster and next to these postcards we put two fishbowls with 
big "Yes" and "No" scotch-taped to them. They grab the postcard, mark 
off their answer, fill in a comment if they want, and drop it in the 
right bowl. It might be good to ask for their name and org, but I'm not 
sure. Having that would help with legitimacy, but it's too much work to 
fill out and will cause lots of work for us to sort though anyway.


I don't suppose we are going to have one of those card readers there, 
will we? I think they cost extra.


Now, the postcards have an additional benefit. It's a matter of funds to 
print more of them, but the more we have, the more we can use them. We 
can distribute them at the entrance, cafeteria, etc. We can distribute 
them at sessions. The cards would also have the booth number on them to 
draw people in. They could even be as small as business cards, but they 
will be hard to see then. This would also just draw people to the Apache 
booth in general, so other projects might even be interested in 
supporting this idea as well.


So, what about the questions? Here are some ideas.
At the top, in large font, a big draw-in header. Something like: Is Open 
Source Java a Good Thing?

Then something like this:
Have you ever found a bug in Java that broke your application?
  You could have just fixed it, but had to work around it 
instead?
OSS Java will not only let you fix it and distribute your code with your 
application, but you would benefit from other people making such fixes, 
while you can just focus on your work and stop wasting time on workarounds!


Do you work with a platform that Sun's Java does not support?
  Have you ever wished that someone would just write a good JVM 
for it?
OSS Java with a vibrant community will provide an incentive to do just 
this. Because codebase is shared and understood by many people, the cost 
of adding a new platform becomes smaller over time, while the benefits 
become larger!


.

It needs a third one, but I can't think of one right now. I think we 
absolutely need to emphasize rigorous compatibility. But I can't think 
of how to put that in this format at the moment. Thoughts? Comments? 
What other benefits do we want to highlight?



Regards
Dmitry


Geir Magnusson Jr. wrote:


All,

The ASF will have a booth at JavaOne this year.  We will be staffing  
the booth with projects, each project there for 2 hours or so to tell  
people about the project and the ASF in general.


If anyone would like to volunteer to help out, add your name here :

http://wiki.apache.org/jakarta/ApacheAtJavaOne20

Re: Harmony Meetup at JavaOne (Was Re: JavaONE - anyone going? Last day for "early bird" reg.)

[Dmitry Serebrennikov]

Geir Magnusson Jr. wrote:



On May 27, 2005, at 6:52 PM, Dmitry Serebrennikov wrote:



Daytime on Sunday before the conference works for me, but I'm open  
otherwise.



I don't understand..  Does this mean Sun day is best, but you are open?

geir


exactly

dmitry

Re: Harmony Meetup at JavaOne (Was Re: JavaONE - anyone going? Last day for "early bird" reg.)

[Dmitry Serebrennikov]

I would be interested in dropping by, but don't know how much I can 
contribute in terms of useful ideas and experience :)
I'm just a lowly Java architect/developer working on applications here 
and there. That and some C experience with a strong interest in helping 
out on this VM project.


Daytime on Sunday before the conference works for me, but I'm open 
otherwise.

Thanks!
Dmitry.

Geir Magnusson Jr. wrote:


Speaking of JavaOne :

Shall we plan a Harmony get-together and drink beer^H^H^H^H^H^H^H^H  
discuss architecture?


It can be before, during or after JavaOne...

geir

On May 27, 2005, at 3:02 PM, Dmitry Serebrennikov wrote:


Sorry, this is a bit off-topic.
Is anyone else planning to go to the JavaONE conference (June 25-30  
San Francisco, CA)?
By the way, today is the last day to register with the "early bird"  
discount.


Regards
Dmitry

Re: JavaONE - anyone going? Last day for "early bird" reg.

[Dmitry Serebrennikov]

Simon Chappell wrote:


Nope. Too expensive, too big, too crowded. I'll stick with the No
Fluff Just Stuff series, thanks.

On 5/27/05, Dmitry Serebrennikov <[EMAIL PROTECTED]> wrote:
 


Sorry, this is a bit off-topic.
Is anyone else planning to go to the JavaONE conference (June 25-30 San
Francisco, CA)?
By the way, today is the last day to register with the "early bird"
discount.

Regards
Dmitry


   



 

Yes, the price is way too high. I'm not certain I'll get to go yet, but 
hoping.

What's the 'No Fluff Just Stuff' thing? I guess that's just a joke.
I would have gone to ApacheCon, but it's way too far for me this time 
around.


By the way, I scanned through the sessions and didn't see one on Harmony 
yet. I saw something about Geronimo and I guess that'll be Geir. Maybe 
that one got retargetted? There are also a few interesting sessions on 
VM internals, which I'm looking forward to.


Regards
Dmitry

JavaONE - anyone going? Last day for "early bird" reg.

[Dmitry Serebrennikov]

Sorry, this is a bit off-topic.
Is anyone else planning to go to the JavaONE conference (June 25-30 San 
Francisco, CA)?
By the way, today is the last day to register with the "early bird" 
discount.


Regards
Dmitry

Re: vmmagic

[Dmitry Serebrennikov]

Steve, I just want to chime in with a big "keep these coming!" :)
A little more, and you'll convert everyone yet! ;)

-dmitry

Steve Blackburn wrote:


Perhaps it is worth saying a little more about vmmagic.


[... snip ...]

Re: Terminology etc

[Dmitry Serebrennikov]

This is excellent! For one, I find Java-in-Java to be much clearer after 
this little set of definitions.


A quick proposal: perhaps "VM bootstrap" as used below should really be 
something like "VM initialization," "VM init," or even "VM startup", 
since the word "bootstrap" is very specific and to me at least, 
indicates something more akin to the "VM bootloader" + "VM boot image" 
(as used below).


I'm going to try to make a couple of observations. Please forgive the 
rambling :)  It just seems like things are starting to take shape...


* It looks like there is really not much in common between this 
architecture and one where "VM core" would be in C... For that one, "VM 
core" would be in C, as would be all of the components, such as GC, 
scheduler, etc. "VM init" doesn't sound like a big deal but would 
probably also be in C. "VM boot image" and the "VM bootloader" are 
simply not present in a C solution.


* "OS interface" is perhaps one place where some code can be shared. If 
C version can benefit from an OS abstraction layer for portability, then 
it seems like this layer could be shared between the C and the Java 
implementations.


* The meat of the VM seems to be in the "spokes" that connect to the "VM 
core-hub". It seems that this is where it would make the most sense to 
mix components written in C with those written in Java, to see which one 
can do a better job. If all spokes were in C, it would make little sense 
to have the hub be in Java... On the other hand if spokes are all Java, 
it makes little sense to have the hub be in C.


Steve, if the spokes were in Java but the hub in C, would we then lose 
all of the aggressive inlining benefits that Java-in-Java solution can 
provide?



-dmitry

Steve Blackburn wrote:


I thought it might be helpful to clarify some terminology and a few
technical issues.  Corrections/improvements/clarifications welcome ;-)

VM core

 The precise composition of the VM core is open to discussion and
 debate.  However, I think a safe, broad definition of it is that
 part of the VM which brings together the major components such as
 JITs, classloaders, scheduler, and GC.  It's the hub in the wheel
 and is responsible for the main VM bootstrap (bootstrapping the
 classloader, starting the scheduler, memory manager, compiler etc).

VM bootstrap

 The bootstrap of the VM has a number of elements to it, including
 gathering command line arguments, and starting the various
 components (above).


In the context of a Java-in-Java VM, the above is all written in Java.


VM boot image

 The boot image is an image of a VM heap constructed ahead of time
 and populated with Java objects including code objects corresponding
 to the VM core and other elements of the VM necessary for the VM
 bootstrap (all written in Java, compiled ahead of time, packaged
 into Java objects and composed into a boot image).  The boot image
 construction phase requires a working host VM (ideally the VM is
 self-hosting).

VM bootloader

 In the case of Jikes RVM a dozen or so lines of assember and a few
 lines of C are required to basically do the job of any boot loader
 loader---mmap a boot image and throw the instruction pointer into
 it.  It will also marshal argv and make it available to the VM core.
 This is technically interesting, but actually pretty trivial and has
 little to do with the VM core (aside from ensuring the instruction
 pointer lands a nice place within the boot image ;-)

OS interface

 The VM must talk to the OS (for file IO, signal handling, etc).
 There is not a whole lot to it, but a Java wrapper around OS
 functionality is required if the VM is java-in-java.  This wrapper
 is pretty trivial and one half of it will (by necessity) be written
 in C.

I hope this brief sketch provides folks with a slightly clearer view
of what a java-in-java VM looks like, and some (tentitive) terminology
we can use to ensure we're not talking at cross purposes.

Cheers,

--Steve

Re: Java Application Native Wrapper

[Dmitry Serebrennikov]

Mohammed Al-Qaimari wrote:
   This project should provide a tool that generates a native executable 
program that just starts a new VM and provides all arguments and classespath 
etc... without suffering with batch and shell files. That's similar to a 
feature in  Borland's JBuilder.
There's NO Knowledge That is NOT POWER!
__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
 

At the risk of creating more nise on the list, here's an opensource tool 
for this purpse that I used with great success (on Windows):
jelude http://www.sfu.ca/~tyuen/jelude/
It is in "public domain", so not a lot of licensing issues.
There are many others that are opensource and not. Just look around if 
you need one of these.

Regards
-dmitry

Re: I hope the JVM implements most using Java itself

[Dmitry Serebrennikov]

I've been trying to process the idea of building java vm in java and 
with the comments on this and other threads it is starting to make 
sense, but I have a couple of specific question below. I would 
appreciate if someone could put in a few words of explanation, perhaps 
it will help others as well. Here goes...

I can see the argument for the code generator written in Java - it still 
produces the same machine code, so the fact that it is written in Java 
does not matter.

I can also see the argument that it is algorithms that matter, not the 
language in which they are written. At least that algorithms matter more.

Ok, but here are the questions.
First one is of the chicken-vs-egg variety -- as the GC algorithm 
written in Java executes, won't it generate garbage of its own, and 
won't it then need to be stopped and the tiny little "real" garbage 
collector run to clean up after it? I can only see two alternatives -- 
either it is going to cleanup its own garbage, which would be truly 
fantastacal... Or it will somehow not generate any garbage, which I 
think is not realistic for a Java program...

This brings me to the second question. In my experience, writing in Java 
and writing in C (and therefore thinking in Java and thinking in C) 
tends to produce very different programs. The languages just lead you in 
different directions. "Language shapes thought," you know. So, although 
one can argue that a Java program will ultimately be JITed (or WATed or 
whatever) to machine code, the program itself will not be written in the 
same way as a C program would be. Again, this is subjective and I expect 
people will not always agree with this. But I find that when I write C 
code, I'm thinking of CPU efficiency, changing strings in-place, and 
using pointers. Maybe *because* C is so painful, I tend to think of the 
simplest, most direct way to accomplish what is needed.
However, when writing Java, I find that I think more of correct object 
abstraction for the problem at hand, code reuse, classes that maintain 
consistent state. I don't think twice of using a HashMap if it happens 
to be convinient, or that inheritance will cause extra indirections at 
runtime.
To summarize (and to get to the question already) - the point is that 
language shapes thought. In other words, a program designed in Java will 
naturally tend to be slower then a program designed in C, simply because 
Java most naturally expresses slower designs then C does. And the 
question is - does this agree with anyone elses experiences? And if it 
does, is it a valid argument against using Java for the design and 
implementation of the VM?


Regards
-dmitry

Re: Thoughts on VM

[Dmitry Serebrennikov]

Bob Griswold wrote:
The performance of the VM doesn't actually matter that much in a
long-running application. It might make the code generation cycle faster
(leading to faster start-up time, but not if it takes time to optimize the
VM) or GC's to happen faster, but the VM code takes up typically less than
10% (usually far less than 10%) of the overall application performance time,
so even if you double the performance of the VM, you will only get a small
improvement in overall application performance.
Bob
 

I just want to put in my 2 cents here.
From my experience GC efficiency is the most critical component for 
large long-running server applications running on multi-CPU machines.

For the last few years, I've been working with a company that writes and 
supports such an application. It runs on 4-way and 8-way Solaris boxes 
mostly and services hundreds of concurrent users. The main performance 
problems we've seen can all be traced to garbage collection locking down 
the whole VM, all 8 CPUs, to do its thing. In fact, the more CPUs, the 
faster you end up generating garbage and filling up the heap, and 
therefore the more frequent are the GC pauses. This basically kills the 
scalability of the VM and an application running on it.

Granted, this was with the 1.3 and 1.4 versions of Sun's VM. I don't 
have direct experience with 1.5 to know if the situation has been 
improved. I heard that that may be the case. But I was just trying to 
point out that GC performance can be very critical of the overall 
performance of an application.

This exact problem is documented at the following URL: 
http://java.sun.com/docs/hotspot/gc/. Notice how the % of time spent in 
GC grows with the number of CPUs to the point where it becomes a 
dominant factor in the overall performance.

Regards
-dmitry
On 5/11/05 6:49 PM, "Kev Jackson" <[EMAIL PROTECTED]> wrote:
 

First post so be kind!
I was thinking about this last night after reading some posts.  Current
VM's use JIT or dynamic profiling/performance optimisation techniques to
improve the code running on them, but this only applies to application
code.  Would it be possible to write the VM in such a way as the VM
itself is able to be optimised at runtime?
This would essentially mean that each application would be running on
it's own custom VM.  Ok it's a non-trivial proposition, but with enough
initial thought I'm pretty sure something like this could be written.
Whether or not it's a good idea - well that remains to be seen.
To accomplish this I would think that the majority of the VM would have
to be written in a highly dynamic language (lisp-like) to allow for
run-time modification, with a small core algorithm in C to handle the
optimisation of the VM.  I would also suggest using lisp to write the
basic tools, not because I know lisp inside out, but because it's a
language that fits the problem domain of writing other language
interpreters/compilers extremely well.
Just some thoughts, is this possible/useful?
Kev
   

 

Re: Backward compatibility

[Dmitry Serebrennikov]

I thinking you worry too much :) Maybe Sun is just making it all too 
complicated ;)

If nothing else, perhaps with some competition Sun will finally start 
fixing all those bugs in the bugparade that have been there for years 
and years (like flaky filesystem operations, weird out of memory errors, 
and the like). Just take a look how Microsoft has gotten off their ass 
once Linux has really became popular. VM can't be that much more 
complicated than an operating system, can it?

-dmitry
Gerry Steele wrote:
I'm a big fan of the Apache foundation but this is one product I'm not too 
sure is such a good idea as of yet for reasons several:

 

Deprecated or non deprecated, we want Harmony to pass the TCK, so
 

whatever the TCK wants us to do, we'll do it.
   


I hope you understand what sticking to the TCK entails. When it comes to 
implementing GUI stuff for instance, your platform will have to fully copy 
the official JVM's Swing/AWT widgets and all other details in order for the 
automation and robot driven tests to pass. The JCK testbase for tiger is 
immense. To get it setup and run is a skill on its own. To get it to pass 
all tests takes a serious am mount of tweaking and a noteable knowledge of 
the javatest harness. It will require implementations on things as extensive 
as CORBA and RMI. We would need passive agents, tname servers etc.

Also, when running the TCK bear in mind that you'll have to run the harness 
with the Sun VM.

I'm not sure about the particular extent of the testsuite provided with the 
TCK you guys are talking about (if there is interest can find out more), but 
the JCK, which is basically a TCK for the entire J2SE jre and jdk will be 
going on impossible to pass for an alternative implmentation as everything 
is written with the Sun JDK/JRE in mind and test cases are adapted in ways 
that will create an infinite unpredictable series of problems when trying to 
adapt your code.

Another reason is that I'm not quite sure I see the point. It will take 4-5 
years or more to even come close to a product like tiger. Sun are already 
working heavily on mustang and dolphin (to a lesser degree on the latter). 
As well as this, sun research have many projects looking at the future of 
the Java VM such as the Barcelona project which will drastically change the 
implementation of the JVM. For instance to make it more network orientated 
or to improve resource sharing.

The latter things (which are yet to see real sun implementation) might be 
something you guys might then want to take advantage of in order to leverage 
a selling point of Harmony. Without something like that it's just another 
attempt at a VM that will be playing catch-up forever.

Also, don't forget about quality. Sun put a serious amount of money and 
manpower into ensuring the quality and compatibility of the JVM. A lot of 
corporations depend on this. They have a regular update release cycle. For 
instance we are currently working on 1.3.1_16, 1.4.2_09, 5.0_04 & 5.0_05.

In a project of this size some of the the test suites take several days to 
run. Some take many many hours of man power. For excessive thoroughness 
there also manual JCK and regression test suites. Which, trust me, will not 
be performed by someone who isn't being paid for it. Things like this don't 
fit well with the community model. 

Another worry I have is that the effort here might be better redirect to 
some other project. We already have Java. Even if harmony does make it to a 
useable release people will still prefer to use the Sun VM. It will be the 
platform people build on and it will be the one they trust.

I'll be very interested in how this turns out. 

Regards,
Gerry
1) speed
 

2) portability (java is claimed to run 'everywhere', but in fact, it
runs only on a few operating systems, even fewer for 1.5)
3) configurability (I might want to tune it differently and, for
example, choose different thread/GC models)
4) implementation stategy (in macosx, multiple JVMs share 80% of their
memory, and some of Swing is native, therefore feels like the rest of
the OS and it's hardware accelerated)
5) internal modularity (we want diversity of implementation to drive
innovation in the VM space, both in and out companies and universities)
And, last but not least, if Sun or other vendors that already have JVM
want to stop paying for all that development on their and want to start
sharing the development costs with the java ecosystem in general and
with a clear warranty that we will not try to pollute the stream we all
drink from, therefore want to contribute some of their code to Harmony,
we will welcome them with open arms.
--
Stefano.
   


 

Re: Class Library Modularity [Was Re: State of the World]

[Dmitry Serebrennikov]

Well, I can think of one thing I would like, some way for the packages 
contained in a JAR file be able to inform the underlying runtime not 
only its external dependencies, but also what it provides (or what it 
exposes). Due to limitations in the Java visibility/protection rules, 
sometimes it is not possible to avoid making implementation API public 
because you are forced to declare classes/methods as public if you 
need to use them from more than one package.
Woudln't it be great if this was addressed at the language level? 
Something like declaring "friend" packages or something like that. Then 
the public modifier would basically fulfil the need for this kind of 
"provides" or "exposes" declaration?

Well, maybe not. If you package a few packages together into a new 
library, each package might have its public interface, but that doesn't 
mean you want those methods as part of your library interface too. So 
the need for "provides" declaration goes beyond the package visibility 
related limitations it seems.

Doesn't Eclipse do something like this?
-dmitry

Re: Java

[Dmitry Serebrennikov]

Matthew French wrote:
Dmitry Serebrennikov said:
 

Using APR sounds very promising.
   

I need to verify this, but I don't believe APR really gives us what we
need in a VM?
A VM is very "thought intensive" code, but it should have very little
dependance on external system libraries. It needs to do malloc and printf
and that would be about it. And often you would want to use system
specific libraries for the performance gain.
APR would be very useful for the J2SE libraries, though. But that is a
different issue.
 

I don't know that much about VM internals yet. But will it also need 
threads? I agree that APR will be most useful for the libraries though. 
So I guess those libraries being in Java is not a foregone conclusion 
either then? :) JNI is a mess though...

-dmitry

Re: Java

[Dmitry Serebrennikov]

Just an idea here...
Using APR sounds very promising. But the arguments in this thread are 
also compelling.
Since the goal of Harmony is to build *modular* VM, perhaps an 
architecture should be developed from the beginning such that it can 
support pieces written in Java as well as others written in C? Competing 
implementations of various modules could then be produced by either camp 
and then the numbers will speak for themselves. But more importantly, 
ability to support such a mix would be an excellent gage of the quality 
of the APIs between modules.

Regards
-dmitry
Steve Blackburn wrote:
I would like advocate the use of Java in implementing the VM (*).
This may seem a low-level issue, but I'm raising it now because it
will have significant implications for the VM core and the overall
approach this project takes.
Why?  a) Software engineering benefits.  b) Performance.  c) "Eating
your own dog food" is good for you.
The basic argument goes like this:
 . From the standpoint of development time, providing (and
   maintaining) completeness of implementation will be our biggest
   challenge.  The more we can leverage Java's advantages in
   development time and maintainability, the better off we are.  The
   advantages of strong typing are particularly compelling when
   implementing the compiler and GC.  This also (largely) addresses
   the OS portability concerns being discussed.
 . From the standpoint of VM performance, the user code and libraries
   are (largely) written in Java anyway, so they will perform as well
   as our JIT allows.  As far as the execution of VM code at runtime,
   this is dominated by the GC, the JIT, and inlined pseudo-user code
   such as barriers and allocation sequences.  Experience with MMTk
   shows that it is possible to build high performance GCs in Java.
   Moreover, because the barriers and allocation sequences are
   expressed in Java, the JIT is able to aggressively optimize these.
   We found that this advantage and the fact that the size of Java
   scalars is statically known meant that we could outperform glibc's
   malloc on raw allocation time (size classes are statically
   evaluated).
 . "Eating your own dog food" is good for you.  It gives you a
   compelling reality check.  If your compiler isn't good enough for
   your own code, what is it good for?
To those I'll add two more points:
 . A project like this has the opportunity to be aggressive and not be
   shackled in the way the existing commercial product VMs are.  The
   Jikes RVM project at IBM (Java in Java) and Bartok at MSR (C# in
   C#) have really shown the potential for this approach.
 . We are a community who believes that Java has something to offer
   as a language, and we've demonstrated (GNU Classpath, Jikes RVM,
   the entire Jakarta project) that we can produce excellent systems
   using Java.
* Of course it is not possible to implement a high performance GC with
 out-of-the box Java 1.4.  However the set of extensions required is
 modest both in number and in implementation effort.  In MMTk we
 found it was necessary to add a number of unboxed types to give us
 type safety over addresses and object references (while retaining
 performance), and we added a number of compiler pragmas for
 correctness (interruptability) and performance (inlining).  These
 extensions have been factored out and are now also used by jnode.
--Steve
Research Fellow, Australian National University
phone: +61 2 6125 4821 fax: +61 2 6125 0010
http://cs.anu.edu.au/~Steve.Blackburn