decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
0005.pdf as text as html | 96 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
0005.pdf as text as html
Authored by: indyandy on Saturday, May 19 2012 @ 09:47 PM EDT
[Ed: As Andy Rubin refused to acknowledge an email due to inconsistent indents I have tried to reproduce the indents exactly]<br>
<br>
<br>
<b>From:</b> Tim Lindholm<br>
<b>To:</b> Andy Rubin<br>
<b>Sent:</b> 8/5/2005 12:49 PM<br>
<b>Cc:</b> <br>
<b>Bcc:</b><br>
<b>Subject:</b> Re: Fwd: Java VM for Android<br>
<br>
<br>
This is indeed entertaining, and I'm sure lots of offers to &quot;help&quot;<br>
will pop up as the Android Project becomes better known here.<br>
FWIW I largely agree with Brian, and think that the guy pointing to<br>
the various open source efforts out there is largely clueless. OK,<br>
maybe there might be a few odds and ends that would be worth picking<br>
up, where we have no value to add and the license isn't onerous. But<br>
most of that stuff is complete crap. The first 30% of a Java runtime<br>
is not nearly as valuable or costly as the last 30%, or 5%, of a<br>
commercial-quality one.<br>
I do want to second Robert G's assessment: he, Urs and Srdjan were<br>
three of what is surely one of the best small JVM implementation<br>
teams that has existed (there were five implementors total in the<br>
original team). They shared an aesthetic for clean design and<br>
coding that you probably won't see outside of academics. They had<br>
some flaws, but not many. One is that they are stubborn Northern<br>
Europeans, who will not necessarily appreciate some other way of<br>
doing things. But I don't think they want to be JVM engineers any<br>
more, and this separation makes for less reason for concern. Frank<br>
Yellin doesn't have the elegance of the HotSpot guys, but is<br>
extremely bright and very experienced with Sun's CLDC implementations.<br>
The other Sun guys he mentions were each very good in their ways, but<br>
not in ways that directly relate to what you need -- they were Big<br>
Java guys, e.g. worrying about scalability and management.<br>
On this same line, yesterday (or the day before??) I had lunch with<br>
the guy at Sun who is the brain behind Sun's little-JVM-on-Linux<br>
effort, on the efficient use of multiple processes on Linux. He<br>
wants to get out of Sun and is extremely interested in Google,<br>
even while not knowing anything about Android. (That email to<br>
Vineet might be able to change this?). Unfortunately he has<br>
immigration things require him to be out of the US Sept-Oct, and<br>
then career things that might make him want to stay at Sun until<br>
January. Knowledge of Android might overcome the latter, but if we<br>
tried for him in the shorter term we'd need to accommodate the away<br>
time. If we can't get him before the away time then he very likely<br>
will stay until January. This guy could be a key hire. The only<br>
possible downfall is that there had historically been bad blood<br>
between the team he worked in and the HotSpot guys, but since then<br>
he has proven his value.<br>
--Tim<br>
Andy Rubin wrote:<br>
&gt; Thought you'd get a kick out of this thread ...<br>
&gt;<br>
&gt;Begin forwarded message:<br>
&gt;<br>
&gt;&gt;*<b>From:< ;/b> *Robert Griesemer &lt;gri@google.com &lt;mailto:gri@google.com&gt;&gt;<br>
&gt;&gt;*Dat e: *August 5, 2005 11 :35:38 AM PDT *<b>To:</b> *Brian Swetland<br>
&gt;&gt; &lt;Swetland@google.com &lt;mailto:swetland@google.com&gt;&gt; *<b>Cc:</b> *Sascha<br>
&gt;&gt; Brawer &lt;Sascha@google.com &lt;mailto:sascha@google.com&gt;&gt;,<br>
&gt;&gt; arubin@google.com &lt;mailto:arubin@google.com&gt;, nicksears@google.com<br>
&gt;&gt; &lt;mailto:nicksears@google.com&gt;, miner@google.com<br>
&gt;&gt; &lt;mailto:miner@google.com&gt;, cwhite@google.com<br>
&gt;&gt; &lt;mailto:cwhite@google.com&gt;, fadden@google.com<br>
&gt;&gt; &lt;mailto:fadden@google.com&gt;, tcole@google.com<br>
&gt;&gt; &lt;mailto:tcole@google.com&gt;, ficus@google.com<br>
&gt;&gt; &lt;mailto:ficus@google.com&gt;, Patrik Reali &lt;patrik@google.com<br>
&gt;&gt; &lt;mailto:patrik@google.com&gt;&gt;, Urs Hoelzle &lt;urs@google.com<br>
&gt;&gt; &lt;mailto:urs@google.com&gt;&gt; *<b>Subject:</b> **Re: Java VM for Android*<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;Brian;<br>
&gt;&gt;<br>
&gt ;&gt; I can't really comment on your project but I'd like to give you<br>
&gt;&gt;some more background info in case you are interested: There are<br>
&gt;&gt;several people here at Google that have intimate VM knowledge: Urs<br>
&gt;&gt; H&quot;i(, V2lzle, Srdjan Mitrovic, and I all worked on Sun's HotSpot JVM; we<br>
&gt;&gt; are in fact part of the original designers of the VM. Srdjan and I<br>
&gt;&gt; later wrote the &quot;client&quot; compiler for the VM (this is the default<br>
&gt;&gt;compiler shipped with Sun's VM, for ia32 and SPARC); and we also<br>
&gt;&gt; wrote the compiler for one version of Sun's CLDC VM for embedded<br>
&gt;&gt;devices (also referred to as the &quot;Monty&quot; VM, running on StrongARM).<br>
&gt;&gt;Todd Turnidge, David Stoutamire, and Ben Gomes joined the HotSpot<br>
&gt;&gt; VM effort a bit later but also have done significant work in that<br>
&gt;&gt;space. Srdjan, Todd, and I later also worked on a successor of the<br>
&gt;&gt;HotSpot VM (for MIPS) at a startup. And last but not least we now<br>
&gt;&gt;also have Tim Lindholm and Frank Yellin, the original Java VM guys<br>
&gt;&gt; here at Google. But you probably don't want that many cooks ...<br>
&gt;&gt;<br>
&gt;&gt;Anyway, you may want to consider chatting with some of these<br>
&gt;&gt; people, there is a considerable amount of knowledge that can be<br>
&gt;&gt;tapped. - gri<br>
&gt;&gt;<br>
&gt;&gt; PS: I am not cc: these extra people to reduce the amount of spam<br>
&gt;&gt;you're getting ... :-)<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;On 8/5/05, *Brian Swetland* &lt;Swetland@google.com<br>
&gt;&gt; &lt;mailto:swetland@google.com&gt;&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I am a somewhat familiar with the grungy work involved in embedded<br>
&gt;&gt; JVM building -- I wrote the VM that the Danger Hiptop platform<br>
&gt;&gt;uses.<br>
&gt;&gt;<b r>
&gt;&gt;There are some useful reasons (in my mind) for going through the<br>
&gt;&gt; effort of building our own embedded VM rather than just going with<br>
&gt;&gt;off the shelf solutions:<br>
&gt;&gt;<br>
&gt;&gt; - We'd like things to be really well-integrated with the<br>
&gt;&gt; environment, small, fast, and fast to launch. Both the &quot;run the vm<br>
&gt;&gt; in a little box just for midlets&quot; model (used by most handsets<br>
&gt;&gt; today) and &quot;run the entire world inside one vm&quot; model (used by<br>
&gt;&gt;danger) have downsides. I'd like to take advantage of running Linux<br>
&gt;&gt;on CPUs with a MMU (arm9 and better) and having multiple instances<br>
&gt;&gt;of the VM run in their own process space. Being able to have hard<br>
&gt;&gt; limits imposed by the kernel on memory use, etc, and tear down a<br>
&gt;&gt; whole VM if an app misbehaves is something we wished for often at<br>
&gt;&gt; Danger. To do this, we need to make sure we can start up things<br>
&gt;&gt;quickly when apps launch -- if java is core to the system and not a<br>
&gt;&gt; little novelty like in current handsets, users are not going to<br>
&gt;&gt;want to wait 10-15 seconds for apps to launch.<br>
&gt;&gt;<br>
&gt;&gt; - License choice is important. One of the goals of this project is<br>
&gt;&gt;to provide an open source system that's appealing to handset OEMs.<br>
&gt;&gt;The Linux kernel is GPL'd, but all the pieces above the kernel<br>
&gt;&gt;that we're using or building so far are under much friendlier<br>
&gt;&gt; licenses (BSD or MIT style typically). Bringing in third party<br>
&gt;&gt;commercial solutions is tricky for this reason too, unless we plan<br>
&gt;&gt; on buying them outright or otherwise convincing them to release<br>
&gt;&gt;their software under an open source license.<br>
&gt;&gt;<br>
&gt;&gt; - After some amazingly negative experiences at Be, dealing with<br>
&gt;&gt; Cygnus C++ compiler support, I would have a lot of concerns about<br>
&gt;&gt; throwing money (away) at Redhat or Cygnus or the like for language<br>
&gt;&gt;or compiler support. Of course there's also the concern of<br>
&gt;&gt;shopping core parts of the system out to possibly disinterested<br>
&gt;&gt;third parties.<br>
&gt;&gt;<br>
&gt;&gt;-The JVM is going to be a central piece of the system we're<br>
&gt;&gt; building, not some little add-on on the side -- so we can provide<br>
&gt;&gt; some really good java application development and user experiences.<br>
&gt;&gt; I'd like to take recycle bits where possible to support javascript<br>
&gt;&gt;and other language bindings, which will require doing things a<br>
&gt;&gt; little differently than an off the shelf JVM.<br>
&gt;&gt;<br>
&gt;&gt; - Classpath is interesting for their &quot;build it all in java&quot;<br>
&gt;&gt; approach, but from a performance perspective (which matters a lot<br>
&gt;&gt;on small devices), pushing chunks of the core library to native<br>
&gt;&gt;code is a huge win. Also, it is GPL with some special riders<br>
&gt;&gt;(which I thought the GPL disallowed ... ).<br>
&gt;&gt;<br>
&gt;&gt;Anyway, those are just some points off the top of my head,<br>
&gt;&gt;<br>
&gt;&gt;Brian<br&g t;
&gt;&gt;<br>
&gt;&gt;On 8/5/05, Sascha Brawer &lt;Sascha@google.com<br>
&gt;&gt; &lt;mailto:sascha@google.com&gt;&gt; wrote:<br>
&gt;&gt;&gt; Hi androids,<br>
&gt;&gt;&gt;<br>
&gt;&gt;& amp;gt;I happened to stumble upon your wiki page [1]. Are you really<br>
&gt;&gt;sure you<br>
&gt;&gt;&gt;want to write your own JVM, as [2] seems to indicate? You<br>
&gt;&gt;&gt; certainly have your reasons, but it sounds like repeating lots of<br>
&gt;&gt;&gt; grungy work.<br>
&gt;&gt;&gt;<br>
&gt;&gt;& gt; So, if you don't mind, let me emit some random personal notes<br>
&gt;&gt;&gt; about the free Java scene.<br>
&gt;&gt;&gt;<br>
&gt;&gt;& ;gt; Everyone and their dog (not really, but way too many people) has<br>
&gt;&gt;been<br>
&gt;&gt;&gt;wri ting a JVM around GNU Classpath [3]. Most of them don't target<br>
&gt;&gt;&gt;embedded systems, many are crap, much has gone to oblivion, but<br>
&gt;&gt;&gt;there's also some stuff that might possibly be useful to you<br>
&gt;&gt;&gt;guys.<br>
&gt;&gt;&a mp;gt;<br>
&gt;&gt;&gt; I'd really recommend having a look at JamVM [4]: it's fast for a<br>
&gt;&gt;pure<br>
&gt;&gt;&gt;inter preter, with a decent and small codebase. JamVM is what most<br>
&gt;&gt;&gt; Classpath hackers use nowadays for development. The author seems<br>
&gt;&gt;&gt;a nice guy, he was working on optimizing Sun's and IBM's JVMs,<br>
&gt;&gt;&gt; and is now an independent contractor.<br>
&gt;&gt;&gt;<br>
&gt;&gt ;&gt; I know of two companies using Classpath for JVMs that target<br>
&gt;&gt;embedded systems:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&a mp;gt; /k! [5] is a cover-up for one guy having his fun. My personal<br>
&gt;&gt;&gt; impression from the Classpath meetings is that the author is<br>
&gt;&gt;&gt;really into free software; I'm pretty sure he would be keen on a<br>
&gt;&gt; contract for<br>
&gt;&gt;&gt; an open-source embedded JVM. In the meetings list, he seemed to<br>
&gt;&gt;&gt; know what he's talking about, but I haven't chatted that much<br>
&gt;&gt;&gt;with him.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&g t; Aicas [6] is a real company whose embedded JVM is based on<br>
&gt;&gt; Classpath.<br>
&gt;&gt;&gt; Since they haven't given anything back to the project, I'd be<br>
&gt;&gt;&gt; surprised if they would be interested in a contract for an<br>
&gt;&gt; open-source<br>
&gt;&gt;&gt;embedded JVM.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&g t; There's also a Bytecode-to-C compiler [7], but I've no idea<br>
&gt;&gt;&gt;whether it's any good. I don't think it gets much used. But it<br>
&gt;&gt;&gt; might be interesting in case you want to use an ahead-of-time<br>
&gt;&gt;&gt; compiler for selected hot spots, and use a pure interpreter like<br>
&gt;&gt;&gt; JamVM for the rest.<br>
&gt;&gt;&gt;<br>
&gt;&gt;& gt; Kaffe [8] has been used for embedded systems, but the licensing<br>
&gt;&gt;is in<br>
&gt;&gt;&gt; a limbo (GPL, copyright held by a dead company).<br>
&gt;&gt;&gt;<br>
&gt;&gt;& amp;gt; You could pay Redhat for tweaking gcj/gcc, but their focus<br>
&gt;&gt;really is<br>
&gt;&gt;&gt;on desktop systems. But since you mention C++ linkage on your<br>
&gt;&gt;&gt; wiki: gee uses the same vtables for Java and C++, they call this<br>
&gt;&gt;&gt;&quot;Cygnus Native Interface (CNI)&quot;. There has been lots of talk<br>
&gt;&gt;&gt;about<br>
&gt;&gt;g iving gee<br>
&gt;&gt;&gt; a better jitter for dynamically loaded bytecode; they currently<br>
&gt;&gt;have a<br>
&gt;&gt;&gt;very inefficient interpreter as part of the Java runtime<br>
&gt;&gt; library. But<br>
&gt;&gt;&gt; last I've heard, Redhat's plan now is to use the gee backend as<br>
&gt;&gt;a JIT<br>
&gt;&gt;&gt; -- hairy stuff, and certainly totally unusable for an embedded<br>
&gt;&gt; sytem.<br>
&gt;&gt;&gt;<br>
&gt;&gt;& ;gt; If you need more info around the free Java projects, or if want<br>
&gt;&gt;&gt; to establish a contact, please feel to talk to either me or<br>
&gt;&gt;&gt; Patrik<br>
&gt;&gt;Reali.<br>
&gt;&gt;&g t; We've both been somewhat active in this scene before joining<br>
&gt;&gt;&gt; Google, so we know most people from meetings.<br>
&gt;&gt;&gt;<br>
&gt;&gt;& amp;gt; Oh, you surely know that quite a few people at Google have a JVM<br>
&gt;&gt;&gt; background? For instance Robert Griesemer or Urs Hoelzle. I hope<br>
&gt;&gt;&gt;<br>
&gt;&gt;you< ;br>
&gt;&gt;&gt;don't mind that I'm taking the liberty to cc them on this post,<br>
&gt;&gt;&gt; in case they want to comment/shoot me down.<br>
&gt;&gt;&gt;<br>
&gt;&gt;& gt; Best wishes, and have fun with Android,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&a mp;gt; -- Sascha<br>
&gt;&gt;&gt;<br>
&gt;&gt;& ;gt; [1] http://wiki.corp.google.com/twiki/bin/view/Main/Android [2]<br>
&gt;&gt; http://wiki.corp.google.com/twiki/bin/view/Main/AndroidJavaVM<br>
& ;gt;&gt; &lt;http://wiki .corp.google.com/twiki!bin/view/Main/AndroidJavaVM&gt;<br>
&gt ;&gt;&gt;[3] http://www.gnu.org/software/classpath/ [4]<br>
&gt;&gt;&gt;http://jamvm.sourceforge.net/ [5]<br>
&gt;&gt;&gt;http://www.kiffer.be/k/profile.html [6] http://www.aicas.com/ [7]<br>
&gt;&gt;&gt;http://jcvm.sourceforge.net/ [8] http://www.kaffe.org<br>
&gt;&gt;&gt;<br>
&g t;&gt;<br>
&gt;&gt;<br>
&gt;<br>

[ Reply to This | Parent | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )