incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <stuk...@stoo.me.uk>
Subject Andrew Johnson's comments: part 4
Date Thu, 10 Dec 2009 14:48:09 GMT
Page 92
=======
JavaHeap
========
(84).
"The Heap can be viewed as an unordered collection of JavaObjects..."
                               ^^^^^^^^^

We expect a reproducible order.

(85).
getObjects

"Get the set of objects which are stored in this heap."

Should explain whether JavaObject, for classes might appear.

(Andrew means the java/lang/Class object instances of classes)

Page 95
=======
JavaMonitor
===========
(86).
getID

Could this throw CorruptDataException?
e.g. some javacore dumps omit this for arraylocks.

(87).
public int getEntryCount()

Number of times a thread is now holding locks on this monitor.

Page 98
=======
JavaReference
=============

(88).
Need static defined here.

(89).
getRootType

"Returns" + extras

(Not sure what Andrew means by this).

(90).
getRootType
"..., see HEAP_ROOT_ static above" where?

(Andrew is referring to the constants that are not included in the PDF 
form of the JavaDoc).

Page 100
========
JavaReference
=============

(91).
getTarget

"Returns a JavaObject or a JavaClass"

Is there a more type safe way of doing this?

(92).
getSource

Not very type safe. Is there a better way?

JavaThread? as well if precise stack frame not known (or JNI Local)

(Andrew touches on a good point here - IBM's 1.4.2 JVM will return 
JavaThread here due to it having a conservative garbage collector)

Page 102
=========
javax.tools.diagnostics.vm
==========================
Dump

(93).
Table 6.43 Class Summary

more info please

(Andrew is asking for more information on the Dump class)

Dump
====
(94).
execute

Need some dump control

(Andrew is suggesting we have more control over dump generation.)

Page 103
========
Table A.2.
==========

(95).

Segments, CS Short
           DS Short

(Andrew is point out how we don't support x86/x86_64 segment registers 
extending that point, we don't support addressing
using them with ImagePointer either)

Page 106
========
Table A.5 zSereies 31 register names
====================================

FP registers

(Andrew is pointing out how we don't list floating point registers.)

Page 107
========
Table A.6 zSeries 64 Register Names
===================================


psw0  Long }  Easier that PSW is BigInteger
psw1  Long }

(Andrew also makes the same point for z/Series 31 register names.)

-----------------------

And that concludes Andrew Johnson's comments.

There are a number of changes that need to be made to the document 
generation.
I've not listed all of Andrews comments. The ones not listed are the 
ones I have applied
as a "matter of law", i.e. spelling errors and indisputable points of fact.

I'll follow up with my comments separately.

Thanks Andrew.

Regards,
     Stuart

-- 

Stuart Monteith
http://blog.stoo.me.uk/


Mime
View raw message