JDK-8078234 : Redacted HPROF dump to protect privacy data
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 8u40
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: linux
  • CPU: x86_64
  • Submitted: 2015-04-16
  • Updated: 2024-07-30
  • Resolved: 2016-07-11
Related Reports
Relates :  
Description
A DESCRIPTION OF THE REQUEST :
This problem addresses the necessity to produce debugging information protecting organisations' privacy. 

This RFE introduces a new flag (Debugging Option) in order to produce a redacted HPROF dump which does not expose application run-time data. 

This flag must be used with -XX:+HeapDumpOnOutOfMemoryError and be used to protect application run-time data within the HPROF dump. 

For example -XX:+HeapDumpRedacted or -XX:+HeapDumpEncrypted

The process may consist in updating all the primitive and / or object values with the default ones when the HPROF dump is generated: 

byte = 0
short = 0
int =	0
long	= 0L
float	= 0.0f
double = 0.0d
char = '\u0000'
String (or any object) = null
boolean = false

This flag could also be part of jmap (and/or jmc, other tools) options i.e. 
-redacted or -encrypted

Therefore, as a result only objects themselves remain so as to troubleshoot memory issues. 

JUSTIFICATION :
There are organisations that have got restrictions when providing with debugging information to support. 

For example: 

- Organisations working with their respectives governments.

- Health Organisations where the Protected health information (PHI): Any information about health status, provision of health care, or payment for health care that can be linked to a specific individual must be protected.

- Or any organisation with highly restricted information. 

All of them share the same problem, they experience memory issues within their Java applications, but they are not allowed to provide with a HPROF dump due to data privacy.

On the other hand, support organisations may request for HPROF dumps in a safely environment protecting customers' data. 

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Update all the primitive or object values with the default ones when the HPROF dump is generated: 

byte = 0
short = 0
int =	0
long	= 0L
float	= 0.0f
double = 0.0d
char = '\u0000'
String (or any object) = null
boolean = false

As a result only objects themselves remain so as to troubleshoot memory issues. 
ACTUAL -
HPROF dump with application run-time data in place. 

CUSTOMER SUBMITTED WORKAROUND :
No workaround. 


Comments
Redacted Hprof is not high enough on our list of priorities, closing as WNF.
11-07-2016

This would be possible to implement. One change would be that Strings be left as they are. Instead all primitive arrays (in addition) to primitives should be zero:ed. This would lead to the String's data being removed (the data is stored in a char[]). Setting Object references to null is not a good idea since the whole object graph would then be lost and nothing would be reachable anymore.
22-04-2015

Moving across JDK for investigation by dev team.
21-04-2015