cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <Chiradeep.Vit...@citrix.com>
Subject Re: [Proposal] Switch to Java 7
Date Tue, 07 Jan 2014 02:55:48 GMT
Java 7 is preferred for Apache Hadoop but not required
http://wiki.apache.org/hadoop/HadoopJavaVersions
(I was looking to see if other OSS projects had migrated)

--
Chiradeep

> On Jan 6, 2014, at 6:16 PM, "Ryan Lei" <ryanlei@cht.com.tw> wrote:
> 
> There was yet another similar discussion a half-year ago:
> http://markmail.org/thread/ap6v46r3mdsgdszp
> 
> -------------------------------------------------------------------------------------------
> Yu-Heng (Ryan) Lei, Associate Researcher
> Cloud Computing Dept, Chunghwa Telecom Labs
> ryanlei@cht.com.tw or ryanlei750328@gmail.com
> 
> 
> 
> On Tue, Jan 7, 2014 at 7:34 AM, Chiradeep Vittal <
> Chiradeep.Vittal@citrix.com> wrote:
> 
>> Yes, there was another discussion here:
>> http://markmail.org/thread/uf6bxab6u4z4fmrp
>> 
>> 
>> 
>>> On 1/6/14 3:18 PM, "Kelven Yang" <kelven.yang@citrix.com> 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/tryResourceClo
>>> se.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
>> 
>> 

Mime
View raw message