Negative culture of Android Market reviews

MIME-Version: 1.0
Date: Fri, 12 Dec 2008 06:44:06 -0800 (PST)
User-Agent: G2/1.0
Message-ID: <569512f6-24d9-462b-a06a-1cc0f3afcd6f@40g2000prx.googlegroups.com>
Subject: Negative culture of Android Market reviews
From: Eric Mill <kproject...@gmail.com>
To: Android Discuss <android-discuss@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hey all,

Have other people noticed the negative tone rampant through Android
Market reviews?  If an app does something people don't like, such as:
includes ads, has a visible bug, dares to offer only a trial, or is
"unoriginal" (the same idea as another app released earlier), it gets
blasted.  And not just criticized, but leveled with poorly-spelled
profanity, personal insults, and 1-star ratings (never 2-stars, always
1).

Sometimes it feels like a mini-YouTube in there.  And since most
people will only ever see the last 3 comments on an app, it doesn't
take much to make an app look completely unpalatable.  I don't even
have an app on there myself, this is just me observing from afar.

I never would have expected this from G1 owners, which should be
optimistic early adopter types, and certainly not from the people so
into it that they go to their My Downloads folder and take the time to
rate and star their apps.

This sort of thing is going to become a problem, if it isn't one
already.  I propose a few ideas to Google to deal with this:

* Add a basic "flag this comment" moderation feature.
* Make it easier to read more than 3 comments - either, have "Read all
comments" become "Read more comments" and load them inline, or move
the "About the developer" options into the Menu-button menu, and use
the same infinite scroll technique on comments that you use for app
listings.
* Discount old ratings heavily, in the presence of new ratings (Google
may already be doing this)
* Add a positive, "thumbs up" style rating for comments, to promote
the thoughtful and sane reviewers.

What do other people think are good ways to address this?

MIME-Version: 1.0
Date: Fri, 12 Dec 2008 07:33:22 -0800 (PST)
In-Reply-To: <569512f6-24d9-462b-a06a-1cc0f3afcd6f@40g2000prx.googlegroups.com>
References: <569512f6-24d9-462b-a06a-1cc0f3afcd6f@40g2000prx.googlegroups.com>
User-Agent: G2/1.0
Message-ID: <5bdf5196-a06d-4caf-a240-d04bc46e4454@x38g2000yqj.googlegroups.com>
Subject: Re: Negative culture of Android Market reviews
From: Ed <edmundcl...@gmail.com>
To: Android Discuss <android-discuss@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Eric,

I have also noticed the same issue. Some people are being so vile that
it is embarrassing to read.

I like your ideas for the user rating features, but I would also add a
feature on the app side that could help people know what they are
getting before they respond with insults. I believe all apps in the
Market should be flagged in the apps list with particular identifiers:
e.g., Trial, Advertisements Included, Beta. This would also help to
tone down the negative feedback we have been seeing.

--Ed


On Dec 12, 8:44=A0am, Eric Mill <kproject...@gmail.com> wrote:
> Hey all,
>
> Have other people noticed the negative tone rampant through Android
> Market reviews? =A0If an app does something people don't like, such as:
> includes ads, has a visible bug, dares to offer only a trial, or is
> "unoriginal" (the same idea as another app released earlier), it gets
> blasted. =A0And not just criticized, but leveled with poorly-spelled
> profanity, personal insults, and 1-star ratings (never 2-stars, always
> 1).
>
> Sometimes it feels like a mini-YouTube in there. =A0And since most
> people will only ever see the last 3 comments on an app, it doesn't
> take much to make an app look completely unpalatable. =A0I don't even
> have an app on there myself, this is just me observing from afar.
>
> I never would have expected this from G1 owners, which should be
> optimistic early adopter types, and certainly not from the people so
> into it that they go to their My Downloads folder and take the time to
> rate and star their apps.
>
> This sort of thing is going to become a problem, if it isn't one
> already. =A0I propose a few ideas to Google to deal with this:
>
> * Add a basic "flag this comment" moderation feature.
> * Make it easier to read more than 3 comments - either, have "Read all
> comments" become "Read more comments" and load them inline, or move
> the "About the developer" options into the Menu-button menu, and use
> the same infinite scroll technique on comments that you use for app
> listings.
> * Discount old ratings heavily, in the presence of new ratings (Google
> may already be doing this)
> * Add a positive, "thumbs up" style rating for comments, to promote
> the thoughtful and sane reviewers.
>
> What do other people think are good ways to address this?
>

