Re: dead zone
Peter Relson
>contains the substring "32G".
Use2GTo32G: "Satisfy this request for n 1M segments using storage in the
range 2G to 32G."
>At some release 64-bit LE moved the CAA and other control blocks from
>starting at 4G to 32G.
I suspect this isn't true. LE has no control whatsoever over the "origin"
(address returned by IARV64) which determines the address at which its
above-2G blocks are placed. But RSM's giving the range 2G to 32G to Java
likely meant that when LE requested storage from IARV64, it no longer was
given an address "as low as" 4G.
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Mark Zelden
>
> I was told that compressed pointers for storage below 32GB fit
>into a smaller space, so more compressed pointers fit in a cache
>line, leading to more effective cache utilization. Performance is
>all about the caches these days. I am not a Java person. I don't
>know what a compressed pointer is.
>
From what (I think) I understand / remember from what I heard
at SHARE, it is addresses of large object pages. And since they are
in 1M increments / boundaries, the lower 3 bytes aren't needed as
long as the "thing" that needs those addresses understands what
they are. (So obviously you need z/OS 1.9 or above and a z10
with large page support turned on take advantage of this new function).
>> > I'm still intrigued that the (undocumented) option's name
>> > contains the substring "32G". Is 32GiB the size of a particular
>> > granule in 64-bit storage management? Or might the "32" refer
>> > to a fictitious "32-bit" addressing capability?
>>
How many 32bit pointers can fit in 30G? I think 4026531840 - which
would represent 3840T of virtual storage (if my math is correct - which
it probably isn't). I'm getting dizzy thinking about these large numbers.
>
> The range from 2GB to 32GB is set aside for a particular intended
>user, which is the JVM.
>
On Mon, 4 Jan 2010 07:58:37 -0600, McKown, John
<John....@HEALTHMARKETS.COM> wrote:
>>
>> The storage between 2g and 4g is NOT accessible in 31 bit mode.
>>
>
>You're right! So, why bother and how does it improve performance? I guess
we'll never know. It is likely "proprietary".
Since it was talked about at SHARE, I don't think it's proprietary. It's
just not GUPI.
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Tom Marchant
>>
>> I was told that compressed pointers for storage below 32GB fit
>>into a smaller space, so more compressed pointers fit in a cache
>>line, leading to more effective cache utilization. Performance is
>>all about the caches these days. I am not a Java person. I don't
>>know what a compressed pointer is.
>>
Just a wild guess. If all pointers are to storage on a doubleword boundary,
the address can be shifted right three bits. Then you can point to any
doubleword below 32 GB using an unsigned 32-bit address. How that might
help performance is a mystery to me.
--
Tom Marchant
Paul Gilmartin
>
>How many 32bit pointers can fit in 30G? I think 4026531840 - which
>would represent 3840T of virtual storage (if my math is correct - which
>it probably isn't). I'm getting dizzy thinking about these large numbers.
>
15-bit pointers (reserving 1 bit for ?). I surmise this allows
compaction of the page table by a factor of 2.
I'd say "abbreviated" rather than "compressed".
-- gil
Scott Rowe
and therefor use less cache. With today's processor designs, using cache effectively can have huge performance benefits.
>>> Tom Marchant <m42tom-...@YAHOO.COM> 1/4/2010 10:45 AM >>>
--
Tom Marchant
CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you.
Anne & Lynn Wheeler
> Just a wild guess. If all pointers are to storage on a doubleword boundary,
> the address can be shifted right three bits. Then you can point to any
> doubleword below 32 GB using an unsigned 32-bit address. How that might
> help performance is a mystery to me.
don't laugh, I've actually done that for an application ... which
involves huge number of pointers (significantly reduced storage required
before needing to roll over to 64-bit pointers).
--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
Doug Henry
thread.
Match 31-bit WebSphere Application Server performance with new features in
64-bit Java on System z
http://www-03.ibm.com/servers/enable/site/education/wp/1d71a/1d71a.pdf
Doug
On Mon, 4 Jan 2010 12:00:25 -0500, Scott Rowe <Scott...@JOANN.COM>
wrote:
>IIRC, this is the type of thing they are doing, and as Jim mentioned: it
improves performance because more pointers fit in a cache line,
>and therefor use less cache. With today's processor designs, using cache
effectively can have huge performance benefits.
>
>
>>>> Tom Marchant <m42tom-...@YAHOO.COM> 1/4/2010 10:45 AM
>>>
>>On Sat, 2 Jan 2010 15:37:15 -0500, Jim Mulder <d10...@US.IBM.COM>
wrote:
>>>
>>> I was told that compressed pointers for storage below 32GB fit
>>>into a smaller space, so more compressed pointers fit in a cache
>>>line, leading to more effective cache utilization. Performance is
>>>all about the caches these days. I am not a Java person. I don't
>>>know what a compressed pointer is.
>>>
>
>Just a wild guess. If all pointers are to storage on a doubleword boundary,
>the address can be shifted right three bits. Then you can point to any
>doubleword below 32 GB using an unsigned 32-bit address. How that might
>help performance is a mystery to me.
>
>--
>Tom Marchant
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Doug Henry
> Sent: Monday, January 04, 2010 11:33 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: dead zone
>
> Here is an IBM document that answers many of the questions
> raised in this
> thread.
>
> Match 31-bit WebSphere Application Server performance with
> new features in
> 64-bit Java on System z
>
> http://www-03.ibm.com/servers/enable/site/education/wp/1d71a/1d71a.pdf
>
> Doug
Very interesting! Thanks for posting that URL. Using the "bar" for storage avoids out-of-memory errors in 31 bit Java and the overhead in 64 bit Java. The 31 bit Java pointer is 24 bytes, but 48 bytes (with some padding bytes) in 64 bit. So that reduces the storage overhead and page tables and TLB usage. At least, as best as I can tell.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Mark Zelden
>Here is an IBM document that answers many of the questions raised in this
>thread.
>
>Match 31-bit WebSphere Application Server performance with new features in
>64-bit Java on System z
>
>http://www-03.ibm.com/servers/enable/site/education/wp/1d71a/1d71a.pdf
>
Thanks! I've been trying to find something like this since last week when
this thread started. I couldn't even determine what Java level had the
function added when looking at the Java APARs.
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
----------------------------------------------------------------------
Tom Marchant
>McKown, John wrote:
>>> The storage between 2g and 4g is NOT accessible in 31 bit mode.
>>>
>>> Binyamin Dissen <bdi...@dissensoftware.com>
>>>
>>
>> You're right! So, why bother and how does it improve performance?
>>I guess we'll never know. It is likely "proprietary".
>>
>It improves performance by avoiding the extra level of indirection when
>translating the virtual address to a real address on a TLB miss.
>Doesn't have to reference the region-table entry.
What?
Addresses above 2 GiB need the region third index to translate them.
--
Tom Marchant
Doug Henry
Your welcome.
As always Bob Rogers was great when presenting this information.
Doug
On Mon, 4 Jan 2010 12:22:02 -0600, Mark Zelden
<mark....@ZURICHNA.COM> wrote:
>On Mon, 4 Jan 2010 11:32:36 -0600, Doug Henry
<doug_...@USBANK.COM> wrote:
>
>>Here is an IBM document that answers many of the questions raised in this
>>thread.
>>
>>http://www-03.ibm.com/servers/enable/site/education/wp/1d71a/1d71a.pdf
>>
>
>Thanks! I've been trying to find something like this since last week when
>this thread started. I couldn't even determine what Java level had the
>function added when looking at the Java APARs.
>
>Mark
>--
>Mark Zelden
----------------------------------------------------------------------
Mohammad Khan
realize that it's a pig ?
Mohammad
On Fri, 1 Jan 2010 08:41:53 -0800, Edward Jaffe
<edj...@PHOENIXSOFTWARE.COM> wrote:
>Steve Samson <ssa...@dc.rr.com> writes:
>>> The "bar" is a thick one, from 2g to 4g, "sacrificed" to avoid a
>>> somewhat unlikely compatibility exposure. Undisciplined use of the
>>> high-order bit in 31-bit addresses could have led to unexpected
>>> results. The thick bar avoids such a problem. Considering the vast
>>> magnitude of 64-bit virtual addresses, why should anyone care or do
>>> anything to circumvent the omitted address range?
>>>
>
>The z/OS RSM developers introduced functionality to allow Java to
>acquire storage within the previously "thick" bar for performance reasons.
>
>--
>Edward E Jaffe
Shane
> In other words more lipstick is being applied here. When are they going to
> realize that it's a pig ?
Hard to argue ... :-))
Shane ...
Bob Shannon
>> realize that it's a pig ?
>Hard to argue ... :-))
So what's your alternative? Abandon Java on Z?
Bob Shannon
Rocket Software
Mohammad Khan
observation from a bemused observer on the latest installment in this effort.
There was something called High Performance Compiler for Java in mid 90's
IIRC.
Mohammad