Re: API review of VarHandles

[Paul Sandoz]

> On 10 Feb 2016, at 02:03, Hans Boehm  wrote:
> 
> I found this a bit scary for naive readers:
> 
> * The Java Language Specification permits operations to be executed in
> * orders different than are apparent in program source code, subject to
> * constraints arising, for example, from the use of locks, {@code volatile}
> * fields or VarHandles.
> 
> I would change it to
> 
> * The Java Language Specification permits other threads to observe operations
> * as if they were executed in orders different than are apparent in program 
> source code,
> * subject to constraints arising, for example, from the use of locks, {@code 
> volatile}
> * fields or VarHandles.
> 
> to make it clear that we are not talking about intra-thread semantics here.
> 
> That way it will hopefully only be scary to experts, as intended.
> 

Many thanks! updated to what you suggest,
Paul.

Re: API review of VarHandles

[Paul Sandoz]

Hi Jeremy,

Sorry for the late reply. Catching after some distractions and being away.


> On 22 Jan 2016, at 19:03, Jeremy Manson  wrote:
> 
> Couple of thoughts:
> The Java Language Specification permits operations to be executed in orders 
> different than are apparent in program source code, subject to constraints 
> arising, for example, from the use of locks, volatile fields or VarHandles. 
> The static methods, fullFence, acquireFence, releaseFence, loadLoadFence 
> andstoreStoreFence, can also be used to impose constraints. Their 
> specifications are phrased in terms of the lack of "reorderings" -- 
> observable ordering effects that might otherwise occur if the fence were not 
> present.
> 
> 
> There is no notion of reordering (per se) in the JLS; the fact that 
> reorderings can occur is just implied by the way programs can be observed to 
> behave. So, these fence operations don't map to anything non-implementation 
> dependent.  I don't think it would be impossible to fix the spec to define 
> something that works the way you want (similar to the final field semantics), 
> but it isn't in there already.  You might want to call that out (either by 
> saying this behavior is best effort implementation-dependent or by fixing the 
> spec).
> 

Until we update the JMM spec, pushed out beyond 9, we are in a bit of a bind 
and have to hand wave a bit for both access mode methods and fences, both of 
which talk about reorderings (see getAcquire/setRelease for example).

There is the following at the end, but it’s easy to loose sight of with all the 
other sections:

* @apiNote
* More precise phrasing of the specification of access mode methods and memory
* fence methods may accompany future updates of the Java Language
* Specification.

I moved that up into the fences paragraph.

