incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Johnson <>
Subject Re: Andrew Johnson's comments
Date Thu, 17 Dec 2009 11:07:50 GMT
Steve Poole <> wrote on 10/12/2009 23:04:43:

> > (3).
> >
> > Which methods returning lists throw exceptions?
> >
> > Why is this relevent?

This was just for consistency in the API - having some methods throwing
exceptions rather than returning empty lists or lists with corrupt data
is confusing. There should be good reasons for as deviation from the

> > -------
> >
> > (4).
> >
> > Predictable order via different VMs?
> >
> > What does this mean ?
If you have a list of items then this implies an order. If you have the
same implementation of Kato, but process the dump using two different
VMs to run Kato, should the results come out in the same order? Should
the results come out in the same order from two different runs?
HashSets and HashMaps have unpredictable orders, especially with two
different VMs. If dump processing was multi-threaded then an
implementation could happen to generate results in a different order.
Using an index into a list then becomes less useful.

> > Page 25
> > =======
> > (7).
> >
> > re. `services directory'
> > . This text file should contain a single line which is the package
> > qualified name of the ImageFactory....
> >                                  ^^^^^^
> >
> > Multiple factories?
> > How would multiple factories work in one jar?
> >
> > For each factory you add a new line in the service file.   We can make 
> more clear.
> > (11).
> >
> > public Image getImage(File file)
> >
> > Throws
> > IllegalArgumentException if file is null
> >
> > Why not throw NPE?
> >
> > Don't like NPEs - they can happen unexpectedly.  Throwing a IAE makes 
> deliberate. Thats what its for,
There are huge arguments on this one!
Consistency in the API is also important. Do we check for null everywhere?
Is getImage(nullArg) more common than other errors?

> (12).
> >
> > List<ImageFactory>   sniff file type!
> >
> > get suggested factories for a file or files:
> >
> > / getFactories(File file)
> > \ getFactories(File file, File file)
> >
> > I think that's too specific - if 2 files why not 3 or 4...  If its a 
> of files what happens if multiple factories can handle one or more of 
> files?
> > (15).
> >
> > Table 6.5. Class Summary
> >
> > DataUnavailable should be DataUnavailableException
> >
> >
> > DU extends DUE?
This was more a style issue - normally exceptions have "Exception" in 
name, and errors have "Error" in their name. FindBugs thinks it is bad 
not to. DataUnavailable sounds more like the corresponding Interface to
CorruptData for bad things from lists.
> > Page 29
> > =======
> >
> > Table 6.7. ImageMethods
> >
> > getAddressSpaces()
> >
> >    Also segmented arch?
> >
> > Can you explain some more - I can't guess what you mean.
I'm not sure how we should represent dumps from segmented architectures.
Even Windows sometimes does this - having FS or GS mapping to some
thread specific storage, so FS:[0] is always points to the exception
handler chain for that thread.
What's more confusing is that the FS value is
the same for each thread, but as part of a thread switch the mapping
of the FS register is changed.
I think the way to solve this is to have an ImageRegister.getPointer()
You could then do
ImageRegister FS;

For an ordinary register then getPointer() returns the value
of the register treated as an address in the process address space.

For more complex cases such as FS:0 then this could help.
Fortunately in Windows then FS has a base address in the same address
space as everything else in the process, so FS.getPointer() returns
a pointer in the standard address space, but each thread's
FS would return a different address in the address space even though
getValue returned the same Number.

Also see ESA/370 access registers:
The ESA/370 architecture retained the address size and
other attributes of 370-XA, added 16 new 32-bit access
registers, and extended the address-space control to two
bits to support two additional translation modes: homespace
mode and access-register mode. In the home-space
mode, instruction and operand addresses are translated
using the home STD in CR13. This was originally used
by the ESA/370 control program (MVS*) and now is used
also for Linux** application programs. In the access-register
(AR) mode, instructions are in the primary address
space, and operands are in AR-specified address spaces.
The instruction field specifying a base GR for address
generation for a storage operand also selects the samenumbered
access register. The access register is loadable
by the application program and contains an access-listentry
token (ALET) that designates, by means of an
access-list-entry number (ALEN) an entry in an access
list. The access-list entry in turn points to an ASTE
which contains an STD that is used by DAT to translate
the virtual address for the storage-operand access. Special
ALET values are defined as designating the current
primary STD and current secondary STD. This
architecture allows a program to associate a different
address space with each base register used for storageoperand
accesses. The mapping of ALETs to STDs, known
as access-register translation, is depicted in Figure 4. This
mapping allows for precise control of access to shared
address spaces by various programs as well as
simultaneous and efficient access to multiple address
spaces by a single program.

For this system:
ImageRegister R1;

the Kato implementation would know that R1 was associated
with the address space in AR1 and return an appropriate
pointer in another address space.

Should we have:
ImageRegister.getPointer(long offset)
or perhaps??
ImageRegister.getPointer(Number n)

ImageRegister R1, R2;

Is that worth the convenience over this?

> > Page 30
> > =======
> >
> > getProcessorCount()
> >
> > Returns the number of CPUs running in the system on which the image 
> > running.
> >
> >    System = partition?
> >
> > (I guess Andrew is suggesting "System" should be described as a 
> > in a virtual machine, z/Arch LPAR, pSeries LPAR, etc.?)
> >
> >
> > I don't want too much big iron terminology here.  The end user is 
> going to be intel or equivilent based.  Partition is something on a disk 
> them.  (Or maybe I'm just getting old)
> Any public proof of the best common terminology to use would be welcome.
I guess the system is what the operating system is running on, rather than
the hypervisor's view.

Andrew Johnson
(personal view)

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

View raw message