MIME-Version: 1.0
Date: Fri, 12 Dec 2008 08:19:03 -0800 (PST)
In-Reply-To: <5bdf5196-a06d-4caf-a240-d04bc46e4454@x38g2000yqj.googlegroups.com>
References: <569512f6-24d9-462b-a06a-1cc0f3afcd6f@40g2000prx.googlegroups.com> 
	<5bdf5196-a06d-4caf-a240-d04bc46e4454@x38g2000yqj.googlegroups.com>
User-Agent: G2/1.0
Message-ID: <b38d63d0-61c8-4039-a59f-7803892b8f64@o4g2000pra.googlegroups.com>
Subject: Re: Negative culture of Android Market reviews
From: blindfold <seeingwithso...@gmail.com>
To: Android Discuss <android-discuss@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yes. In part for that reason I have now added runtime JIT compiler
detection to my app such that a message shows up indicating why speed
performance is still (way too) low, but it would be good to have some
more options up front on the Market to indicate to would-be users what
they may expect performance-wise, and why, before they download and
install.

Regards

On Dec 12, 4:33=A0pm, Ed <edmundcl...@gmail.com> wrote:
> Eric,
>
> I have also noticed the same issue. Some people are being so vile that
> it is embarrassing to read.
>
> I like your ideas for the user rating features, but I would also add a
> feature on the app side that could help people know what they are
> getting before they respond with insults. I believe all apps in the
> Market should be flagged in the apps list with particular identifiers:
> e.g., Trial, Advertisements Included, Beta. This would also help to
> tone down the negative feedback we have been seeing.
>
> --Ed

Received-SPF: pass (google.com: domain of danf...@google.com designates 216.239.45.13 
as permitted sender) client-ip=216.239.45.13;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of 
danf...@google.com designates 216.239.45.13 as permitted sender) 
smtp.mail=danf...@google.com; dkim=pass (test mode) header...@google.com
Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69])
	by smtp-out.google.com with ESMTP id mBCId8sB001342
	for <android-discuss@googlegroups.com>; Fri, 12 Dec 2008 10:39:08 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1229107148; bh=9pcZmSjsLMeSDvQS8zwb7PAzULs=;
	h=DomainKey-Signature:MIME-Version:Sender:In-Reply-To:References:
	 Date:X-Google-Sender-Auth:Message-ID:Subject:From:To:Content-Type:
	 Content-Transfer-Encoding:X-GMailtapped-By:X-GMailtapped; b=Sc9bo1
	+r3snH7i3Q7y3bkEGGxq7yPDNgf8pRVEY+jdvZRv2u6xFUR4AnXAsjZiQBu9FWeWsUc
	y2sAn4ucecPaQ==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=mime-version:sender:in-reply-to:references:date:
	x-google-sender-auth:message-id:subject:from:to:content-type:
	content-transfer-encoding:x-gmailtapped-by:x-gmailtapped;
	b=NrYcY6LftUiWf1MYqsV+lwD62wPtP7+mQTMBDZXfe1sE0+IjCK02uyo6gbddiDYCS
	SuOR9+KWqTD6ZzywNl4Xw==
Received: from rv-out-0506.google.com (rvfb25.prod.google.com [10.140.179.25])
	by wpaz5.hot.corp.google.com with ESMTP id mBCIcuvX007216
	for <android-discuss@googlegroups.com>; Fri, 12 Dec 2008 10:38:57 -0800
Received: by rv-out-0506.google.com with SMTP id b25so1513335rvf.41
        for <android-discuss@googlegroups.com>; Fri, 12 Dec 2008 10:38:56 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Sender: danf...@google.com
Received: by 10.141.33.21 with SMTP id l21mr2044714rvj.259.1229107136724; Fri, 
	12 Dec 2008 10:38:56 -0800 (PST)
