MeasurementScheduleRequest has - long field for interval in ms - 2 refs for data type and numeric type We should change that to - int field for interval in s (just pass and return ms as before but internally store as seconds -- as we do not allow for sub-second requests anyway. - put the 2 refs into a byte (upper half for data type, lower half for numeric type) This will on 64bit archs save 8 bytes per object, which matters when you see that 30k perf test resources can have ~180k schedules and for a heap dump with 24k resources coming from Soa5 servers, there are 300k schedule requests. E.g.: private byte toDataNumType(DataType dataType, NumericType numericType) { byte dTmp = (byte) (dataType != null ? dataType.ordinal()+1 : 0); byte nTmp = (byte) (numericType != null ? numericType.ordinal()+1 : 0); return (byte) (dTmp * 16 + nTmp); }
We need to investigate the impact on scheduling, as the above change loses precision. But I think this is no issue as the real schedules for the measurement collector are kept inside ScheduledMeasurementInfo objects. Those ScheduledMeasurementInfo objects could also benefit from above modifications, as the actual time to collect is kept in nextCollection and lastCollection fields. (saving 8bytes on 200k SMI objects). Question is even if the ScheduledMeasurementInfo objects really need to keep separate fields for enabled, interval, name, scheduleId and could not just point to the respective MeasurementScheduleRequest objects. This should allow to save even some 32-40bytes per SMI object, toalling to 6-8MB heap for the soa5 server case cited above.
The ScheduleMeasurementInfo objects extend the MeasurementScheduleRequests and thus will directly benefit from above change. So in the soa5-servers case, we have 500k objects that each would save 8byte on the MeasurementScheduleRequests and (by also removing the lastCollection field from ScheduleMeasurementInfo) 24Bytes per instance, thus 310k*8b + 227k*24b => 7.7 MB memory saving.
Created attachment 833200 [details] Possible patch
the attached patch looks OK. I would recommend adding javadoc to explain what that "two values in a single byte - one upper nybble and one lower nybble" That way people won't get confused seeing this code in the future - just explain what is in the upper half of the byte and what's in the lower half of the byte.
master 210a7b8
Bulk closing of 4.10 issues. If an issue is not solved for you, please open a new BZ (or clone the existing one) with a version designator of 4.10.