+1 for switching to Java 7 in CloudStack 4.4. Kelven
On 1/6/14, 10:27 PM, "Wido den Hollander" <w...@widodh.nl> wrote: >Just to repeat what has been discussed some time ago. > >All the current Long Term Support distributions have Java 7 available. > >RHEL6, RHEL7, Ubuntu 12.04, Ubuntu 14.04 (due in April) will all have >Java 7 available. > >I don't see a problem in switching to Java 7 with CloudStack 4.4 or 4.5 > >Wido > >On 01/07/2014 12:18 AM, Kelven Yang wrote: >> Java 7 has been around for some time now. I strongly suggest CloudStack >>to adopt Java 7 as early as possible, the reason I feel like to raise >>the issue is from the some of practicing with the new DB transaction >>pattern, as following example shows. The new Transaction pattern uses >>anonymous class to beautify the code structure, but in the mean time, it >>will introduce a couple runtime costs >> >> 1. Anonymous class introduces a ³captured context², information >>exchange between the containing context and the anonymous class >>implementation context has either to go through with mutable passed-in >>parameter or returned result object, in the following example, without >>changing basic Transaction framework, I have to exchange through >>returned result with an un-typed array. This has a few implications at >>run time, basically with each call of the method, it will generate two >>objects to the heap. Depends on how frequently the involved method will >>be called, it may introduce quite a burden to java GC process >> 2. Anonymous class captured context also means that there will be >>more hidden classes be generated, since each appearance of the anonymous >>class implementation will have a distance copy of its own as hidden >>class, it will generally increase our permanent heap usage, which is >>already pretty huge with current CloudStack code base. >> >> Java 7 has a language level support to address the issues in a cheaper >>way that our current DB Transaction code pattern is trying to solve. >>http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceCl >>ose.html. So, time to adopt Java 7? >> >> public Outcome<VirtualMachine> startVmThroughJobQueue(final String >>vmUuid, >> final Map<VirtualMachineProfile.Param, Object> params, >> final DeploymentPlan planToDeploy) { >> >> final CallContext context = CallContext.current(); >> final User callingUser = context.getCallingUser(); >> final Account callingAccount = context.getCallingAccount(); >> >> final VMInstanceVO vm = _vmDao.findByUuid(vmUuid); >> >> >> Object[] result = Transaction.execute(new >>TransactionCallback<Object[]>() { >> @Override >> public Object[] doInTransaction(TransactionStatus status) { >> VmWorkJobVO workJob = null; >> >> _vmDao.lockRow(vm.getId(), true); >> List<VmWorkJobVO> pendingWorkJobs = >>_workJobDao.listPendingWorkJobs(VirtualMachine.Type.Instance, >> vm.getId(), VmWorkStart.class.getName()); >> >> if (pendingWorkJobs.size() > 0) { >> assert (pendingWorkJobs.size() == 1); >> workJob = pendingWorkJobs.get(0); >> } else { >> workJob = new VmWorkJobVO(context.getContextId()); >> >> >>workJob.setDispatcher(VmWorkConstants.VM_WORK_JOB_DISPATCHER); >> workJob.setCmd(VmWorkStart.class.getName()); >> >> workJob.setAccountId(callingAccount.getId()); >> workJob.setUserId(callingUser.getId()); >> workJob.setStep(VmWorkJobVO.Step.Starting); >> workJob.setVmType(vm.getType()); >> workJob.setVmInstanceId(vm.getId()); >> >>workJob.setRelated(AsyncJobExecutionContext.getOriginJobContextId()); >> >> // save work context info (there are some duplications) >> VmWorkStart workInfo = new >>VmWorkStart(callingUser.getId(), callingAccount.getId(), vm.getId(), >>VirtualMachineManagerImpl.VM_WORK_JOB_HANDLER); >> workInfo.setPlan(planToDeploy); >> workInfo.setParams(params); >> >>workJob.setCmdInfo(VmWorkSerializer.serialize(workInfo)); >> >> _jobMgr.submitAsyncJob(workJob, >>VmWorkConstants.VM_WORK_QUEUE, vm.getId()); >> } >> >> return new Object[] {workJob, new >>Long(workJob.getId())}; >> } >> }); >> >> final long jobId = (Long)result[1]; >> >>AsyncJobExecutionContext.getCurrentExecutionContext().joinJob(jobId); >> >> return new VmStateSyncOutcome((VmWorkJobVO)result[0], >> VirtualMachine.PowerState.PowerOn, vm.getId(), null); >> } >> >> >> Kelven >>