In-Reply-To: <b38d63d0-61c8-4039-a59f-7803892b8...@o4g2000pra.googlegroups.com>
References: <569512f6-24d9-462b-a06a-1cc0f3afc...@40g2000prx.googlegroups.com>
	 <5bdf5196-a06d-4caf-a240-d04bc46e4...@x38g2000yqj.googlegroups.com>
	 <b38d63d0-61c8-4039-a59f-7803892b8...@o4g2000pra.googlegroups.com>
Date: Fri, 12 Dec 2008 10:38:56 -0800
Message-ID: <8084e12c0812121038t24318673rc19e2475cb140...@mail.gmail.com>
Subject: Re: [android-discuss] Re: Negative culture of Android Market reviews
From: Dan Bornstein <danf...@android.com>
To: android-discuss@googlegroups.com
X-GMailtapped-By: 172.24.198.69
X-GMailtapped: danfuzz

On Fri, Dec 12, 2008 at 8:19 AM, blindfold <seeingwithso...@gmail.com> wrot=
e:
> Yes. In part for that reason I have now added runtime JIT compiler
> detection to my app

I don't know how you are trying to detect a JIT, but in case you are
using the class java.lang.Compiler or the property "java.compiler", as
far as I know neither the class nor property are commonly implemented
on any modern runtime for the Java programming language, and so I
don't expect Dalvik to ever have an implementation of those either (a
nontrivial implementation that is). I would bet, in retrospect, the
original authors =97 in the standard docs, java.lang.Compiler is listed as
"since 1.0" meaning that class has been around since the early 1990s
=97 wouldn't have chosen to make it part of the core java.lang package.

For example, I just compiled and ran the program below on my desktop
J2SE and got the output:

   java.compiler: null
   compilation attempt: false

In a modern implementation, the JIT, if it exists, operates behind the
scenes rather than being something that requires programmer
intervention.

-dan

##########

public class Comp {
   static public void main(String[] args) {
       System.out.println("java.compiler: " +
               System.getProperty("java.compiler"));
       System.out.println("compilation attempt: " +
               Compiler.compileClass(Blah.class));
   }
}

class Blah {
   static public void blort() {
   }
}

MIME-Version: 1.0
Date: Fri, 12 Dec 2008 12:48:05 -0800 (PST)
In-Reply-To: <8084e12c0812121038t24318673rc19e2475cb1408d1@mail.gmail.com>
References: <569512f6-24d9-462b-a06a-1cc0f3afcd6f@40g2000prx.googlegroups.com> 
	<5bdf5196-a06d-4caf-a240-d04bc46e4454@x38g2000yqj.googlegroups.com> 
	<b38d63d0-61c8-4039-a59f-7803892b8f64@o4g2000pra.googlegroups.com> 
	<8084e12c0812121038t24318673rc19e2475cb1408d1@mail.gmail.com>
User-Agent: G2/1.0
Message-ID: <a306c194-ff22-4a76-9423-aea9f72a765c@a26g2000prf.googlegroups.com>
Subject: Re: Negative culture of Android Market reviews
From: blindfold <seeingwithso...@gmail.com>
To: Android Discuss <android-discuss@googlegroups.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Dan,

One check I use is for java.lang.Compiler.compileClass(my.class) which
under Android (on the emulator) properly returns false to indicate
that indeed there is no support for it (yet). The other check is for
measured real-time performance, which I know is possible from my
experience with Nokia phones with lesser CPUs than the one inside the
G1. So that offers a second indicator for the presence of a JIT
compiler or equivalent.

Of course I know that a modern JIT compiler does not and should not
require programmer intervention, but several reply postings from
Android Team members have indicated that they feel that it would be
"very non-trivial" (hackbod) to implement this for Android with its
"dozen or more
VM-containing processes sharing a single CPU and a single pool of
RAM" (JBQ).

Therefore I would think it makes your life easier to first design and
implement a JIT compiler that gets explicitly invoked by the
application developer using compileClass(), such that you don't need
to worry about automatic profiling in the background while developers
will obtain access to major performance gains before the year 201x. It
should not be very hard to implement a light-weight compiler for
regular algebraic expressions and arrays in Java once you manage to
"reverse engineer" those from the Dalvik bytecodes? The whole thing
can be upward compatible with the later addition of automatic
profiling for JIT compilation, optionally making compileClass() a
dummy method again in case it interferes with the then fully automatic
and transparent JIT compilation. This would make for a logical two-
stage process on the still elusive Android roadmap.