* In addition to supporting access to variables under various access modes,
* a set of static methods, referred to as memory fence methods, is also
* provided for fine-grained control of memory ordering.
*
* The Java Language Specification permits operations to be executed in
* orders different than are apparent in program source code, subject to
* constraints arising, for example, from the use of locks, {@code volatile}
* fields or VarHandles.  The static methods, {@link #fullFence fullFence},
* {@link #acquireFence acquireFence}, {@link #releaseFence releaseFence},
* {@link #loadLoadFence loadLoadFence} and {@link #storeStoreFence
* storeStoreFence}, can also be used to impose constraints.  Their
* specifications, as is the case for certain access modes, are phrased in terms
* of the lack of "reorderings" -- observable ordering effects that might
* otherwise occur if the fence was not present.  More precise phrasing of the
* specification of access mode methods and memory fence methods may accompany
* future updates of the Java Language Specification.


I could append another sentence:

  Until then, such reordering behaviour is considered implementation-dependent 
on a best-effort basis.

But perhaps the less we say the better?


> If a VarHandle references a read-only variable (for example a final field) 
> then write, atomic update and numeric atomic update access modes are not 
> supported and corresponding methods throw UnsupportedOperationException.
> 
> Are you sure you want to limit it in this way?  There are an awful lot of 
> calls to setAccessible in the world of reflection.  And writing to final 
> fields *does* map to something sensible in the spec.  In fact, it would be 
> great to have something that wasn't quite such a blunt instrument as 
> setAccessible.

Indeed, very much a blunt instrument.

Note that setAccessible would otherwise be required to be called on the Field 
before being unreflected (either for unreflectVarHandle or, as is the case 
today, unreflectSetter/Getter).

I don’t wanna widen the accessibility hole of this blunt instrument right now; 
it’s easy to widen rather than shrink later on if need be.

The motivation behind this is we want to move towards a world "final really 
means final" and thus lots of nice optimisations may ensue. It may be a long 
and windy road to get there but we have some plans and are starting to work 
some routes towards that goal.


> 
> getVolatile
> public final Object getVolatile(Object... args)
> Returns the value of a variable, with memory semantics of reading a volatile 
> variable.
> 
> Reading *which* volatile variable?  You probably mean that all getVolatiles 
> and setVolatiles provide semantics that behave as if the variable being 
> written / read was declared volatile in the first place, but it is worth 
> calling out.
> 

/**
 * Returns the value of a variable, with memory semantics of reading as if
 * the variable was declared {@code volatile}.
...
Object getVolatile(Object... args);

/**
 * Sets the value of a variable to the {@code newValue}, with memory
 * semantics of setting as if the variable was declared {@code 

Re: API review of VarHandles

[Paul Sandoz]

> On 26 Jan 2016, at 22:46, Brian Goetz  wrote:
> 
> I think that expectation is just out of date (if not outright mistaken.)  
> Yes, j.l.i was originally called "java.dyn", but prior to shipping *7* we 
> renamed it to j.l.i precisely because it had turned into a general 
> customizable linkage mechanism that was usable far beyond dynamic languages. 
> (To wit, Java 8 lambdas got a significant linkage/capture boost from using 
> invokedynamic.)  So to claim it's "supposed to be" only for dynamic languages 
> represents a significant "missing of the memo.”
> 

Furthermore, Java has always been quite dynamic under the covers of the 
language. See also Aleksey’s recent indy string concat enhancements. In future 
this area is likely to be leveraged further. And i know Remi’s is always on the 
look out to expose indy up to into the language :-) and with good reason.

Paul.

> 
> On 1/26/2016 3:31 PM, Martin Buchholz wrote:
>> There's a big "expectations" effect here.  j.l.invoke is "supposed to
>> be" for making dynamic languages less slow, not for making low-level,
>> ultra-non-dynamic operations faster.  Asking the Unsafe users of the
>> world to switch to dynamic VarHandle is like asking C programmers to
>> rewrite their code in perl 6 ... for performance!  It's the same
>> "srsly?" feeling one gets reading """We can currently use RPerl to
>> speed up low-magic Perl 5 code with over 300x performance gain."""
> 

Re: API review of VarHandles

[Paul Sandoz]

Hi

Many thanks for the feedback so far.

Some high-level responses:

1) I don’t think there is much we can do right now to reduce the verbosity of 
reflective lookup. We have discussed this at least once before in the past. We 
need field literals, as mentioned in the JEP, to really knock this on the head 
(which might lead to constant pool forms, or even a “constant-dynamic”, and 
perhaps local variables to VHs that constant fold). But such support of 
literals is just too much work to take on at the moment.

2) Examples are needed in api notes much like there are examples for MHs. It 
might be possible to rearrange things so it’s more user-focused up front with 
suitable "Government Health Warnings". I wanted to focus on the normative 
aspects first.

3) Yes, it’s a sharp knife, a low-level building block, consolidating many 
forms of access and shape under one interface, designed for power users to 
avail of directly or wrap in higher-level forms as required, and leveraging the 
low-level method handle invocation mechanism that has been heavily optimized to 
constant fold and inline.

Paul.

> On 21 Jan 2016, at 23:42, Paul Sandoz  wrote:
> 
> Hi
> 
> This is a request to review the VarHandles API. The code reviews and pushes 
> will occur separately, and flow through the hs-comp repo, most likely from 
> the bottom up first with Unsafe changes.
> 
> The specdiff can be found here:
> 
>  
> http://cr.openjdk.java.net/~psandoz/jdk9/varhandles/specdiff/overview-summary.html
> 
> (Note that specdiff renders some aspects of JavaDoc incorrectly, so just 
> ignore any such quirks.)
> 
> A consensus on the set of access mode methods proposed by Doug was previously 
> discussed and reached.
> 
> For the moment please ignore the following methods on MethodHandles: 
> byteArrayViewVarHandle; and byteBufferViewVarHandle. It is necessary to 
> revisit that functionality w.r.t. alignment and proposed enhancements to 
> ByteBuffer (in discussion on valhalla-dev).
> 
> Paul.
> 
> 

Re: API review of VarHandles

[Martin Buchholz]

There's a big "expectations" effect here.  j.l.invoke is "supposed to
be" for making dynamic languages less slow, not for making low-level,
ultra-non-dynamic operations faster.  Asking the Unsafe users of the
world to switch to dynamic VarHandle is like asking C programmers to
rewrite their code in perl 6 ... for performance!  It's the same
"srsly?" feeling one gets reading """We can currently use RPerl to
speed up low-magic Perl 5 code with over 300x performance gain."""

Re: API review of VarHandles

[Brian Goetz]

I think that expectation is just out of date (if not outright 
mistaken.)  Yes, j.l.i was originally called "java.dyn", but prior to 
shipping *7* we renamed it to j.l.i precisely because it had turned into 
a general customizable linkage mechanism that was usable far beyond 
dynamic languages. (To wit, Java 8 lambdas got a significant 
linkage/capture boost from using invokedynamic.)  So to claim it's 
"supposed to be" only for dynamic languages represents a significant 
"missing of the memo."



On 1/26/2016 3:31 PM, Martin Buchholz wrote:

There's a big "expectations" effect here.  j.l.invoke is "supposed to
be" for making dynamic languages less slow, not for making low-level,
ultra-non-dynamic operations faster.  Asking the Unsafe users of the
world to switch to dynamic VarHandle is like asking C programmers to
rewrite their code in perl 6 ... for performance!  It's the same
"srsly?" feeling one gets reading """We can currently use RPerl to
speed up low-magic Perl 5 code with over 300x performance gain."""

Re: API review of VarHandles

[Michael Haupt]

Hi Martin,

how about seeing j.l.i as a framework for lightweight reflection on the one 
hand, and for method handle-based meta-programming on the other? That's clearly 
usable beyond the domain of dynamic language implementation. Granted, the 
latter remains an important application area, but there are others. For 
example, JEP 280 uses invokedynamic for string concatenation.

In that vein, how about seeing VarHandles as a safer replacement for some of 
the Unsafe API? It's going to be public API, readily usable without having to 
enable access to the carefully tucked-away Unsafe.

Best,

Michael

> Am 26.01.2016 um 21:31 schrieb Martin Buchholz :
> 
> There's a big "expectations" effect here.  j.l.invoke is "supposed to
> be" for making dynamic languages less slow, not for making low-level,
> ultra-non-dynamic operations faster.  Asking the Unsafe users of the
> world to switch to dynamic VarHandle is like asking C programmers to
> rewrite their code in perl 6 ... for performance!  It's the same
> "srsly?" feeling one gets reading """We can currently use RPerl to
> speed up low-magic Perl 5 code with over 300x performance gain."""

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment

Re: API review of VarHandles

[Vitaly Davidovich]

Hi Doug,

I somehow missed your reply and just now noticed it after Martin's last
email quoted it -- thanks for elaborating.

The new name is required because opaque is only "like" C++
> memory_order_relaxed.
> See the jmm-dev list discussions last year for details, but annoyingly,
> Java normal variables and C++ memory_order_relaxed are not quite the
> same, and neither are the same as C-volatile/opaque.


AFAICT, difference between java normal load/store and memory_order_relaxed
is the latter guaranteeing atomicity.  If I'm understanding you correctly,
"opaque" is *just* compiler barrier and does not guarantee atomicity? If
that's so, what is/are the use case(s) for opaque? Andrew mentioned
preventing roach motel movement of loads/stores into the motel.  Is there
something more than that?

Assuming my above statement is correct, it would seem like having
memory_order_relaxed would be more useful than simply "no code motion
around this load/store", or if not more useful, just useful on its own;
there's plenty of code that doesn't care about ordering but would not
tolerate torn reads/stores.


On Fri, Jan 22, 2016 at 8:23 AM, Doug Lea  wrote:

> On 01/22/2016 04:51 AM, Andrew Haley wrote:
>
>> On 22/01/16 00:01, Vitaly Davidovich wrote:
>>
>>> I think the get/setOpaque methods need a bit more explanation ("opaque"
>>> is
>>> an odd naming choice, IMO).  Specifically, it says the operations are
>>> done
>>> in program order but have no effect on inter-thread ordering/visibility.
>>> Is this spec verbiage for a full compiler-only fence?
>>>
>>
>
> Basically yes. It would be the same as C "volatile" (not C++/C11
> "atomic"), if C volatile had a memory model spec. But in any case
> we can't use "volatile" for this in Java because it already means
> something else.
>
>
>> It's like C++ memory_order_relaxed, I guessed.  I understand that but
>> not "opaque".
>>
>>
> The new name is required because opaque is only "like" C++
> memory_order_relaxed.
> See the jmm-dev list discussions last year for details, but annoyingly,
> Java normal variables and C++ memory_order_relaxed are not quite the
> same, and neither are the same as C-volatile/opaque.
>
> -Doug
>
>
>
>

Re: API review of VarHandles

[Martin Buchholz]

On Fri, Jan 22, 2016 at 5:23 AM, Doug Lea  wrote:
> On 01/22/2016 04:51 AM, Andrew Haley wrote:
>>
>> On 22/01/16 00:01, Vitaly Davidovich wrote:
>>>
>>> I think the get/setOpaque methods need a bit more explanation ("opaque"
>>> is
>>> an odd naming choice, IMO).  Specifically, it says the operations are
>>> done
>>> in program order but have no effect on inter-thread ordering/visibility.
>>> Is this spec verbiage for a full compiler-only fence?
>
>
>
> Basically yes. It would be the same as C "volatile" (not C++/C11
> "atomic"), if C volatile had a memory model spec. But in any case
> we can't use "volatile" for this in Java because it already means
> something else.

It would be nice if we could actually say this in the (non-normative
part of the) javadoc.

>>
>> It's like C++ memory_order_relaxed, I guessed.  I understand that but
>> not "opaque".
>>
>
> The new name is required because opaque is only "like" C++
> memory_order_relaxed.
> See the jmm-dev list discussions last year for details, but annoyingly,
> Java normal variables and C++ memory_order_relaxed are not quite the
> same, and neither are the same as C-volatile/opaque.

Could we make atomicity guarantees clear for every method?  When can
we be sure not to get OOTA values?

Re: API review of VarHandles

[Martin Buchholz]

This is my first attempt to understand  java.lang.invoke. It seems
like a new alien world, non-java-like.  I'll need to rebuild my
internal performance model of java code, perhaps by staring at jit
compiled code.

I expect new APIs for atomic variable access to appear in
j.u.c.atomic, not j.l.invoke.  Aleksey has made atomic updaters fast.
Can we continue on that road, providing more updaters or more methods
on current updaters?

Sequential consistency is much easier than release/acquire, which is
in turn much easier than load/load store/store. (using the latter is
almost always a mistake?)
Memory ordering combined with variables is easier than independent fences.
I continue to be uneasy about handing out the sharpest knives in public APIs.
We're not providing much in the way of scare text to get users to think twice.

Re: API review of VarHandles

[Andrew Haley]

On 22/01/16 00:01, Vitaly Davidovich wrote:
> I think the get/setOpaque methods need a bit more explanation ("opaque" is
> an odd naming choice, IMO).  Specifically, it says the operations are done
> in program order but have no effect on inter-thread ordering/visibility.
> Is this spec verbiage for a full compiler-only fence?

It's like C++ memory_order_relaxed, I guessed.  I understand that but
not "opaque".

Andrew.

Re: API review of VarHandles

[Peter Levart]

Hi Paul,

I found a typo (which was probably caused by unconscious influence from 
jigsaw ;-). Search for "Java Memory Module"...


Regards, Peter

On 01/21/2016 11:42 PM, Paul Sandoz wrote:

Hi

This is a request to review the VarHandles API. The code reviews and pushes 
will occur separately, and flow through the hs-comp repo, most likely from the 
bottom up first with Unsafe changes.

The specdiff can be found here:

   
http://cr.openjdk.java.net/~psandoz/jdk9/varhandles/specdiff/overview-summary.html

(Note that specdiff renders some aspects of JavaDoc incorrectly, so just ignore 
any such quirks.)

A consensus on the set of access mode methods proposed by Doug was previously 
discussed and reached.

For the moment please ignore the following methods on MethodHandles: 
byteArrayViewVarHandle; and byteBufferViewVarHandle. It is necessary to revisit 
that functionality w.r.t. alignment and proposed enhancements to ByteBuffer (in 
discussion on valhalla-dev).

Paul.

Re: API review of VarHandles

[Vitaly Davidovich]

On Thursday, January 21, 2016, Brian Goetz  wrote:

>
> I am baffled as to how the original language syntax proposal of using some
>> trick like "xx.volatile.imaginaryMethod()" plus maybe one or two new
>> bytecodes was considered unacceptable; looking at this API, I know that
>> none of the aforementioned metrics were considered as acceptance criteria.
>> How did we get to this strange place?
>>
>
> The path was actually quite obvious.
>
> The first question was, "OK, if the language had this magic syntax, what
> bytecode would get generated?  And clearly it couldn't be Unsafe.  So
> either a pile of new bytecodes, or an API, was needed that the front-end
> compiler could generate against.
>
> Building APIs is generally preferable to new bytecodes, if an API can do
> the job, and it turned out that it could do it just as well. Once we had an
> API that met the requirements, it was pretty clear that language syntax was
> not only unnecessary, but likely undesirable -- these exotic access modes
> are power tools for power users (do you really want typical users to reason
> about mixed volatile and relaxed access to variables?), and they meet the
> needs of such users just fine (those users have been using Unsafe all
> along, and this is clearly better and safer.)


The VarHandle API isn't ergonomic like Unsafe; this being for power users
is irrelevant to the ergonomics of the API.  Instead, it's fairly verbose
with setup ceremony.  Now, I personally don't mind that too much and more
interested in the features it provides but I'm not surprised by David's
reaction.

People already provide nicer APIs on top of Unsafe in their own projects,
and I suspect this will be even more so with VH.


>
> So it was not the either-or of "either an API *or* magic language syntax",
> it was "either an API *or* syntax plus an API".  At which point it was
> clear that the syntax didn't carry its own weight.
>
> I think this is a fine example of how the obvious idea was wrong, and that
> most of the value of the initial syntax idea was framing the problem
> space.  I'm glad we saw fit to jettison that when it ceased to provide
> value.
>
>
>

-- 
Sent from my phone

Re: API review of VarHandles

[Vitaly Davidovich]

On Friday, January 22, 2016, Andrew Haley  wrote:

> On 22/01/16 00:01, Vitaly Davidovich wrote:
> > I think the get/setOpaque methods need a bit more explanation ("opaque"
> is
> > an odd naming choice, IMO).  Specifically, it says the operations are
> done
> > in program order but have no effect on inter-thread ordering/visibility.
> > Is this spec verbiage for a full compiler-only fence?
>
> It's like C++ memory_order_relaxed, I guessed.  I understand that but
> not "opaque".

I thought so too before reading opaque javadoc (no pun intended).  C++
relaxed says nothing about order though, only atomicity.  Opaque doesn't
mention atomicity at all.

I'm guessing opaque is compiler only fence because a method that a compiler
doesn't inline (as an example) is considered "opaque" to the compiler and
serves like a fence.  Perhaps that's how opaque ended up here.  At any
rate, I think it's a poor name.

>
> Andrew.
>


-- 
Sent from my phone

Re: API review of VarHandles

[Andrew Haley]

On 01/22/2016 11:15 AM, Vitaly Davidovich wrote:

> I'm guessing opaque is compiler only fence because a method that a
> compiler doesn't inline (as an example) is considered "opaque" to
> the compiler and serves like a fence.  Perhaps that's how opaque
> ended up here.  At any rate, I think it's a poor name.

Humm.  I guess so, but I'm not sure why you'd want a compiler fence in
Java.  It's not like C where you can access memory-mapped I/O.  I
suppose it disallows roach-motel code motion.

Andrew.

Re: API review of VarHandles

[Vitaly Davidovich]

On Friday, January 22, 2016, Andrew Haley  wrote:

> On 01/22/2016 11:15 AM, Vitaly Davidovich wrote:
>
> > I'm guessing opaque is compiler only fence because a method that a
> > compiler doesn't inline (as an example) is considered "opaque" to
> > the compiler and serves like a fence.  Perhaps that's how opaque
> > ended up here.  At any rate, I think it's a poor name.
>
> Humm.  I guess so, but I'm not sure why you'd want a compiler fence in
> Java.  It's not like C where you can access memory-mapped I/O.  I
> suppose it disallows roach-motel code motion.


Well that's part of my confusion on what this is :).  C++ relaxed makes
sense to me - don't care about anything other than atomicity, which could
be useful for Java too so that one could reliably/portably do atomic stores
to, e.g, longs and have that compile to plain mov on 64 bit machines and
something possibly more expensive on 32 bit.  Maybe that's what this
actually is but "program order" is too vague here.

>
> Andrew.
>


-- 
Sent from my phone

Re: API review of VarHandles

[Aleksey Shipilev]

On 01/22/2016 03:08 PM, Vitaly Davidovich wrote:
> The VarHandle API isn't ergonomic like Unsafe; this being for power users
> is irrelevant to the ergonomics of the API.  Instead, it's fairly verbose
> with setup ceremony.  Now, I personally don't mind that too much and more
> interested in the features it provides but I'm not surprised by David's
> reaction.

Um, I don't get the "fairly verbose" and "setup ceremony" parts,
especially in comparison with Unsafe. Unsafe also comes with a setup
ceremony, don't you think?

See:

public class C {
  static class CU {
static final Unsafe U;
static final long OFFSET;

static {
  try {
Field f = Unsafe.class.getDeclaredField("theUnsafe");
f.setAccessible(true);
U = (Unsafe) f.get(null);
OFFSET = U.objectFieldOffset(CU.class.getDeclaredField("x"));
  } catch (ReflectiveOperationException eh) {
throw new IllegalStateException(eh);
  }
}

private int x;

public boolean doCas(int expected, int value) {
  return U.compareAndSwapInt(this, OFFSET, expected, value);
}
  }

  static class VU {
static final VarHandle VH;

static {
  try {
VH = MethodHandles.lookup().findVarHandle(
VU.class, "x", int.class);
  } catch (ReflectiveOperationException eh) {
throw new IllegalStateException(eh);
  }
}

private int x;

public boolean doCas(int expected, int value) {
  return VH.compareAndSet(this, expected, value);
}
  }
}

Even if you pull off Unsafe lookup into separate "holder" class, you'd
still need to lookup OFFSET.

Granted, VH lookup requires learning new stuff, but so does Unsafe,
A*FU, Reflection, or any other special API/syntax. The mind trick is
that you already *know* all those APIs, and so they appear conceptually
simple to you. Once you internalize that VarHandle is a "handle", which
you have to acquire before use, it clicks.


> People already provide nicer APIs on top of Unsafe in their own projects,
> and I suspect this will be even more so with VH.

Yes, but lacking the syntax support, that's the best you can do:

 static class MyAwesomeWrapper {
   public static VarHandle iAmPrettySureThatFieldExists(
  MethodHandles.Lookup lookup, Class recv, String name,
  Class type) {
  try {
return lookup.findVarHandle(recv, name, type);
  } catch (ReflectiveOperationException eh) {
throw new IllegalStateException(eh);
  }
}
  }

  static class VUH {
static final VarHandle VH =
MyAwesomeWrapper.iAmPrettySureThatFieldExists(
  MethodHandles.lookup(),
  VUH.class, "x", int.class);

private int x;

public boolean doCas(int expected, int value) {
  return VH.compareAndSet(this, expected, value);
}
  }

...which is not that bad?

I am not discounting David's comments about the conceptual complexity of
the documentation. It looks like a normative text that 99% users would
not read, but stroll straight into code examples.

-Aleksey

Re: API review of VarHandles

[Doug Lea]

On 01/22/2016 04:51 AM, Andrew Haley wrote:

On 22/01/16 00:01, Vitaly Davidovich wrote:

I think the get/setOpaque methods need a bit more explanation ("opaque" is
an odd naming choice, IMO).  Specifically, it says the operations are done
in program order but have no effect on inter-thread ordering/visibility.
Is this spec verbiage for a full compiler-only fence?



Basically yes. It would be the same as C "volatile" (not C++/C11
"atomic"), if C volatile had a memory model spec. But in any case
we can't use "volatile" for this in Java because it already means
something else.



It's like C++ memory_order_relaxed, I guessed.  I understand that but
not "opaque".



The new name is required because opaque is only "like" C++ memory_order_relaxed.
See the jmm-dev list discussions last year for details, but annoyingly,
Java normal variables and C++ memory_order_relaxed are not quite the
same, and neither are the same as C-volatile/opaque.

-Doug

Re: API review of VarHandles

[Vitaly Davidovich]

On Friday, January 22, 2016, Aleksey Shipilev 
wrote:

> On 01/22/2016 03:08 PM, Vitaly Davidovich wrote:
> > The VarHandle API isn't ergonomic like Unsafe; this being for power users
> > is irrelevant to the ergonomics of the API.  Instead, it's fairly verbose
> > with setup ceremony.  Now, I personally don't mind that too much and more
> > interested in the features it provides but I'm not surprised by David's
> > reaction.
>
> Um, I don't get the "fairly verbose" and "setup ceremony" parts,
> especially in comparison with Unsafe. Unsafe also comes with a setup
> ceremony, don't you think?


Yes unsafe also has some ceremony, but it seems like VH is a bit more so.
As I mentioned, I'm not too bothered by that aspect given wrappers will be
built anyway (just like Unsafe).

But, if this were in the language it would likely be more ergonomic.  Not
saying ergonomics trumps everything else, but it's something David alluded
to (lang vs API).

>
> See:
>
> public class C {
>   static class CU {
> static final Unsafe U;
> static final long OFFSET;
>
> static {
>   try {
> Field f = Unsafe.class.getDeclaredField("theUnsafe");
> f.setAccessible(true);
> U = (Unsafe) f.get(null);
> OFFSET = U.objectFieldOffset(CU.class.getDeclaredField("x"));
>   } catch (ReflectiveOperationException eh) {
> throw new IllegalStateException(eh);
>   }
> }
>
> private int x;
>
> public boolean doCas(int expected, int value) {
>   return U.compareAndSwapInt(this, OFFSET, expected, value);
> }
>   }
>
>   static class VU {
> static final VarHandle VH;
>
> static {
>   try {
> VH = MethodHandles.lookup().findVarHandle(
> VU.class, "x", int.class);
>   } catch (ReflectiveOperationException eh) {
> throw new IllegalStateException(eh);
>   }
> }
>
> private int x;
>
> public boolean doCas(int expected, int value) {
>   return VH.compareAndSet(this, expected, value);
> }
>   }
> }
>
> Even if you pull off Unsafe lookup into separate "holder" class, you'd
> still need to lookup OFFSET.
>
> Granted, VH lookup requires learning new stuff, but so does Unsafe,
> A*FU, Reflection, or any other special API/syntax. The mind trick is
> that you already *know* all those APIs, and so they appear conceptually
> simple to you. Once you internalize that VarHandle is a "handle", which
> you have to acquire before use, it clicks.


I get the handle part and don't have a problem with the concept.  I do
agree that one will get used to it.  Again, for me, features matter more
than syntax (for the most part).

>
>
> > People already provide nicer APIs on top of Unsafe in their own projects,
> > and I suspect this will be even more so with VH.
>
> Yes, but lacking the syntax support, that's the best you can do:
>
>  static class MyAwesomeWrapper {
>public static VarHandle iAmPrettySureThatFieldExists(
>   MethodHandles.Lookup lookup, Class recv, String name,
>   Class type) {
>   try {
> return lookup.findVarHandle(recv, name, type);
>   } catch (ReflectiveOperationException eh) {
> throw new IllegalStateException(eh);
>   }
> }
>   }
>
>   static class VUH {
> static final VarHandle VH =
> MyAwesomeWrapper.iAmPrettySureThatFieldExists(
>   MethodHandles.lookup(),
>   VUH.class, "x", int.class);
>
> private int x;
>
> public boolean doCas(int expected, int value) {
>   return VH.compareAndSet(this, expected, value);
> }
>   }
>
> ...which is not that bad?
>
> I am not discounting David's comments about the conceptual complexity of
> the documentation. It looks like a normative text that 99% users would
> not read, but stroll straight into code examples.


I'm actually not bothered by the spec-like docs; in fact I like the extra
detail in the same place as the API.  Perhaps it can be rearranged so the
impl details are not the first thing a reader sees.  This is, by
definition, a low level API with misuse leading to very subtle bugs - over
documenting is much better than under documenting.

>
> -Aleksey
>
>

-- 
Sent from my phone

Re: API review of VarHandles

[Aleksey Shipilev]

On 01/22/2016 04:54 PM, David M. Lloyd wrote:
> The costs are both performance and memory overhead.  The
> Atomic*FieldUpdaters are good for memory usage and reasonably usable,
> but suffer from performance problems and generics issues. 

Hopefully, not anymore:
 http://shipilev.net/blog/2015/faster-atomic-fu/

BTW, those are the same techniques we use to compile VarHandles down to
the naked memory accesses.

Cheers,
-Aleksey

Re: API review of VarHandles

[Vitaly Davidovich]

+1, good stuff Aleksey (I had actually seen chatter about this change on
one of these openjdk lists, but people have already moved away from the
field updaters), except every time I think about final instance fields not
being treated as constants I get sad :).  The other wrinkle is the "am I
lucky today to get proper inlining" in order to peel away costs.  I'm not
sure whether VH machinery will make this work reliably, irrespective of
callsite frequency, inlining depth, etc (that's another advantage of
bytecode -- there's no need to crack method chains).



On Fri, Jan 22, 2016 at 9:04 AM, David M. Lloyd 
wrote:

> On 01/22/2016 07:57 AM, Aleksey Shipilev wrote:
>
>> On 01/22/2016 04:54 PM, David M. Lloyd wrote:
>>
>>> The costs are both performance and memory overhead.  The
>>> Atomic*FieldUpdaters are good for memory usage and reasonably usable,
>>> but suffer from performance problems and generics issues.
>>>
>>
>> Hopefully, not anymore:
>>   http://shipilev.net/blog/2015/faster-atomic-fu/
>>
>> BTW, those are the same techniques we use to compile VarHandles down to
>> the naked memory accesses.
>>
>
> Great, nice work, and nice article!
> --
> - DML
>

Re: API review of VarHandles

[David M. Lloyd]

On 01/21/2016 07:32 PM, Brian Goetz wrote:



I am baffled as to how the original language syntax proposal of using
some trick like "xx.volatile.imaginaryMethod()" plus maybe one or two
new bytecodes was considered unacceptable; looking at this API, I know
that none of the aforementioned metrics were considered as acceptance
criteria.  How did we get to this strange place?


The path was actually quite obvious.

The first question was, "OK, if the language had this magic syntax, what
bytecode would get generated?  And clearly it couldn't be Unsafe.  So
either a pile of new bytecodes, or an API, was needed that the front-end
compiler could generate against.

Building APIs is generally preferable to new bytecodes, if an API can do
the job, and it turned out that it could do it just as well. Once we had
an API that met the requirements, it was pretty clear that language
syntax was not only unnecessary, but likely undesirable -- these exotic
access modes are power tools for power users (do you really want typical
users to reason about mixed volatile and relaxed access to variables?),
and they meet the needs of such users just fine (those users have been
using Unsafe all along, and this is clearly better and safer.)

So it was not the either-or of "either an API *or* magic language
syntax", it was "either an API *or* syntax plus an API".  At which point
it was clear that the syntax didn't carry its own weight.

I think this is a fine example of how the obvious idea was wrong, and
that most of the value of the initial syntax idea was framing the
problem space.  I'm glad we saw fit to jettison that when it ceased to
provide value.


I will contest the "APIs is generally preferable to new bytecodes, if an 
API can do the job" tack because it clearly doesn't track logically: 
most of the bytecodes in the JVM today could have been intrinsic API 
methods instead, e.g. Integer.add(int, int) and that sort of thing, but 
they clearly benefit from being bytecodes just from a simplicity 
standpoint.  Having new bytecodes would certainly be simpler for javac; 
it would be simpler for the user also, especially the user of class 
generators and transformers (who by this point will now have to do some 
pretty bananas things to transform field references); I can only 
speculate that it would also be simpler for the interpreter/JIT itself 
as well because really you're just generating variations on getfield, 
*aload, etc.  But that is all besides the point.


Even the API itself is really heavy and weird.  Experts need simple APIs 
more than anyone - especially those writing complex concurrent 
algorithms.  They're the ones who aren't content to copy and paste blobs 
off of StackOverflow; rather they need to be able to prove that their 
program is correct, and the more complexity there is, the more difficult 
a task that becomes.  But even the premise that this API is experts-only 
is self-fulfilling: atomics and fences are quite useful to less advanced 
users too, especially simple get-and-set and CAS operations.  But there 
is little chance that this API is going to be used (or used correctly) 
by such users.


I have no problem with the methods present on the final product, in 
terms of the types of fences and operations.  But the setup procedures 
and concepts are far more complex than necessary, and I don't see this 
being useful to most users in its current shape as most people will flee 
from it.


--
- DML

Re: API review of VarHandles

[Vitaly Davidovich]

On Friday, January 22, 2016, David M. Lloyd  wrote:

> On 01/21/2016 07:32 PM, Brian Goetz wrote:
>
>>
>> I am baffled as to how the original language syntax proposal of using
>>> some trick like "xx.volatile.imaginaryMethod()" plus maybe one or two
>>> new bytecodes was considered unacceptable; looking at this API, I know
>>> that none of the aforementioned metrics were considered as acceptance
>>> criteria.  How did we get to this strange place?
>>>
>>
>> The path was actually quite obvious.
>>
>> The first question was, "OK, if the language had this magic syntax, what
>> bytecode would get generated?  And clearly it couldn't be Unsafe.  So
>> either a pile of new bytecodes, or an API, was needed that the front-end
>> compiler could generate against.
>>
>> Building APIs is generally preferable to new bytecodes, if an API can do
>> the job, and it turned out that it could do it just as well. Once we had
>> an API that met the requirements, it was pretty clear that language
>> syntax was not only unnecessary, but likely undesirable -- these exotic
>> access modes are power tools for power users (do you really want typical
>> users to reason about mixed volatile and relaxed access to variables?),
>> and they meet the needs of such users just fine (those users have been
>> using Unsafe all along, and this is clearly better and safer.)
>>
>> So it was not the either-or of "either an API *or* magic language
>> syntax", it was "either an API *or* syntax plus an API".  At which point
>> it was clear that the syntax didn't carry its own weight.
>>
>> I think this is a fine example of how the obvious idea was wrong, and
>> that most of the value of the initial syntax idea was framing the
>> problem space.  I'm glad we saw fit to jettison that when it ceased to
>> provide value.
>>
>
> I will contest the "APIs is generally preferable to new bytecodes, if an
> API can do the job" tack because it clearly doesn't track logically: most
> of the bytecodes in the JVM today could have been intrinsic API methods
> instead, e.g. Integer.add(int, int) and that sort of thing, but they
> clearly benefit from being bytecodes just from a simplicity standpoint.
> Having new bytecodes would certainly be simpler for javac; it would be
> simpler for the user also, especially the user of class generators and
> transformers (who by this point will now have to do some pretty bananas
> things to transform field references); I can only speculate that it would
> also be simpler for the interpreter/JIT itself as well because really
> you're just generating variations on getfield, *aload, etc.  But that is
> all besides the point.
>
> Even the API itself is really heavy and weird.  Experts need simple APIs
> more than anyone - especially those writing complex concurrent algorithms.
> They're the ones who aren't content to copy and paste blobs off of
> StackOverflow; rather they need to be able to prove that their program is
> correct, and the more complexity there is, the more difficult a task that
> becomes.  But even the premise that this API is experts-only is
> self-fulfilling: atomics and fences are quite useful to less advanced users
> too, especially simple get-and-set and CAS operations.  But there is little
> chance that this API is going to be used (or used correctly) by such users.


Experts need control more than anything else.  This is not to say they'll
be happy with a subpar API but control typically means lots of details so
there's a limit on how abstracted the API can be.  As mentioned, given the
API provides low level control one can build a higher level one for their
own needs.  The topic of ordering is complex by its nature, there's a
danger in hiding details in more abstract API.

>
> I have no problem with the methods present on the final product, in terms
> of the types of fences and operations.  But the setup procedures and
> concepts are far more complex than necessary, and I don't see this being
> useful to most users in its current shape as most people will flee from it.
>
> --
> - DML
>


-- 
Sent from my phone

Re: API review of VarHandles

[Vitaly Davidovich]

Which existing Atomic* classes? I take it you mean the field updaters and
not AtomicInteger and friends.  The biggest issue with field updaters is
their performance, for me.  I take it you mean something else by "costs"
though? Having to specify the target (field) as a string is annoying, and I
do wish there was a way javac could assist there.  VH is no worse in this
respect, but also no better.

On Fri, Jan 22, 2016 at 8:34 AM, David M. Lloyd 
wrote:

> On 01/22/2016 07:29 AM, Vitaly Davidovich wrote:
>
>> Experts need control more than anything else.  This is not to say they'll
>> be happy with a subpar API but control typically means lots of details so
>> there's a limit on how abstracted the API can be.  As mentioned, given the
>> API provides low level control one can build a higher level one for their
>> own needs.  The topic of ordering is complex by its nature, there's a
>> danger in hiding details in more abstract API.
>>
>
> I understand that, and that is reasonable.  However, will it be possible
> to build higher level APIs on this that do not suffer the same costs that
> make the existing Atomic* classes unattractive?
>
> --
> - DML
>

Re: API review of VarHandles

[David M. Lloyd]

On 01/22/2016 07:29 AM, Vitaly Davidovich wrote:

Experts need control more than anything else.  This is not to say they'll
be happy with a subpar API but control typically means lots of details so
there's a limit on how abstracted the API can be.  As mentioned, given the
API provides low level control one can build a higher level one for their
own needs.  The topic of ordering is complex by its nature, there's a
danger in hiding details in more abstract API.


I understand that, and that is reasonable.  However, will it be possible 
to build higher level APIs on this that do not suffer the same costs 
that make the existing Atomic* classes unattractive?


--
- DML

Re: API review of VarHandles

[Vitaly Davidovich]

So in this regard, VH ought to be better since it will have performance
like Unsafe (rather than field updaters - is that accurate by the way? Is
VH on par with Unsafe for issuing atomic ops?) and not have the memory
bloat of the instance atomic classes.  Generics is a non-issue for VH.

I do agree with the "this is all just hoop jumping to issue basic memory
ops", but that's more a reflection on Java (memory footprint of atomic
instance classes, generics issues) rather than VH.

On Fri, Jan 22, 2016 at 8:54 AM, David M. Lloyd 
wrote:

> The costs are both performance and memory overhead.  The
> Atomic*FieldUpdaters are good for memory usage and reasonably usable, but
> suffer from performance problems and generics issues.  The "regular"
> Atomic* classes have good usability (including with generic types) and
> generally very good performance on the actual operations, but generally
> unacceptable memory overhead.  The only way to do atomic array element
> access is via the Atomic*Array though, which has pretty good performance
> but again has memory overhead that can be unacceptable.
>
> Overall this whole thing is a lot of gymnastics for something that's
> basically a fancy way of accessing a plain field or array element - one of
> the most basic concepts in Java.
>
>
> On 01/22/2016 07:40 AM, Vitaly Davidovich wrote:
>
>> Which existing Atomic* classes? I take it you mean the field updaters and
>> not AtomicInteger and friends.  The biggest issue with field updaters is
>> their performance, for me.  I take it you mean something else by "costs"
>> though? Having to specify the target (field) as a string is annoying, and
>> I
>> do wish there was a way javac could assist there.  VH is no worse in this
>> respect, but also no better.
>>
>> On Fri, Jan 22, 2016 at 8:34 AM, David M. Lloyd 
>> wrote:
>>
>> On 01/22/2016 07:29 AM, Vitaly Davidovich wrote:
>>>
>>> Experts need control more than anything else.  This is not to say they'll
 be happy with a subpar API but control typically means lots of details
 so
 there's a limit on how abstracted the API can be.  As mentioned, given
 the
 API provides low level control one can build a higher level one for
 their
 own needs.  The topic of ordering is complex by its nature, there's a
 danger in hiding details in more abstract API.


>>> I understand that, and that is reasonable.  However, will it be possible
>>> to build higher level APIs on this that do not suffer the same costs that
>>> make the existing Atomic* classes unattractive?
>>>
>>> --
>>> - DML
>>>
>>>
>>
> --
> - DML
>

Re: API review of VarHandles

[David M. Lloyd]

The costs are both performance and memory overhead.  The 
Atomic*FieldUpdaters are good for memory usage and reasonably usable, 
but suffer from performance problems and generics issues.  The "regular" 
Atomic* classes have good usability (including with generic types) and 
generally very good performance on the actual operations, but generally 
unacceptable memory overhead.  The only way to do atomic array element 
access is via the Atomic*Array though, which has pretty good performance 
but again has memory overhead that can be unacceptable.


Overall this whole thing is a lot of gymnastics for something that's 
basically a fancy way of accessing a plain field or array element - one 
of the most basic concepts in Java.


On 01/22/2016 07:40 AM, Vitaly Davidovich wrote:

Which existing Atomic* classes? I take it you mean the field updaters and
not AtomicInteger and friends.  The biggest issue with field updaters is
their performance, for me.  I take it you mean something else by "costs"
though? Having to specify the target (field) as a string is annoying, and I
do wish there was a way javac could assist there.  VH is no worse in this
respect, but also no better.

On Fri, Jan 22, 2016 at 8:34 AM, David M. Lloyd 
wrote:


On 01/22/2016 07:29 AM, Vitaly Davidovich wrote:


Experts need control more than anything else.  This is not to say they'll
be happy with a subpar API but control typically means lots of details so
there's a limit on how abstracted the API can be.  As mentioned, given the
API provides low level control one can build a higher level one for their
own needs.  The topic of ordering is complex by its nature, there's a
danger in hiding details in more abstract API.



I understand that, and that is reasonable.  However, will it be possible
to build higher level APIs on this that do not suffer the same costs that
make the existing Atomic* classes unattractive?

--
- DML





--
- DML

Re: API review of VarHandles

[David M. Lloyd]

On 01/22/2016 07:57 AM, Aleksey Shipilev wrote:

On 01/22/2016 04:54 PM, David M. Lloyd wrote:

The costs are both performance and memory overhead.  The
Atomic*FieldUpdaters are good for memory usage and reasonably usable,
but suffer from performance problems and generics issues.


Hopefully, not anymore:
  http://shipilev.net/blog/2015/faster-atomic-fu/

BTW, those are the same techniques we use to compile VarHandles down to
the naked memory accesses.


Great, nice work, and nice article!
--
- DML

Re: API review of VarHandles

[Vitaly Davidovich]

Agreed; it's a building block, not an assembled piece.

On Friday, January 22, 2016, Brian Goetz  wrote:

>
> The VarHandle API isn't ergonomic like Unsafe; this being for power users
>> is irrelevant to the ergonomics of the API. Instead, it's fairly verbose
>> with setup ceremony.  Now, I personally don't mind that too much and more
>> interested in the features it provides but I'm not surprised by David's
>> reaction.
>>
>> People already provide nicer APIs on top of Unsafe in their own projects,
>> and I suspect this will be even more so with VH.
>>
>
> And that's absolutely fine with us.  We wanted to provide a secure, safe,
> fast substrate that code generators and brave library writers alike will
> use; if people want to wrap it, we view that as success, not failure.
>
>
>

-- 
Sent from my phone

Re: API review of VarHandles

[Brian Goetz]

The VarHandle API isn't ergonomic like Unsafe; this being for power 
users is irrelevant to the ergonomics of the API. Instead, it's fairly 
verbose with setup ceremony.  Now, I personally don't mind that too 
much and more interested in the features it provides but I'm not 
surprised by David's reaction.


People already provide nicer APIs on top of Unsafe in their own 
projects, and I suspect this will be even more so with VH.


And that's absolutely fine with us.  We wanted to provide a secure, 
safe, fast substrate that code generators and brave library writers 
alike will use; if people want to wrap it, we view that as success, not 
failure.

Re: API review of VarHandles

[David M. Lloyd]

On 01/21/2016 04:42 PM, Paul Sandoz wrote:

Hi

This is a request to review the VarHandles API. The code reviews and pushes 
will occur separately, and flow through the hs-comp repo, most likely from the 
bottom up first with Unsafe changes.

The specdiff can be found here:

   
http://cr.openjdk.java.net/~psandoz/jdk9/varhandles/specdiff/overview-summary.html

(Note that specdiff renders some aspects of JavaDoc incorrectly, so just ignore 
any such quirks.)

A consensus on the set of access mode methods proposed by Doug was previously 
discussed and reached.

For the moment please ignore the following methods on MethodHandles: 
byteArrayViewVarHandle; and byteBufferViewVarHandle. It is necessary to revisit 
that functionality w.r.t. alignment and proposed enhancements to ByteBuffer (in 
discussion on valhalla-dev).


Language like that used in the VarHandle documentation is very precise 
and relevant to a JVM maintainer.  But from a use perspective, this is 
terrible!  Are we really expecting users to make sense of this API?


I can tell you that as a user, I'd be looking for methods that look and 
act just like what I see on the existing Atomic*FieldUpdater style 
classes.  Understanding the dissertation that is the description of 
VarHandles as a prerequisite for using this feature is pretty rough for 
users.


In summary, this API might be expedient implementation-wise (I mean, it 
must be, right?), but in terms of style, future comprehensibility, ease 
of use, understandability, consistency with existing constructs, and (I 
can only imagine) implementation complexity, this monster cannot 
possibly be the best we can do.


I am baffled as to how the original language syntax proposal of using 
some trick like "xx.volatile.imaginaryMethod()" plus maybe one or two 
new bytecodes was considered unacceptable; looking at this API, I know 
that none of the aforementioned metrics were considered as acceptance 
criteria.  How did we get to this strange place?  Is it just that 
MethodHandles are the latest shiny golden hammer?


--
- DML

Re: API review of VarHandles

[Vitaly Davidovich]

I think the get/setOpaque methods need a bit more explanation ("opaque" is
an odd naming choice, IMO).  Specifically, it says the operations are done
in program order but have no effect on inter-thread ordering/visibility.
Is this spec verbiage for a full compiler-only fence?

On Thursday, January 21, 2016, Paul Sandoz  wrote:

> Hi
>
> This is a request to review the VarHandles API. The code reviews and
> pushes will occur separately, and flow through the hs-comp repo, most
> likely from the bottom up first with Unsafe changes.
>
> The specdiff can be found here:
>
>
> http://cr.openjdk.java.net/~psandoz/jdk9/varhandles/specdiff/overview-summary.html
>
> (Note that specdiff renders some aspects of JavaDoc incorrectly, so just
> ignore any such quirks.)
>
> A consensus on the set of access mode methods proposed by Doug was
> previously discussed and reached.
>
> For the moment please ignore the following methods on MethodHandles:
> byteArrayViewVarHandle; and byteBufferViewVarHandle. It is necessary to
> revisit that functionality w.r.t. alignment and proposed enhancements to
> ByteBuffer (in discussion on valhalla-dev).
>
> Paul.
>
>
>

-- 
Sent from my phone

Re: API review of VarHandles

[Brian Goetz]

I am baffled as to how the original language syntax proposal of using 
some trick like "xx.volatile.imaginaryMethod()" plus maybe one or two 
new bytecodes was considered unacceptable; looking at this API, I know 
that none of the aforementioned metrics were considered as acceptance 
criteria.  How did we get to this strange place? 


The path was actually quite obvious.

The first question was, "OK, if the language had this magic syntax, what 
bytecode would get generated?  And clearly it couldn't be Unsafe.  So 
either a pile of new bytecodes, or an API, was needed that the front-end 
compiler could generate against.


Building APIs is generally preferable to new bytecodes, if an API can do 
the job, and it turned out that it could do it just as well. Once we had 
an API that met the requirements, it was pretty clear that language 
syntax was not only unnecessary, but likely undesirable -- these exotic 
access modes are power tools for power users (do you really want typical 
users to reason about mixed volatile and relaxed access to variables?), 
and they meet the needs of such users just fine (those users have been 
using Unsafe all along, and this is clearly better and safer.)


So it was not the either-or of "either an API *or* magic language 
syntax", it was "either an API *or* syntax plus an API".  At which point 
it was clear that the syntax didn't carry its own weight.


I think this is a fine example of how the obvious idea was wrong, and 
that most of the value of the initial syntax idea was framing the 
problem space.  I'm glad we saw fit to jettison that when it ceased to 
provide value.