incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Pilkington <>
Subject Re: Remaining Specification topics
Date Thu, 10 Sep 2009 14:21:30 GMT
Hi, I think that there is an additional topic which needs to be added
to the list of outstanding items. Although it is not strictly a design
activity, more a strategy, design decisions will need to be made in
order to adhere to it (if we accept that it should be addressed). What
I propose is that implementations of this JSR are required to adopt a
'best can do' approach to returning data to the user. What I mean by
this is that it is not acceptable to be unable to provide information
through the API in the event that a non fatal error occurs when the
underlying data in the core file is being processed. Core files are
often produced in less than ideal circumstances and data integrity
problems should be expected and be treated as 'business as usual'. A
simple example could be iterating over the stack frames and finding a
corrupt one - an implementation would be expected to return the stack
information up to the point of the corruption followed by an object
which implements a CorruptData interface, rather than to just throw a

One implication of adopting this 'best can do' approach is that when
an error occurs you may be able to silently deal with it and complete
the operation, however in terms of problem determination you may have
lost information which could be important in debugging. This
information may be important to the tool which is consuming the API,
but of less importance to the user viewing the information through the
tool. Take for example executing a JavaObject.arraycopy(). It may well
be that as you are traversing the array you come across an invalid
memory address for one of the elements in the array, so rather than
fail the entire copy operation you insert a CorruptData object into
the target array and carry on. The API consumer can detect that one of
the array objects is corrupt, but you have potentially lost vital
information. What I would suggest is that an internal error/message
queue is created onto which more detailed, perhaps also more low
level, information is placed and linked to the returned item via the
objects ID (by ID I mean the value that is returned by calling getID()
on the object). This would allow you to link the error information to
the returned object. It would also allow the operation to complete and
honour the 'best can do' approach. A similar approach is adopted by
the Firefox browser in that it will always attempt to render what it
can to the user, but if you open the error console in a separate
window, you can see all the errors or warnings that were encountered
and what action was taken.

The final part of this is that the API would need to be expanded to
allow this error information to be exposed to API consumers (but not
necessarily the end users)

Does this sound like something that is worth taking forwards ?

2009/9/8 Steve Poole <>:
> hi all,
> Now we have a first specification draft I've been thinking about the
> remaining design activities that need to be closed before we can call the
> JSR complete.  Here's my list.  I'll send out a specific email for each one
> to keep the threads separate.
> 1 -  Round tripping entity identity.   Its desirable to be able to get a
> handle to an entity within a dump and then come back later and ask for the
> entity by handle.
> 2 - Standardising access to internals.   The Java runtime API is
> inconsistent in offering support for accessing the internal data of an
> entity.
> 3 - Optionality - how do we  define a mechanism that allows a dump to
> explain what it contains.
>  4 - "Snapshot" support - We need to determine what the direction is for
> supporting smaller, faster and content configurable dumps.
> Cheers
> Steve


Adam Pilkington

View raw message