Moreover, the compileClass() approach makes for an elegant alternative
for JNI by removing platform (CPU type) dependencies on the developer
side, while avoiding the need to program in two different languages
(Java/Android and C). The resulting native code from an embedded
compiler on the phone may be somewhat less efficient than from a
"heavy" compiler for use with JNI on the developer's PC, but I doubt
that the difference will be dramatic? After gaining a speed gain of an
order of magnitude, I'm quite willing to sacrifice 20 percent or so of
that gain in view of the mentioned advantages.

> as far as I know neither the class nor property are commonly implemented
> on any modern runtime for the Java programming language

You mean that compileClass() gets ignored/stripped by Sun's javac and
is not mapped to JVM bytecodes that form the input for generating
Dalvik bytecodes? That could indeed be a showstopper if confirmed. But
you do not need the Java VM runtime, do you? You only need javac to
generate the JVM bytecodes for compileClass(), and it does not matter
if the Java runtime subsequently ignores those parts since you only
need the bytecodes as input for conversion to Dalvik, and do not
depend on what the JVM supports. Please correct me if I misunderstand
the concept.

Thanks

On Dec 12, 7:38 pm, Dan Bornstein <danf...@android.com> wrote:
> On Fri, Dec 12, 2008 at 8:19 AM, blindfold <seeingwithso...@gmail.com> wr=
ote:
> > Yes. In part for that reason I have now added runtime JIT compiler
> > detection to my app
>
> I don't know how you are trying to detect a JIT, but in case you are
> using the class java.lang.Compiler or the property "java.compiler", as
> far as I know neither the class nor property are commonly implemented
> on any modern runtime for the Java programming language, and so I
> don't expect Dalvik to ever have an implementation of those either (a
> nontrivial implementation that is). I would bet, in retrospect, the
> original authors =97 in the standard docs, java.lang.Compiler is listed a=
s
> "since 1.0" meaning that class has been around since the early 1990s
> =97 wouldn't have chosen to make it part of the core java.lang package.
>
> For example, I just compiled and ran the program below on my desktop
> J2SE and got the output:
>
>    java.compiler: null
>    compilation attempt: false
>
> In a modern implementation, the JIT, if it exists, operates behind the
> scenes rather than being something that requires programmer
> intervention.
>
> -dan
>
> ##########
>
> public class Comp {
>    static public void main(String[] args) {
>        System.out.println("java.compiler: " +
>                System.getProperty("java.compiler"));
>        System.out.println("compilation attempt: " +
>                Compiler.compileClass(Blah.class));
>    }
>
> }
>
> class Blah {
>    static public void blort() {
>    }
>
> }
>

Received-SPF: pass (google.com: domain of danf...@google.com designates 
216.239.45.13 as permitted sender) client-ip=216.239.45.13;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of 
danf...@google.com designates 216.239.45.13 as permitted sender) 
smtp.mail=danf...@google.com; dkim=pass (test mode) header...@google.com
Received: from spaceape24.eur.corp.google.com (spaceape24.eur.corp.google.com 
[172.28.16.76])
	by smtp-out.google.com with ESMTP id mBCN8gsT022600
	for <android-discuss@googlegroups.com>; Fri, 12 Dec 2008 15:08:42 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1229123322; bh=LF8C42AiPM18SafNBIVl2Hx8cvA=;
	h=DomainKey-Signature:MIME-Version:Sender:In-Reply-To:References:
	 Date:X-Google-Sender-Auth:Message-ID:Subject:From:To:Content-Type:
	 Content-Transfer-Encoding:X-GMailtapped-By:X-GMailtapped; b=VQt2HQ
	NOyHIqVJFJBzjtWm8gyrx8CpzEnfiuWZAGJHNR6JphRULIsdbZXhNdM0NBiN2Rr2Ngf
	Ulk+DYdeWQD0Q==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=mime-version:sender:in-reply-to:references:date:
	x-google-sender-auth:message-id:subject:from:to:content-type:
	content-transfer-encoding:x-gmailtapped-by:x-gmailtapped;
	b=F9xii0DK6qS/yz26IGXxt09zlZ5uTlo2eLuMnhLJAvbbDFAVBJ2+ODN7pasibuAXg
	T5qNRE+pZ6ekkdWZp50CQ==
