So, Tom, is it a common misconception that only addresses from
1_00000000 and up are above the bar?  I thought that was the original
reason for the "bar" designation, "thickness" being an intentional
attribute.

How many "lines," then, do we need?  16MB, 2GB, 4GB, 32GB, 288GB . . .

Doug Watkins




The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it.

From: IBM Mainframe Assembler List
[mailto:[email protected]] On Behalf Of Tom Marchant
Sent: Thursday, December 09, 2010 10:37 AM
To: [email protected]
Subject: Re: z/OS IARV64

On Thu, 9 Dec 2010 06:23:45 -0700, Paul Gilmartin wrote:

>I understand that on z/OS Java has a special dispensation to use
>storage within the bar.

I wish you wouldn't write "within the bar".  It suggests that
the bar has thickness, which it does not.  Addresses up to and
including 7FFFFFFF are below the bar.  Addresses from 80000000
and up are above the bar.  "Special dispensation" is not needed.

Prior to that, it is true that that IARV64 would never create a
memory object in the range from 2GB to 4GB.  That was an arbitrary
decision intended to avoid confusion.  As I understand it, there
was some concern that a user might see an address with bits 0-31
all zero and bit 32 on and be confused.  Is it a 31-bit address
with the high order bit on to signify AMODE(31) or is it a 64-bit
address?  It seems to me that it hes led to considerable other
confusion.

As to Java, this was discussed on IBM-MAIN.  See, for example,
this post from Jim Mulder:
http://www.mail-archive.com/[email protected]/msg108339.html

where he writes,
>>The range from 2GB to 32GB is set aside for a particular
>>intended user, which is the JVM.

The way that the area is used is described in SHARE presentation
2160 from Seattle last year, titled, "Java SDK5, SDK6 and Beyond:
A Performance Update"

--
Tom Marchant

Reply via email to