Received: from rv-out-0506.google.com (rvbf6.prod.google.com [10.140.82.6])
	by spaceape24.eur.corp.google.com with ESMTP id mBCN8c90008920
	for <android-discuss@googlegroups.com>; Fri, 12 Dec 2008 15:08:39 -0800
Received: by rv-out-0506.google.com with SMTP id f6so2176317rvb.53
        for <android-discuss@googlegroups.com>; Fri, 12 Dec 2008 15:08:38 -0800 (PST)
MIME-Version: 1.0
Sender: danf...@google.com
Received: by 10.140.199.15 with SMTP id w15mr2156438rvf.253.1229123318511; 
	Fri, 12 Dec 2008 15:08:38 -0800 (PST)
In-Reply-To: <a306c194-ff22-4a76-9423-aea9f72a7...@a26g2000prf.googlegroups.com>
References: <569512f6-24d9-462b-a06a-1cc0f3afc...@40g2000prx.googlegroups.com>
	 <5bdf5196-a06d-4caf-a240-d04bc46e4...@x38g2000yqj.googlegroups.com>
	 <b38d63d0-61c8-4039-a59f-7803892b8...@o4g2000pra.googlegroups.com>
	 <8084e12c0812121038t24318673rc19e2475cb140...@mail.gmail.com>
	 <a306c194-ff22-4a76-9423-aea9f72a7...@a26g2000prf.googlegroups.com>
Date: Fri, 12 Dec 2008 15:08:38 -0800
Message-ID: <8084e12c0812121508t713838ccre239371b19dc1...@mail.gmail.com>
Subject: Re: [android-discuss] Re: Negative culture of Android Market reviews
From: Dan Bornstein <danf...@android.com>
To: android-discuss@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-GMailtapped-By: 172.28.16.76
X-GMailtapped: danfuzz

On Fri, Dec 12, 2008 at 12:48 PM, blindfold <seeingwithso...@gmail.com> wrote:
> Of course I know that a modern JIT compiler does not and should not
> require programmer intervention, but several reply postings from
> Android Team members have indicated that they feel that it would be
> "very non-trivial" (hackbod) to implement this for Android with its
> "dozen or more
> VM-containing processes sharing a single CPU and a single pool of
> RAM" (JBQ).
>
> Therefore I would think it makes your life easier to first design and
> implement a JIT compiler that gets explicitly invoked by the
> application developer using compileClass() [...]

Actually, this wouldn't make anyone's life particularly easier. For a
JIT to do its job properly, it has to know something of the context in
which a method is being used, and it may alter its behavior depending
on circumstance.

For example, it's entirely likely that the first incarnation of a JIT
for Android won't even operate on whole methods, rather only compiling
the most used loop-free "traces" through methods, thereby taking less
memory and less time (and hence use less battery) compared to doing
whole-method compilation. Use your favorite search engine to look up
"trace-based jit" for further details.

If we go for this sort of JIT, the effort of hooking up compileClass()
would actually end up adding work, not reducing it.

> You mean that compileClass() gets ignored/stripped by Sun's javac and
> is not mapped to JVM bytecodes that form the input for generating
> Dalvik bytecodes? [...]

What I mean is that I would be surprised to find many implementations
of java.lang.Compiler.compileClass() that didn't look like this:

    public boolean compileClass(Class c) { return false; }

including in systems that actually do perform JIT compilation. So I
wouldn't rely on the return value of compileClass() to tell you
anything meaningful.

-dan

MIME-Version: 1.0
Date: Fri, 12 Dec 2008 16:01:23 -0800 (PST)
In-Reply-To: <8084e12c0812121508t713838ccre239371b19dc12a9@mail.gmail.com>
References: <569512f6-24d9-462b-a06a-1cc0f3afcd6f@40g2000prx.googlegroups.com> 
	<5bdf5196-a06d-4caf-a240-d04bc46e4454@x38g2000yqj.googlegroups.com> 
	<b38d63d0-61c8-4039-a59f-7803892b8f64@o4g2000pra.googlegroups.com> 
	<8084e12c0812121038t24318673rc19e2475cb1408d1@mail.gmail.com> 
	<a306c194-ff22-4a76-9423-aea9f72a765c@a26g2000prf.googlegroups.com> 
	<8084e12c0812121508t713838ccre239371b19dc12a9@mail.gmail.com>
User-Agent: G2/1.0
Message-ID: <f34b6231-4c31-4bad-b393-67f8aa1d7256@k1g2000prb.googlegroups.com>
Subject: Re: Negative culture of Android Market reviews
From: blindfold <seeingwithso...@gmail.com>
To: Android Discuss <android-discuss@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

> If we go for this sort of JIT, the effort of hooking up compileClass()
> would actually end up adding work, not reducing it.

In case of the trace-based JIT approach that you describe, you could
be right. "My" JIT proposal would act more like a JNI counterpart.
However, since most time is usually spent inside loops, you might
treat those loops as "virtual" method calls to make the difference
between method compilation and trace-based compilation of loops much
smaller, thereby reducing the work. A loop would then act like a call
to, say, a "for()" or a "while()" method, and much the same machinery
as developed for compileClass() method compilation could be reused and
retargetted.

> What I mean is that I would be surprised to find many implementations
> of java.lang.Compiler.compileClass() that didn't look like this:
>
>   public boolean compileClass(Class c) { return false; }
>
> including in systems that actually do perform JIT compilation.

Are you talking about implementations of the javac compiler or
implementations of the java VM (JVM)? For Android it does not matter
what the existing JVMs do with the call, because Android has its own
VM. For the Android tool chain it only matters what javac does:
whether it preserves all compileClass() call information in the .class
files or not. *If* javac replaces the compileClass() call by a stub
that just returns false, then we are indeed badly stuck, but I do not
believe that this is what happens. The stub is only implemented in the
JVMs that we need not care about.

When I compile your sample program with javac in Sun's JDK1.6.0_05, I
get a 861 byte Comp.class. When I replace your "Compiler.compileClass
(Blah.class)" by "false" (the Sun JVM evaluation of same when running
"java Comp"), I get a 721 byte Comp.class, that is 140 bytes less. Now
you are the VM expert, but without looking into the actual bytecodes
this already suggests to me that the compileClass() call info gets
preserved in the bytecode representation, and that is all you need to
identify the set of bytecodes for optional JIT compilation in the back-
end? Maybe it is even easier to apply JIT compilation for native code
generation from the Java VM bytecodes (the .class files) instead of
trying that from the Dalvik bytecodes (.dex files) that you generate
with dx from the .class files (decompiled Java classes in general look
pretty human-readable, but I do not know if that would also hold for
decompiled Dalvik dex files, so why not take the more easy route).

> So I wouldn't rely on the return value of compileClass() to tell you
> anything meaningful.

I suspect that Android dx or the Android VM currently implements that

    public boolean compileClass(Class c) { return false; }

but this is correct and fine as long as there is no JIT support in
Android. Moreover, I think that Android has full control over what
compileClass() returns, because javac will - as argued above - only
encode the call information and leave the implementation to the VM,
right? The VM is in our case the Android VM, not some java VM, so if
compileClass() currently returned true I would have to file an Android
bug report.

Thank you for your insights.

On Dec 13, 12:08=A0am, Dan Bornstein <danf...@android.com> wrote:
> On Fri, Dec 12, 2008 at 12:48 PM, blindfold <seeingwithso...@gmail.com> w=
rote:
> > Of course I know that a modern JIT compiler does not and should not
> > require programmer intervention, but several reply postings from
> > Android Team members have indicated that they feel that it would be
> > "very non-trivial" (hackbod) to implement this for Android with its
> > "dozen or more
> > VM-containing processes sharing a single CPU and a single pool of
> > RAM" (JBQ).
>
> > Therefore I would think it makes your life easier to first design and
> > implement a JIT compiler that gets explicitly invoked by the
> > application developer using compileClass() [...]
>
> Actually, this wouldn't make anyone's life particularly easier. For a
> JIT to do its job properly, it has to know something of the context in
> which a method is being used, and it may alter its behavior depending
> on circumstance.
>
> For example, it's entirely likely that the first incarnation of a JIT
> for Android won't even operate on whole methods, rather only compiling
> the most used loop-free "traces" through methods, thereby taking less
> memory and less time (and hence use less battery) compared to doing
> whole-method compilation. Use your favorite search engine to look up
> "trace-based jit" for further details.
>
> If we go for this sort of JIT, the effort of hooking up compileClass()
> would actually end up adding work, not reducing it.
>
> > You mean that compileClass() gets ignored/stripped by Sun's javac and
> > is not mapped to JVM bytecodes that form the input for generating
> > Dalvik bytecodes? [...]
>
> What I mean is that I would be surprised to find many implementations
> of java.lang.Compiler.compileClass() that didn't look like this:
>
> =A0 =A0 public boolean compileClass(Class c) { return false; }
>
> including in systems that actually do perform JIT compilation. So I
> wouldn't rely on the return value of compileClass() to tell you
> anything meaningful.
>

Received-SPF: pass (google.com: domain of danf...@google.com designates 216.239.45.13 
as permitted sender) client-ip=216.239.45.13;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of 
danf...@google.com designates 216.239.45.13 as permitted sender) 
smtp.mail=danf...@google.com; dkim=pass (test mode) header...@google.com
Received: from spaceape10.eur.corp.google.com (spaceape10.eur.corp.google.com 
[172.28.16.144])
	by smtp-out.google.com with ESMTP id mBFIPrIh003779
	for <android-discuss@googlegroups.com>; Mon, 15 Dec 2008 10:25:54 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
	t=1229365554; bh=9StplHrX+RzuxFBHrs+Pr0hYP0E=;
	h=DomainKey-Signature:MIME-Version:Sender:Date:X-Google-Sender-Auth:
	 Message-ID:Subject:From:To:Content-Type:Content-Transfer-Encoding:
	 X-GMailtapped-By:X-GMailtapped; b=P2ItkSQalrFvFZscPln58gpaHUTAxryd
	sMQxWHOvG+IteL6HP9PJe6GX3E9ybHgpa33UV3EX7Q+TD2ojMspawQ==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=mime-version:sender:date:x-google-sender-auth:message-id:
	subject:from:to:content-type:
	content-transfer-encoding:x-gmailtapped-by:x-gmailtapped;
	b=mnXAPND3PwbPs1TuWz3KXPXohakknkr4kNYgUhJIAiw9hvtyVsTFDCOge+T2r932v
	BRqj+2UzRUBleBxURca6w==
Received: from rv-out-0506.google.com (rvbf6.prod.google.com [10.140.82.6])
	by spaceape10.eur.corp.google.com with ESMTP id mBFIOQ17028119
	for <android-discuss@googlegroups.com>; Mon, 15 Dec 2008 10:25:51 -0800
Received: by rv-out-0506.google.com with SMTP id f6so2798529rvb.27
        for <android-discuss@googlegroups.com>; Mon, 15 Dec 2008 10:25:50 -0800 (PST)
MIME-Version: 1.0
Sender: danf...@google.com
Received: by 10.141.28.4 with SMTP id f4mr3856680rvj.37.1229365550733; Mon, 15 
	Dec 2008 10:25:50 -0800 (PST)
Date: Mon, 15 Dec 2008 10:25:50 -0800
Message-ID: <8084e12c0812151025k7eb2486x8c58d2c5e30d4...@mail.gmail.com>
Subject: On JITs (was Re: Negative culture of Android Market reviews)
From: Dan Bornstein <danf...@android.com>
To: android-discuss@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-GMailtapped-By: 172.28.16.144
X-GMailtapped: danfuzz

On Fri, Dec 12, 2008 at 4:01 PM, blindfold <seeingwithso...@gmail.com> wrote:
>> What I mean is that I would be surprised to find many implementations
>> of java.lang.Compiler.compileClass() that didn't look like this:
>>
>>   public boolean compileClass(Class c) { return false; }
>>
>> including in systems that actually do perform JIT compilation.
>
> Are you talking about implementations of the javac compiler or
> implementations of the java VM (JVM)?

I mean implementations of the core library. You can find the Dalvik
one in the source under </dalvik/libcore/luni-kernel/>.

> For Android it does not matter
> what the existing JVMs do with the call, because Android has its own
> VM. [...] I think that Android has full control over what
> compileClass() returns

Yes, we control compileClass() for Android, but it still *does*
matter, because the Android effort in this area is overwhelmingly to
implement a familiar class library. Since the prevailing common
implementation leaves this method effectively unimplemented, we don't
have a compelling reason to implement it ourselves, *especially*
because implementing it would represent a significant amount of work
for no real benefit, again, because our likely JIT implementation
couldn't possibly be exercised well by using this class.

The IBM article from 2002 that you cite in a followup talks about
using it to "prove that the JIT doesn't take any internal errors."
Given that the operation of this method in our case would be *very*
different than the usual way the JIT runs, you wouldn't actually be
able to "prove" such things in the case of Dalvik, and this would also
be true of almost every newer JIT out there.

The Compiler class is a vestige of the early days of JIT thought,
relatively speaking, and I honestly don't know why the it hasn't been
marked officially deprecated, given that that is effectively its
status.

-dan

MIME-Version: 1.0
Date: Mon, 15 Dec 2008 11:44:16 -0800 (PST)
In-Reply-To: <8084e12c0812151025k7eb2486x8c58d2c5e30d49f1@mail.gmail.com>
References: <8084e12c0812151025k7eb2486x8c58d2c5e30d49f1@mail.gmail.com>
User-Agent: G2/1.0
Message-ID: <92f59e5b-aca5-45c1-bc63-a081df0d8cb7@p2g2000prf.googlegroups.com>
Subject: Re: On JITs (was Re: Negative culture of Android Market reviews)
From: blindfold <seeingwithso...@gmail.com>
To: Android Discuss <android-discuss@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

OK, thank you Dan, your position is clear. I just hope that it will -
with the current indefinite planning and no mention of JIT on the
Android roadmap - not take forever before Android developers can get
the JIT speed performance levels that they are used to with most Java
ME based phones. If you are convinced that the relatively unknown
compileClass() would only hamper development of your likely JIT
implementation, then by all means drop it in favor of other (upward
compatible) means to speed up the process of bridging the performance
gaps. I hope that Google will not just throw it over the wall at a
moment that no one is expecting it, because developers need to plan
their actions too. I would dislike having to implement a temporary JNI-
based solution as much as you dislike compileClass(), I suppose:
effort that is largely wasted as soon as a good JIT compiler becomes
available. Sharing more planning information could at least ease the
developer pain here, because currently we do not have the foggiest
idea when what to expect.

Regards

On Dec 15, 7:25=A0pm, Dan Bornstein <danf...@android.com> wrote:
> On Fri, Dec 12, 2008 at 4:01 PM, blindfold <seeingwithso...@gmail.com> wr=
ote:
> >> What I mean is that I would be surprised to find many implementations
> >> of java.lang.Compiler.compileClass() that didn't look like this:
>
> >> =A0 public boolean compileClass(Class c) { return false; }
>
> >> including in systems that actually do perform JIT compilation.
>
> > Are you talking about implementations of the javac compiler or
> > implementations of the java VM (JVM)?
>
> I mean implementations of the core library. You can find the Dalvik
> one in the source under </dalvik/libcore/luni-kernel/>.
>
> > For Android it does not matter
> > what the existing JVMs do with the call, because Android has its own
> > VM. [...] I think that Android has full control over what
> > compileClass() returns
>
> Yes, we control compileClass() for Android, but it still *does*
> matter, because the Android effort in this area is overwhelmingly to
> implement a familiar class library. Since the prevailing common
> implementation leaves this method effectively unimplemented, we don't
> have a compelling reason to implement it ourselves, *especially*
> because implementing it would represent a significant amount of work
> for no real benefit, again, because our likely JIT implementation
> couldn't possibly be exercised well by using this class.
>
> The IBM article from 2002 that you cite in a followup talks about
> using it to "prove that the JIT doesn't take any internal errors."
> Given that the operation of this method in our case would be *very*
> different than the usual way the JIT runs, you wouldn't actually be
> able to "prove" such things in the case of Dalvik, and this would also
> be true of almost every newer JIT out there.
>
> The Compiler class is a vestige of the early days of JIT thought,
> relatively speaking, and I honestly don't know why the it hasn't been
> marked officially deprecated, given that that is effectively its
> status.
>